Как убедить команду программистов отпустить старые пути?

Question

Это вопрос бизнес-программирования, который я не могу понять, как решить. Я работаю с командой программистов, которые работают с Бейсиком более 20 лет. Меня привели, чтобы помочь написать то же самое программное обеспечение в .NET, только с обновлениями и современными методами. Проблема в том, что я не могу заставить кого-то из трех других членов команды (всех программистов на BASIC, хотя сейчас и на .NET тоже) понять, как правильно создавать реляционную базу данных. Вот что они не поймут:

У нас в основном есть транзакция, которая отслеживает информацию тега клиента. Нам нужно иметь возможность отслеживать текущие транзакции и прошлые транзакции. В старой системе использовалась база данных с плоскими файлами, в которой была одна таблица, содержащая записи с основной текущей транзакцией клиента, и другая транзакция, которая содержала все предыдущие транзакции клиента вместе с важной денежной информацией. Чтобы избежать избыточности, они перезаписывают текущую транзакцию историей транзакций (сначала обновляется файл истории, а затем текущая.) Это совершенно не нужно, поскольку вам нужна только одна таблица транзакций, но мой руководитель или любой другой из двух моих коллег -работники не могут этого понять. Как именно я могу убедить их увидеть свет, чтобы нам не приходилось делать нелепое количество работы и в конечном итоге слишком много раз попадать в базу данных? Спасибо за вклад!

Answer 1

Во-первых, я должен признать, что из вашего описания мне не совсем понятно, каковы структуры данных и логические потоки в существующих структурах. Для меня это означает, что, возможно, вы также не разъясняете себя своим коллегам, поэтому один из ваших приоритетов должен состоять в том, чтобы иметь возможность объяснить, устно или предпочтительно в письменной форме и диаграммах, текущую ситуацию и предлагаемую замену. Пожалуйста, примите это как замечание, а не как критику вашего вопроса.

Во-вторых, я нахожу весьма примечательным, что программисты с 20-летним опытом не понимают реляционные базы данных и транзакции. Кодирование плоских файлов вышло из мейнстрима очень давно - я впервые работал с реляционными базами данных в коммерческих условиях еще в 1988 году, и к середине 90-х они стали довольно распространенным явлением. Какой сектор и тип продукта вы работаете? Для меня кажется возможным, что вы можете иметь дело с какой-то встроенной или иным образом «необычной» системой, и в этом случае вам нужно убедиться, что у вас нет какой-либо проблемы со связью, и вы пропускаете большого слона. вам не было указано - вы не будете первым «консультантом», привлеченным в команду, которая каким-то образом создана из-за отсутствия соответствующей информации. Тем не менее, такие архаичные магазины все еще существуют - одна из моих нынешних клиентских систем взаимодействует с системой на основе плоских файлов, написанной на языке COBOL, и да, управлять ею просто ужасно; -)

Наконец, если вы полностью уверены в своей позиции и столкнулись с командой, которая не примет ваши рекомендации - и демонстрационный код это хорошая идея, если вы можете сэкономить время - тогда у вас, вероятно, будет принять решение изящно и переместить один. На этом месте я бы попытался абстрагироваться от проблемы - можно ли, например, перенести обновления базы данных в хранимые процедуры, чтобы код для обновления обеих таблиц был в SP и мог быть изменен позднее, чтобы перейти к вашей схеме без изменение соответствующего приложения? Убедитесь, что ваши аргументы хорошо документированы и записаны, чтобы вы могли вернуться к ним позже, если возникнет такая возможность.

Вы не будете первым программистом, которому пришлось внедрить неоптимальное решение из-за офисной политики - используйте его в качестве учебного опыта для своего личного развития по работе с такими ситуациями и соблазнитесь мыслью, что вам заплатят для дополнительной работы. Часто решающим фактором в таких аргументах является не логика, а «вес репутации», который вы сами приносите на стол - звучит так, как будто вас привлекли, у вас не так много рычагов воздействия в вашей команде, так что вы Возможно, вам придется поработать над завоеванием репутации, превзойдя в реализации то, что они согласны сделать, прежде чем вы приобретете достаточную репутацию в последующих случаях - вам нужно сначала измениться!

Answer 2

Иногда лучшим аргументом является пример. Я бы написал прототип (или замену, если не слишком много работы). На примере, который нужно изучить, будет легче увидеть плюсы и минусы реляционной базы данных.

Кроме того, у баз данных с плоскими файлами есть свои места, так как их намного легче "администрировать", чем настоящую реляционную базу данных. Сохраняйте открытость. ; -)

Answer 3

Иногда вы не можете.

Если вы читаете некоторые книги по XP, они часто говорят, что одним из ваших самых больших препятствий будет убедить вашу команду отказаться от того, что они всегда делали.

Обычно они рекомендуют людям, которые не могут адаптироваться, переходить в другие проекты (или просто отпускать их).

Обзоры кода могут помочь в вашем случае. Обязательные проверки кода каждой строки кода не являются неслыханными.

Answer 4

Я думаю, что вам, возможно, придется подавать пример - когда люди видят, что «новый» путь - это меньше работы, они примут его (если вы не потираете в этом свои носы).

Я бы также спросил себя, действительно ли старый дизайн вызывает проблему или это просто эстетически раздражает. Важно выбрать свои сражения - если старый дизайн не вызывает проблем с производительностью или затрудняет обслуживание системы, вы можете оставить старый дизайн в покое.

Наконец, если вы оставите старый дизайн на месте, попробуйте и абстрагируйте интерфейс между вашим новым кодом и старой базой данных, чтобы, если вы убедите своих коллег улучшить дизайн позже, вы можете отказаться от новой схемы без необходимость что-либо изменить.

Answer 5

Трудно выделить много всего, кроме общего разочарования от первоначального вопроса.

Да, существует множество техник и привычек, которые долгое время приобретают люди, которые могут оказаться бесполезными и даже дорогостоящими в свете технологических изменений. Некоторые вещи, которые имели смысл, когда вычислительная мощность, память и даже диск были дорогими, теперь могут быть глупыми попытками оптимизации. Также очень часто люди накапливают вредные привычки и плохие модели программирования с течением времени.

Вы должны быть осторожны, хотя.

Иногда есть веские причины для того, что делают эти старые таймеры. К сожалению, они, возможно, даже не смогут выразить словами «почему» - если они даже больше знают, почему.

Я вижу много такого разочарования, когда новички приходят в цех по разработке программного обеспечения для предприятий. Это может быть плохо, даже если в среде достаточно современных технологий и инструментов. Если большая часть вашего опыта заключается в написании небольших настольных и веб-приложений для небольшого сообщества, многое из того, что вы «знаете», может оказаться неправильным.

Часто существуют требования к ведению журнала транзакций на уровне выше того, что может делать ваша СУБД. Довольно часто бывает необходимо выйти за пределы семантики транзакций БД, чтобы обеспечить корректность временной последовательности, один раз и только один раз, обновление, отказоустойчивость и отсутствие отказа.

И это даже не начинает решать проблемы, связанные с масштабируемостью предприятия или между предприятиями. Когда вы начнете приближаться к полумиллиону сложных транзакций в день, вы обнаружите, что технология RDBMS не дает вам результатов. Поскольку реляционные базы данных не предназначены для обработки больших объемов транзакций, вам часто приходится нарушать стандартные парадигмы для нормализации и обновления. Обычные методы блокировки СУБД могут разрушить масштабируемость, независимо от того, какое количество оборудования вы используете для решения проблемы.

Легко отрицать все это как грубость или общую глупость - даже некомпетентность. Но будьте осторожны, потому что это не всегда так.

И, между прочим: помимо RDBMS существуют и другие модели, и альтернативой RDBMS не обязательно являются «плоские файлы» - вопреки опыту большинства современных программистов. Существуют транзакционные иерархические СУБД, которые могут обрабатывать гораздо более высокую пропускную способность, чем СУБД. Например, IMS все еще жива в крупных магазинах IBM. Другие поставщики предлагают аналогичное программное обеспечение для разных платформ.

Конечно, в магазине на 4 человека, может быть, ничего из этого не применимо.

Answer 6

Следующее может не применяться в вашей ситуации, но вы очень мало упоминаете о технических деталях, поэтому я подумал, что упомяну это ...

Иногда, если шаблоны доступа сильно отличаются для текущих данных, чем для исторических данных (я создаю этот пример, но скажу, что к текущим данным обращаются 1000 раз в секунду и к небольшому подмножеству столбцов, и все текущие данные умещаются менее чем в 1 ГБ, тогда как, скажем, в исторических данных используется 1000 ГБ, доступ осуществляется только 100 раз в день, и доступ ко всем столбцам),

тогда то, что делают ваши коллеги, имело бы смысл для оптимизации производительности. Разделив текущие данные (избыточно по альбету), вы можете оптимизировать индексы и структуры данных в этой таблице для более высокочастотных схем доступа, которые вы не могли сделать в хронологической таблице.

Не все, что является "академически" или "технически" правильным с чисто реляционной точки зрения, имеет смысл, когда применяется в реальной практической ситуации.

Answer 7

Запишитесь на несколько приличных тренингов, и тогда вам нужно убедить их, что с новыми технологиями возможно гораздо больше (или, по крайней мере, проще!).

Но я думаю, что самое важное здесь - это то, что профессиональные сертифицированные тренеры сначала обучат их основам. Они будут более впечатлены этим, а не просто одним из их коллег, который скажет им: «Эй, почему бы не использовать это?»

Похожие посты здесь .