Перевод статьи «What Are The Best Software Engineering Principles?».
Принципы разработки программ это определенные правила и рекомендации, которым следуют разработчики, если хотят писать красивый, понятный и поддерживаемый код.
Нет никакой волшебной палочки, с помощью которой можно было бы превратить смесь переменных, классов и функций в идеальный код. Но с помощью некоторых советов и подсказок инженер может понять, правильно ли он все делает.
Давайте рассмотрим базовые рекомендации. По большей части это общие советы, применимые независимо от языка, на котором вы пишете.
Семь раз отмерь, один раз отрежь
Я думаю, это самое главное. Если из всей статьи вы запомните только одно правило, то пусть это будет именно этот принцип.
Мы, разработчики/devops/архитекторы/менеджеры страдаем от недостатка внимания, от глупых ошибок и опечаток. Я полагаю, что, применительно к разработке, этот принцип означает качество и уверенность в своем коде/процессе/системе. Однако эта уверенность происходит не из самого кода как такового, она должна базироваться на тестах.
Не повторяйся (Don’t Repeat Yourself – DRY)
Это довольно простое, но полезное правило, гласящее, что повтор одного и того же кода в разных местах является плохой идеей. Причина этого в том, что в дальнейшем ваш код нужно будет поддерживать и видоизменять. Если какой-то отрывок дублируется в нескольких местах программы, высока вероятность, что это приведет к негативным последствиям двух типов:
- При необходимости внести даже мельчайшее изменение в код вам придется делать это во всех местах, где этот код используется. Это потребует много дополнительного времени и усилий (порой это нелегкое занятие – см. закон Миллера).
- Продвигаясь от одного экземпляра повторяющегося кода к другому, вы можете случайно пропустить один из них, и это приведет к ошибкам в приложении.
В связи с этим рекомендуется выделять код в отдельный метод, если он встречается больше двух раз. Это совет общего характера. Фактически, об отдельном методе стоит подумать, даже если у вас есть только один повтор кода.
Бритва Оккама
Это очень простая идея, пришедшая в программирование из философии. Свое название она получила в честь английского монаха Вильяма из Оккама. Идея сводится к следующему: «Не следует множить сущее без необходимости».
В IT этот принцип понимается так: не следует создавать дополнительные сущности, если в них нет нужды. Поэтому, собираясь добавить какой-нибудь метод / класс / инструмент / процесс / что-угодно, следует сперва подумать о том, какие преимущества даст такое добавление. Если преимуществ нет, а сложность возрастает, то зачем же добавлять?
Принцип KISS (Keep it simple, stupid – «Придерживайся простоты»)
Этот принцип очень похож на предыдущий, но его значение слегка отличается. Принцип гласит, что код должен быть простым и по возможности не содержать никаких сложных структур. В противном случае сильно усложняется отладка и поддержка этого кода.
Кроме того, если не следовать этому принципу, другому программисту будет сложно разобраться в запутанных и сложных ветвлениях, и в связи с этим его работа также потребует дополнительного времени и усилий.
Поэтому следует всегда стремиться использовать простые и логичные конструкции без глубокой вложенности. Это упростит жизнь и вам, и вашим коллегам, поскольку сложность порождает баги. Помните о выражении Петера Хинтдженса:
«Простота всегда лучше функциональности».
Принцип YAGNI (You Aren’t Gonna Need It – «Тебе это не понадобится»)
У многих программистов возникает желание реализовать сразу весь необходимый функционал (а иногда даже то, что необходимым не назовешь) с самого начала процесса разработки. И тогда разработчик сразу добавляет все возможные методы к классу и реализует их, хотя в будущем они могут даже не понадобиться.
Поэтому, согласно данной рекомендации, реализуйте сначала только необходимое, а уж потом, по мере надобности, наращивайте функционал. Так вы сэкономите усилия, время и нервы, которые потратили бы на отладку ненужного кода.
Big Design Up Front («Сначала – проектирование»)
Прежде чем начать разрабатывать функционал, необходимо до мельчайших деталей продумать архитектуру приложения и всю информационную систему. Только после этого можно приступать к реализации по предварительно подготовленному плану.
Этот принцип имеет право на существование, однако в последнее время подвергается критике. Основная ее причина – устаревание плана в ходе проектирования и разработки. Поскольку план устаревает, вам придется вносить соответствующие изменения.
Однако такой подход имеет неоспоримые преимущества. Благодаря правильному проектированию вы сможете существенно снизить стоимость последующей отладки и исправления багов. Более того, созданные таким образом информационные системы обычно более последовательны и правильны в архитектурном плане.
Избегай преждевременной оптимизации
«Преждевременная оптимизация – корень всех зол в программировании (или, по крайней мере, большей их части)»,
– Дональд Кнут.
Оптимизация это очень нужный процесс, позволяющий ускорить работу программы, а также снизить потребление ресурсов системы. Но всему свое время. Если оптимизация осуществляется на ранних стадиях разработки, она может принести больше вреда, чем пользы.
Это связано с тем, что работа с оптимизированным кодом отнимает у разработчика больше времени и усилий, да и вообще может оказаться более сложной. В подобных случаях довольно часто возникает необходимость сначала проверить правильность выбранного подхода к разработке.
Поэтому предпочтительнее в начале использовать не самые оптимальные решения, а более простые. Уже впоследствии, оценив, насколько эти решения замедляют работу приложения, следует внести изменения, которые ускорят работу или снизят ресурсоемкость алгоритма.
Следует также учитывать, что при реализации наиболее оптимального алгоритма в начале разработки в ходе ваших работ могут поменяться требования – и вся работа полетит псу под хвост. Так что не нужно тратить время на преждевременную оптимизацию.
Принцип наименьшего удивления
Этот принцип означает, что ваш код должен быть интуитивно понятным и очевидным. Он не должен удивлять другого разработчика во время ревью кода. Например, если метод называется «делать печеньки», но в результате получается картошка, то этот код плохой (и это очевидно).
S.O.L.I.D.
«SOLID» представляет собой целую группу принципов объектно-ориентированного проектирования, используемых отдельными разработчиками при написании кода. Каждая буква этого акронима соответствует одному из принципов:
- Single responsibility (Принцип единственной ответственности). Каждый модуль или класс должен отвечать за единственную часть функционала. Эта часть должна быть полностью инкапсулирована в этом классе.
- Open-closed (Принцип открытости-закрытости). Сущности программы (классы, модули, функции и т. д.) должны быть открыты для расширения, но закрыты для изменения.
- Liskov substitution (Принцип подстановки Барбары Лисков). Наследующий класс должен дополнять, а не заменять поведение базового класса.
- Interface segregation (Принцип разделения интерфейса). Клиентский интерфейс не должен зависеть от методов, которые он не использует.
- Dependency inversion (Принцип инверсии зависимостей). Программист должен работать на уровне интерфейса, а не на уровне реализации.
Когда все эти принципы применяются совместно, разработчик создает код, который со временем будет легко поддерживать и расширять.
Закон Деметры
Основная идея этого принципа состоит в том чтобы разделять зоны ответственности между классами вашего кода и инкапсулировать логику внутри класса, метода или структуры. Исходя из этого принципа, можно вывести несколько рекомендаций:
- Классы или другие программные модули должны быть независимы.
- Нужно стараться уменьшать количество связей между различными классами (см. зацепление).
- Классы, имеющие непосредственное отношение друг к другу, должны находиться в одном модуле/пакете/папке (см. связность).
Если разработчик следует этому принципу, создаваемое им приложение будет более гибким, понятным и поддерживаемым.
Заключение
Товарищи разработчики, давайте будем инженерами! Давайте создавать надежные и хорошо реализованные системы, а не каких-то быстрорастущих монстров. Этому поможет следование указанным здесь принципам. Конечно, все эти принципы сформулированы не мной; я лишь подумал, что не помешает напомнить о них.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]