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