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

Question

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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

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

Однако ты должен быть осторожен.

Иногда на то, что делают эти старожилы, есть веские причины.К сожалению, они, возможно, даже не смогут сформулировать "почему" - если они вообще теперь знают "почему".

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

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

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

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

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

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

Answer 6

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

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

Связанный пост здесь.

Answer 7

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

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

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

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