Если беглый кодер пренебрегает хорошими практиками, разве его беглость не работает против него? [закрыто]

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

Значительная часть приложения была создана стажерами, n00bs и т. Д .; но также был программист в ранге Master Developer, и со всей скромностью оставленный им код также сомнителен, возможно, по-другому, но все же.

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

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

Предполагая, что это правда, я могу подумать о следующих причинах:

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

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

Что вы думаете об этом? Это правда (до какой степени, если так)?

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

Да. Я был этим парнем. И я узнал, что это ужасная вещь.

Это все очень хорошо для вас, вам не нужно изучать что-то новое.

Но как насчет остальной части вашей команды? Они становятся очень зависимыми от вас. Они не могут найти Google «Quicky ORM Клайва», чтобы получить помощь по объектно-реляционному картографу, который вы написали.

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

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

Да, изучение Hibernate заняло бы больше времени, чем написание чего-то более легкого. Но выгода от этого слишком велика, чтобы ее игнорировать, ИМХО.

• если вы с легкостью кодируете, то чувствуете (или на самом деле в краткосрочной перспективе) просто быстрее выявляете ваши собственные решения на месте, не обращаясь к библиотекам, существующей функциональности и т. Д.

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

• если у вас достаточно опыта, чтобы легко поддерживать образ сложной программы, он менее склонен разбивать ее на модули, слои и т. Д.

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

Просто убедитесь, что это не потому, что он работает в среде «Если ваша клавиатура не щелкает, значит, вы не работаете». Мы все оглядываемся на код и задаемся вопросом, о чем мы думали. Кроме того, этот магазин практикует рефакторинг своего кода? Возможно, это была роскошь, которую ему не дали.

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

Изменить: Давайте удостоверимся, что мы не наказываем тех, кто случайно знает ответы. Есть те, кто свободно и быстро пишет хороший код. Ключ не должен подходить к каждой проблеме таким способом.

100%.

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

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

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

Проблема, которую вы описали, была в основном NIH («не изобретена здесь») - есть ли другие симптомы?

Иногда NIH, особенно если он изолирован от одного или двух человек, может быть рассмотрен в групповом обсуждении («Джо имеет некоторый опыт создания резервных копий SQL с использованием стандартных библиотек - как вы думаете, Джо?»). Это может быть менее конфронтационно, чем просто обратиться к человеку и сказать: «Эй! Используй стандартную библиотеку, дурачок!» :)

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

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

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

Самым большим препятствием для «быстрых и грязных» решений является всегда, когда вам нужно добавить к нему больше позже. Когда вам нужно больше возможностей. Есть только так много, что вы можете сделать без структуры. После этого он ломается, и его перегруппировка обходится дорого (пока что удовлетворяет, но не очень ценится).

По сути, вы должны защититься от ЛЮБОГО ХАКА, который потенциально может стать «работоспособным решением», готовым для продажи нетерпеливым продавцом. Это старое "Это не готово! - Но это работает, нет?" головоломка.