Доброго времени суток, читатель! Хочу поделиться небольшой статье посвященной самым известным принципам разработки программного обеспечения. Статья будет полезна скорее для начинающих разработчиков, потому что опытные вряд ли найдут здесь что-то новое. Но и новичкам тоже нужно что-то читать.
Принципы разработки ПО — это набор определенных правил и рекомендаций, которым нужно следовать при написании исходного кода программы, если хочешь написать красивый, понятный и легко редактируемый код. То есть, не существует волшебной палочки, с помощью которой можно было бы превратить мешанину из переменных, классов и методов в идеальный листинг, но существуют некоторые подсказки, которые помогают программисту определить, все ли правильно он делает. Давайте рассмотрим эти основные рекомендации.
Don’t Repeat Yourself (DRY) — Не повторяйся!
Достаточно простой, но при этом очень полезный принцип, который говорит, что повторение одного и того же кода в нескольких местах — очень плохая идея. Это связано в первую очередь с необходимостью дальнейшего поддержания и изменения кода. Если какой-то определенный кусок листинга повторяется в нескольких местах программы, то велика вероятность возникновения двух плачевных ситуаций:
- При необходимости внести даже малейшие исправления в исходный код, вам придется заглянуть во все места где он используется, что потребует дополнительных затрат времени и сил
- Из первого пункта вытекает второй, вы или другой разработчик может случайно пропустить одно из исправлений и столкнуться с последующими ошибками в работе приложения
В связи с этим есть рекомендация, если какой-либо код встречается в листинге более двух раз, то его нужно выносить в отдельный метод. Это общая рекомендация, на самом деле нужно задуматься о выделении метода даже если вы встречаете повторение второй раз.
Occam’s Razor (OR) — Бритва Оккама
Очень распространенная идея, которая пришла в программирование из философии. Принцип получил свое имя в честь английского монаха Уильяма из Оккама. Данный принцип гласит следующее: «Не следует множить сущее без необходимости». В сфере программирования, это правило трактуется следующим образом — не нужно создавать лишние сущности без необходимости в них. То есть, всегда задумывайтесь над тем, получите ли вы выгоду выделив дополнительный класс или метод. Ведь если вы будете выделять в отдельный метод одну строчку, которая при этом еще и нигде больше не повторяется, то только запутаете и усложните свой код.
Keep It Simple Stupid (KISS) — Делай это проще
Схожий с предыдущим пунктом принцип, но имеющий немного другую смысловую нагрузку. Данная рекомендация говорит, что код нужно писать простым, без сложных конструкций, так как в противном случае это может значительно усложнить поддержание и отладку. Кроме того, другому программисту будет намного сложнее разобраться в хитросплетениях и сложных ветвлениях листинга, что тоже потребует дополнительных затрат сил и времени. Поэтому всегда старайтесь использовать простые и логичные конструкции без глубокой вложенности, так вы упростите жизнь и себе, и коллегам.
You Aren’t Gonna Need It (YAGNI) — Тебе это не понадобится
Проблема которой страдают многие программисты. Стремление разработать сразу весь потенциально необходимый (а иногда даже ненужный) функционал с самого начала процесса разработки. То есть, когда разработчик с самого начала добавляет все возможные методы в класс и реализует их, при этом в дальнейшем может даже ни разу ими и не воспользоваться. Поэтому согласно этой рекомендации, разрабатывайте только то, что вам необходимо в первую очередь, а в дальнейшем при необходимости наращивайте функциональные возможности. Так вы сэкономите многоженство сил, времени и нервов на отладку кода, который на самом деле не нужен.
Big Design Up Front (BDUF) — Масштабное проектирование прежде всего
Это противоположный предыдущему принцип, который гласит, что перед тем, как приступать к разработке необходимо заранее продумать и спроектировать всю информационную систему вплоть до достаточно мелких деталей, и только после этого приступать к реализации по заранее подготовленному плану. Принцип имеет право на существование, но в последнее время встречается достаточно много его критики. В первую очередь это связано с устареванием плана за время проектирования и разработки. В связи с чем все равно приходится вносить последующие изменения. Но у него есть и неопровержимые плюсы, при грамотном проектировании можно значительно сократить затраты на дальнейшую отладку и исправление багов. Кроме того, такие информационные системы обычно получаются более лаконичными и архитектурно правильными.
Avoid Premature Optimization (APO) — Избегайте преждевременной оптимизации
Оптимизация — очень правильный и необходимый процесс, который позволяет ускорить работу программы, а также снизить потребление системных ресурсов. Но всему свое время. Если оптимизация проводится на ранних этапах разработки, то она может принести больше вреда чем пользы. Это в первую очередь связано с тем, что на разработку оптимизированного кода необходимо затрачивать больше времени и сил разработчика. При этом достаточно часто необходимо сначала удостоверится в правильности выбранного подхода разработки. Поэтому вначале выгоднее использовать простые, но при этом не самые оптимальные решения. А в дальнейшем, оценив как сильно замедляет работу приложения этот участок кода, выполнить изменение на более быстрый или менее ресурсоемкий алгоритм. Кроме того, за то время пока вы будите изначально реализовывать самый оптимальный алгоритм, требования могут измениться и код отправится в помойку. Так что не нужно тратить время на преждевременную оптимизацию.
Principle Of Least Astonishment (POLA) — Принцип наименьшего удивления
Данный принцип гласит, что ваш исходный код должен быть интуитивно понятен, очевиден, и как можно меньше удивлять другого программиста, во время чтения листинга. Это означает, что если в метод называется «Сделать автомобиль», а в результате получается мотоцикл, это плохая идея и плохой код. На самом деле я сейчас конечно утрирую, но в любом случае, ваши методы должны делать только то, что можно понять из их названия. А имена должны быть наиболее как можно более информативными, но при этом лаконичными. Не нужно писать в имя переменно целое предложение, но и называть ее одной буквой тоже не стоит. Стремитесь к тому, чтобы написанный вами код можно было читать как книгу.
Law of Demeter (LOD) — Закон Деметры
Основная идея данного закона состоит в разделении областей ответственности между классами и сокрытием внутренней структуры от внешней среды. То есть, каждый класс должен стремиться к тому, чтобы быть максимально самостоятельными и обособленным от остальных классов, а при необходимости взаимодействовать только с необходимыми другими классами «друзьями». Из этого закона можно выделить несколько рекомендаций:
- Классы должны быть самостоятельными
- Нужно стараться сократить количество связей между различными классами
- Классы должны быть выстроены иерархически
По поводу последнего пункта можно привести пример, из жизни. Для того, чтобы заставить собаку побежать, не нужно обращаться отдельно к каждой ее лапе. Достаточно отдать команду собаке, а она уже сама все сделает, чтобы прибежать к вам.
Благодаря соблюдению данного принципа приложения становится более гибким и понятным.
Заключение
Здесь я перечислил основные принципы которым следует придерживаться при разработке исходного кода программного обеспечения. При их соблюдении ваш код должен стать более гибким, легко поддерживаемым и удобочитаемым. Но при этом обязательно помните, что все хорошо в меру, и чрезмерное использование данных принципов может принести больше вреда, чем пользы.
Источник: CODE BLOG
Автор: Вадим
