Дизайн для удобства сопровождения кода

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

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

Что означает невозможность поддержки кода? Когда то, что, по вашему мнению, должно занимать часы, в конечном итоге занимает недели. Именно тогда вы можете с уверенностью сказать, что у вас есть неподдерживаемый код.

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

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

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

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

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

• Избегайте дооснащения функциональными возможностями. Это главная проблема, из-за которой код становится недоступным в течение определенного периода времени. После модернизации вам понадобится еще одна функция, которую вы в конечном итоге модернизируете поверх модернизации. Короче говоря, это кроличья нора, в которую не захочется заходить. Постарайтесь заметить их как можно раньше и полностью избегайте их.
• Не изменяйте архитектуру кода для незнакомых вам функций. Создавайте только то, что вы знаете. Будьте открыты для рефакторинга дизайна в соответствии со своими потребностями. Чтобы вносить безопасные изменения, создайте хороший пакет автоматизации, который даст вам уверенность в том, что ваши ожидания оправдаются по мере того, как вы продолжаете изменять код.
• Следуйте твердым принципам - всегда старайтесь придерживаться принципов единой ответственности, открытого-закрытого и разделения интерфейсов. Если вы попытаетесь придерживаться этих принципов, он автоматически структурирует ваш код, чтобы его можно было сопровождать.
• Используйте шаблоны проектирования с определенной целью - Если у вас есть места, где есть смысл использовать известные шаблоны проектирования, используйте их и, что еще более важно, назовите свои классы осмысленно.
• Простота. Я не могу не подчеркнуть, насколько важно писать простой код и сохранять простой дизайн в целом. Следуйте принципу ПОЦЕЛУЙ (будь простым, глупым) до глубины души. Как только вы заметите, что некоторые части вашего кода начинают расти, пора сделать шаг назад и задуматься над общим дизайном и ответственностью этой части кода. Выполните рефакторинг, чтобы упростить работу с учетом новых требований.
• Лучше меньше, да лучше. Не бойтесь удалять код. Код, который не нужен и просто валяется, означает, что нужно поддерживать больше кода. Возьмите за привычку удалять мертвый код.
• Правильно выполняйте обработку ошибок. Обработка ошибок - важная и фундаментальная часть, которая определяет, как логические потоки создают уровни ваших компонентов. По-настоящему подумайте о том, как вы хотите сделать это для текущего проекта, и последовательно следуйте этому на протяжении всего.

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

Заявление об ограничении ответственности: выраженные мной мнения являются исключительно моими и не отражают взгляды или мнения моего работодателя.

Если вам понравился этот пост, он тоже может вас заинтересовать: