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

16

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

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

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

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

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

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

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

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

Конрад Моравский
источник
24
«Дайте мне шесть часов, чтобы срубить дерево, и я проведу первые четыре заточки топора». - Авраам Линкольн "Оттачивай свой топор в свободное время". - Большинство боссов
JeffO
15
Некоторая путаница здесь для меня вызвана названием, например, когда я читаю «бегло»I.ThinkOf(this).KindOfThing()
Бенджол
Вы спрашивали этого старшего разработчика, почему он это сделал? Как вы уже указали, приложение глючит. Так что, возможно, старший разработчик был ограничен в том, что он мог делать с этим ошибочным приложением сам. Если его код работает только "большую часть времени", то он содержит ошибки и должен быть заменен и / или исправлен.
Ramhound
@Ramhound - нет, так как он покинул компанию до того, как я присоединился. Он был последним человеком, который работал над этим, прежде чем я занялся этим. От коллег я знаю, что он спешил, так как исправление приложения было приоритетом из-за многих жалоб клиентов. Но он не очень хорошо справлялся с управлением временем, поскольку время от времени он явно протаранил открытую дверь. Кстати, он создал свою собственную библиотеку для локализации приложений WPF и Winforms.
Конрад Моравский
1
тесно связаны: это и это . Некоторые (многие) люди застревают на этом этапе ...
BlueRaja - Дэнни Пфлугхофт

Ответы:

22

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

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

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

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

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

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

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

прецизионный самописец
источник
1
Я тоже был этим парнем - и я не согласен со вторым предложением. Возможность решения большинства проблем не означает, что ваши решения надежные, поддерживаемые, гибкие, масштабируемые ... или даже то, что первоначальная реализация разрабатывается так быстро. Многие лучшие идеи, которые вы узнаете за пределами справочников по языку / библиотеке, - это «почему я об этом не подумал?» простой, а также гибкость, масштабируемость и т.д. Одна из худших вещей , - понимая , что я был подвержен идеей ранее, но отклонил его как бессмысленная академическую абсурдность, без практического использования, поэтому , когда я нуждался в этом ...
Steve314
6
В некоторых организациях получение разрешения на использование сторонней библиотеки может занять шесть месяцев и более. В некоторых случаях вы можете подождать шесть месяцев и получить отказ в конце, так или иначе. Раньше я создавал одноразовый ORM только потому, что не хотел тратить время на бюрократию, когда уже был в сжатые сроки.
Тоби
2
@Toby: Честная точка зрения. Но эти компании, как правило, больше не экономят.
фунтовые
Не говоря уже о том, что ВВС США такие же, как упомянутые компании @Toby. Мы пытались протолкнуть Ruby on Rails, но им это не понравилось.
Трэвис Пессетто
@Тобы, однако, есть несколько случаев, когда изобретать велосипед - правильная вещь, ключ должен убедиться, что вы понимаете, почему вы
jk.
14

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

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

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

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

Кристофер Биббс
источник
1
Да, в самом деле. И я полагаю, что я был бы более против такого рода людей, если бы я не зарабатывал на жизнь в течение многих лет, прибывших, чтобы убирать за ними ... ;-)
Майк Вудхаус,
4

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

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

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

JeffO
источник
Именно моя мысль. Если основной целью компании является предоставление как можно быстрее, то люди часто работают допоздна и делают то, что не делали бы, если бы им было позволено работать без давления. Вы чувствуете себя более «продуктивным» и полезным, если набираете много кода, о котором думаете во время набора текста. Откинувшись назад, чтобы подумать или даже поговорить с коллегами о проблемной проблеме ... такого рода вещи легко заставляют вас чувствовать, что вы откладываете проект. Вы могли бы писать код в то время, верно? ;-).
deadsven
Мне повезло После переезда мне разрешили работать из дома. Все хотят знать, сделано ли это, и не работаю ли я. Я не буду наказан за знание ответа.
Джефф
3

100%.

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

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

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

l0b0
источник
1

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

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

Скотт К Уилсон
источник
1

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

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

Даниэль Перейра
источник
0

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

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

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

MPelletier
источник
как это отвечает на заданный вопрос?
комнат
@gnat На вопрос «Что ты об этом думаешь?», я ответил так, как я думал. Я по-прежнему придерживаюсь того же мнения: беглость (что позволяет быстро находить решения, взламывать и т. Д.) Может в конечном итоге привести к вредоносному коду. Вы не можете просто свободно говорить на языке, вы должны знать, как организовать код.
MPelletier