Написание легко модифицируемого кода

Question

Каким образом я могу написать легко модифицируемый код?

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

Answer 1

Общее руководство - вне поля зрения

• Высокая когезия, низкая связь
• Не повторяйся
• Распознавать шаблоны проектирования и реализовывать их
• Не распознавать шаблоны проектирования там, где их нет или необходимо
• Используйте стандарт кодирования, придерживайтесь его
• Комментируйте все, что следует комментировать, если сомневаетесь: комментарий
• Использовать юнит-тесты
• Пишите комментарии и тесты перед внедрением, чтобы точно знать, что вы хотите сделать
• И когда все идет не так: рефакторинг, рефакторинг, рефакторинг. С хорошими тестами вы можете быть уверены, что ничего не сломается

И о да:

читать это: http://www.pragprog.com/the-pragmatic-programmer

Все (я думаю) выше и больше в нем

Answer 2

Повесьте ваш код на D.R.Y.

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

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

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

Всегда запускайте свой код через DRY-er.

Answer 3

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

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

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

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

Answer 4

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

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

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

Рассматривая использование проверенных и верных методов над передовыми. Вы отказываетесь от некоторых функций для предсказуемости.

Наконец, если этот код будет использоваться людьми до и после модификации, вам необходимо (ed) иметь соответствующий API, изолирующий ваш код от их. Наличие сильного API позволяет вам изменить ситуацию за кулисами без необходимости предупреждать всех ваших потребителей. Я думаю, что по этому поводу есть достойная статья о Coding Horror.

Answer 5

Вот мой текущий опыт: я работаю (Java) со своего рода схемой базы данных, которая может часто меняться (поля добавлены / удалены, типы данных изменены). Моя стратегия состоит в том, чтобы проанализировать эту схему и сгенерировать код со скоростью apache . Сгенерированный BaseClass никогда не изменяется программистом. Иначе, создается MyClass extends BaseClass, и логические компоненты этого класса (например, toString ()!) Реализуются с использованием «получателей» и «установщиков» суперкласса.

Answer 6

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

Проектирование при написании кода никогда не работает ... для меня :-)