Как бороться с отличными продуктами, написанными с дерьмовым кодом?

Question

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

К сожалению, код раздут, иногда очень плохо написан, и его трудно читать и изменять. Это значительно усложняет реализацию изменений.

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

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

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

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

Answer 1

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

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

Answer 2

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

Затем выполните рефакторинг наихудших битов кода или битов, которые вам все равно нужно изменить.

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

И найди оригинальных разработчиков и соблазни их в какой-нибудь темный переулок :) Или, лучше, заставь их сделать изменения

Answer 3

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

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

Если изменения более сложные, попробуйте применить свои изменения в как можно меньшем количестве мест. Если ваш план состоит в том, чтобы со временем очистить код, это место для начала. Будьте осторожны с изменениями, которые вы делаете, потому что вы можете легко сломать зависимости, которые вы не понимаете. Мой личный опыт заключается в том, что я обычно могу добавлять новые функции или вносить изменения, фактически удаляя код и переписывая то, что осталось в любой данной подпрограмме или методе.

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

Answer 4

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

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

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

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

В-третьих , план улучшения, он может содержать недавние и будущие TODO

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

У каждого программного обеспечения есть возможности для совершенствования, поэтому вас наняли для его улучшения.

Answer 5

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

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

Answer 6

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

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

Что касается "дерьмового кода", это очень субъективно. Это действительно код (реализация), который "дерьмовый" или дизайн? Есть ли нехватка шаблонов дизайна? Злоупотребление или плохая реализация шаблонов проектирования? Или они действительно реализовали цельные шаблоны проектирования, но вы просто недостаточно знакомы с ними, чтобы их распознать?

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

Answer 7

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

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

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

Answer 8

"Несмотря на это, приложение хорошо выглядит, полезно, и пользователям нравится и оно хочет изменений"

Приложение, очевидно, дает клиентам то, что они хотят, но звучит так, как будто оно достигло неуправляемой стадии.

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

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

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

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

Answer 9

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