Подходы при разработке: KISS, YAGNI, DRY, SOC, LOD и другие
6 января 2017
В этой статье раскрываются некоторые сокращения с рекомендациями по реализации проектов. Ни в коем случае нельзя принимать эти рекомендации за истину в последней инстанции. Всегда есть нюансы, всегда есть ограничения, всегда есть противоречия. Просто нужно выбирать и придерживаться того, что вам и команде будет удобнее с прицелом на перспективу.
Чем проще код, логика и общая реализация, тем понятнее и надёжнее система. Излишнее усложнение без явной выгоды таит явные проблемы.
Не нужно делать функционал, который не нужен прямо сейчас. Это позволяет сэкономить ресурсы, высвободить время, набрать опыта использования и сформировать более предметные требования для доработки системы.
Если есть несколько одинаковых кусков функционального кода, то нужно его переносить в общую функцию (класс, метод, трейт и другие элементы языка). Так легче вносить изменения, потому что экономится время и снижаются косяки. Аналогично не только с кодом, но и с другими вещами, например, с логикой – если есть одинаковые объекты, то можно попытаться выделить их них общую абстракцию.
Разработчик не должен писать программу как единый блок, а должен разбивать код на части и так, чтобы каждая часть выполняла отдельную простую работу.
Для функций - если вы понимаете, что используемая функция становится слишком объемной и принимает слишком много аргументов, то ее следует разделить на более мелкие функции. Ключом к успешному разделению функций является обнаружение перенагруженности и путаницы.
Закон Деметры гласит, что нужно укорачивать связи (уменьшать знания) между объектами, взаимодействуя только со своими ближайшими друзьями, а не с друзьями друзей.
В более строгом виде закон описывается так:
Объект A может вызывать методы объекта B, но объект A не должен через объект B получать доступ к объекту C, чтобы вызывать методы объекта C. Иначе это будет вести к тому, что объекту A потребуется больше знаний о внутренней структуре объекта B и приведёт к нарушению закона.
Подход призывает перед разработкой досконально продумать весь функционал и сделать детальный проект программной системы. Затем можно переходить к реализации – программированию, тестированию, отладке и так далее.
Подход призывает выполнить задание – выяснить осуществима ли задумка, будет ли она достигать заявленные цели, сколько времени, людей и финансовых затрат потребуется на реализацию. На выходе должен получиться отчёт, презентация или иной документ с описанием итогов проверки концепции.
Пригодный для использования продукт, в котором реализованы основные функции и который был сделан для получения обратной связи от пользователей. MVP используется, когда хочется быстрее опробовать продукт и понять в какую сторону двигаться дальше.
Философский принцип, который применим всюду. Он значит, что среди конкурирующих гипотез следует выбирать ту, которая наиболее простая и которая несёт наименьшее количество новых предположений.
Не нужно заниматься оптимизацией на ранних этапах разработки проекта. Это вам поможет сконцентрироваться на реализации общей концепции проекта и не позволит утопать в технических деталях.
Код не должен удивлять другого разработчика. А значит, что при прочих равных код желательно делать простым, понятным (включая названия переменных, методов, классов и т.п.) и написанным по рекомендациям, например, PSR (см. статью «Перевод рекомендаций по стандартам PSR-1, PSR-4 и PSR-12»).
Дублируемого кода в долгосрочной перспективе обходится дороже и несёт больше рисков, чем его переделка. Для решения проблемы см. выше принцип DRY (не повторяйся).
В проектировании это значит, что достоверность анализа и его результатов зависит от качества входных данных. В программировании подход означает, что ввод ошибочного значения даст ошибочный (в частном случае бесполезный) результат.
KISS
Будь проще (Keep it stupid simple)Чем проще код, логика и общая реализация, тем понятнее и надёжнее система. Излишнее усложнение без явной выгоды таит явные проблемы.
YAGNI
Вам это не нужно (You aren't gonna need It)Не нужно делать функционал, который не нужен прямо сейчас. Это позволяет сэкономить ресурсы, высвободить время, набрать опыта использования и сформировать более предметные требования для доработки системы.
DRY
Не повторяйся (Don't repeat yourself)Если есть несколько одинаковых кусков функционального кода, то нужно его переносить в общую функцию (класс, метод, трейт и другие элементы языка). Так легче вносить изменения, потому что экономится время и снижаются косяки. Аналогично не только с кодом, но и с другими вещами, например, с логикой – если есть одинаковые объекты, то можно попытаться выделить их них общую абстракцию.
SoC
Разделение забот (Separation of Concerns)Разработчик не должен писать программу как единый блок, а должен разбивать код на части и так, чтобы каждая часть выполняла отдельную простую работу.
Для функций - если вы понимаете, что используемая функция становится слишком объемной и принимает слишком много аргументов, то ее следует разделить на более мелкие функции. Ключом к успешному разделению функций является обнаружение перенагруженности и путаницы.
LOD
Закон Деметры, принцип наименьшего знания (Law of Demeter)Закон Деметры гласит, что нужно укорачивать связи (уменьшать знания) между объектами, взаимодействуя только со своими ближайшими друзьями, а не с друзьями друзей.
В более строгом виде закон описывается так:
Объект A может вызывать методы объекта B, но объект A не должен через объект B получать доступ к объекту C, чтобы вызывать методы объекта C. Иначе это будет вести к тому, что объекту A потребуется больше знаний о внутренней структуре объекта B и приведёт к нарушению закона.
BDUF
Сперва детальное проектирование (Big design up front)Подход призывает перед разработкой досконально продумать весь функционал и сделать детальный проект программной системы. Затем можно переходить к реализации – программированию, тестированию, отладке и так далее.
PoC
Проверка концепции (Proof of concept)Подход призывает выполнить задание – выяснить осуществима ли задумка, будет ли она достигать заявленные цели, сколько времени, людей и финансовых затрат потребуется на реализацию. На выходе должен получиться отчёт, презентация или иной документ с описанием итогов проверки концепции.
MPV
Минимальный жизнеспособный продукт (Minimal viable product)Пригодный для использования продукт, в котором реализованы основные функции и который был сделан для получения обратной связи от пользователей. MVP используется, когда хочется быстрее опробовать продукт и понять в какую сторону двигаться дальше.
Бритва Оккама
Не следует множить сущее без необходимости (Occam's razor)Философский принцип, который применим всюду. Он значит, что среди конкурирующих гипотез следует выбирать ту, которая наиболее простая и которая несёт наименьшее количество новых предположений.
APO
Избегайте преждевременной оптимизации (Avoid premature optimization)Не нужно заниматься оптимизацией на ранних этапах разработки проекта. Это вам поможет сконцентрироваться на реализации общей концепции проекта и не позволит утопать в технических деталях.
POLA
Принцип наименьшего удивления (Principle of least astonishment)Код не должен удивлять другого разработчика. А значит, что при прочих равных код желательно делать простым, понятным (включая названия переменных, методов, классов и т.п.) и написанным по рекомендациям, например, PSR (см. статью «Перевод рекомендаций по стандартам PSR-1, PSR-4 и PSR-12»).
DIE
Дублирование – это зло (Duplication is evil)Дублируемого кода в долгосрочной перспективе обходится дороже и несёт больше рисков, чем его переделка. Для решения проблемы см. выше принцип DRY (не повторяйся).
GIGO
Если мусор на входе, то будет мусор и на выходе (Garbage in, garbage out)В проектировании это значит, что достоверность анализа и его результатов зависит от качества входных данных. В программировании подход означает, что ввод ошибочного значения даст ошибочный (в частном случае бесполезный) результат.