Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Принципы разработки программного обеспечения необходимо знать каждому инженеру, который хочет писать чистый код. Следование этим принципам позволяет вам и другим разработчикам понять проект.
Кроме того, обслуживание или изменение проекта в будущем станет легким. Таким образом, вы в конечном итоге сэкономите деньги, время и ресурсы. Если вы хотите, чтобы проект развивался более плавно, то рекомендуется жить по этим законам.
Мы хотим помочь вам внедрить чистый код. Давайте рассмотрим наиболее распространенные принципы разработки программного обеспечения.
1. Будь проще, Саймон (Keep It Simple Simon, KISS)
При написании следующего большого проекта убедитесь, что ваш код прост и понятен. Код не должен вызывать затруднений у людей при модификации или изменении.
Ваши методы должны быть небольшими, не превышающими 40-50 строк.
Каждый метод должен решать только одну проблему.
У вас в проекте много условий? Убедитесь, что вы разбили их на более мелкие блоки кода.
Always Keep It Simple, Stupid (KISS) позволяет вам и другим программистам быстро выявлять ошибки. Он также помогает вносить дальнейшие изменения в код. Это один из наиболее распространенных принципов бережливого производства в гибкой разработке программного обеспечения.
2. Вам это не понадобится (You Aren't Gonna Need It, YAGNI)
Большинство программистов с самого начала попадают в ловушку, пытаясь реализовать все функции сразу. В конце концов, часть или большинство из этих функций становятся бесполезными.
Как развивающийся разработчик программного обеспечения, всегда начинайте с добавления всего нескольких методов в класс. Когда ваш проект начнет обретать форму и возникнут новые требования, вы можете добавить больше функций. Таким образом, вы будете придерживаться принципов бережливой разработки программного обеспечения.
Этот принцип экономит время, усилия и расходы, которые тратятся впустую на попытки понять или отладить код.
3. Дважды отмерь и один раз отрежь (Measure Twice and Cut Once)
Некачественно выполненный этап написания требований обычно приводит к более чем 50% проблем в разработке. Поэтому подготовьтесь, разработав системный подход к процессу программирования.
Дважды проверьте все требования проекта, чтобы убедиться, что вы не ничего не упускаете и не добавляете лишнего в свой код. После этого сделайте наброски, которые будут направлять весь процесс для получения высококачественного кода. Всегда тестируйте свой проект с самых основ, чтобы убедиться, что все в порядке.
Этот принцип дает гораздо более предсказуемые результаты, особенно если стоимость проекта уже высока. Вы избавите себя от головной боли, связанной с удалением или добавлением строк кода в соответствии с требованиями.
4. Не повторяйся (Don’t Repeat Yourself, DRY)
При написании кода не повторяйтесь. То есть избегайте копирования кода в разные места. В противном случае дальнейшее обслуживание будет трудным. Причина в том, что вам придется изменять код в разных местах.
Эти изменения затронут и тесты, которые нужно будет починить. Для этого потребуется больше времени, усилий и денег.
Чтобы избежать этой ловушки, вы можете извлечь общую логику.
Кроме того автоматизируйте всё, что можно автоматизировать. Тогда ваш код останется бережливым.
Описанные выше шаги помогут повторно использовать код без необходимости копировать его.
5. Бритва Оккама
Создатель этого принципа - Уильям Оккам, философ 14 века. Принцип гласит, что в группе гипотез всегда выбирайте ту, которая имеет наименьшее количество предположений.
Следуя принципу бережливой разработки программного обеспечения, всегда начинайте с максимально простого кода. Затем осторожно увеличивайте сложность по мере необходимости.
Простой код позволяет легко представить, разработать, протестировать и исправить продукт на каждом этапе. Он также значительно сокращает количество ошибок, что позволяет программе работать быстрее.
6. Сначала большое проектирование (Big Design Up Front, BDUF)
Этот принцип разработки программного обеспечения утверждает, что разработчик должен сначала завершить проектирование проекта. После этого проект можно реализовать.
Сторонники утверждают, что такой подход помогает обнаруживать проблемы на стадии требований и быстро их решать.
Однако изменения в требованиях к программному обеспечению могут произойти в течение жизненного цикла проекта. Такие изменения могут вызвать трудности или даже сделать дизайн проекта устаревшим.
Один из способов решить эту проблему - сначала создать общую архитектуру. Затем необходимо разделить требования на несколько этапов в соответствии с приоритетами. В процессе разработки начните с этапа с самым высоким приоритетом, постепенно опускаясь до самого низкого. На каждом этапе используйте этот принцип перед началом разработки.
7. Избегайте преждевременной оптимизации
Дональд Кнут утверждал, что корень всего зла в программировании - преждевременная оптимизация.
Мы все согласны с тем, что оптимизация ускоряет процесс разработки и снижает потребление ресурсов. Однако она приведёт к неприятным последствиям, если вы займётесь ей слишком рано.
Причина в том, что приоритезация кода занимает много времени и значительно усложняется, если делать её не вовремя. Кроме того, в процессе реализации наиболее оптимального решения требования могут измениться. Если это произойдет, ваша программа окажется в мусорной корзине или ее будет сложно изменить.
Поэтому начните с самого простого подхода, даже если он не самый оптимальный. Затем в дальнейшем оцените выбранный метод с точки зрения затрат ресурсов и времени. Основываясь на оценке, вы можете выбрать более быстрый алгоритм, который позволит потреблять меньше ресурсов или усилий.
8. Наименьшее удивление
Принцип наименьшего удивления гласит, что желательно разработать функцию, которая не имеет высокого коэффициента удивления.
Компоненты системы должны вести себя так, как того ожидают конечные пользователи. Поэтому результаты вашего проекта будут прибыльными только в том случае, если они очевидны, предсказуемы и последовательны.В противном случае пользователи будут уклоняться от использования функций или структур, которые удивляют или сбивают их с толку.
Вы создаёте программные продукты для людей. Таким образом, вы сильно выиграете от разработки удобных для пользователя функций. Стремитесь соответствовать ментальным моделям, опыту и ожиданиям людей.
Помните, что вы должны привлечь внимание пользователя как можно быстрее. Насколько нам известно, объем внимания современных пользователей резко упал.
9. Закон Деметры
Закон Деметры пытается разделить обязанности между классами и уменьшить связанность между ними.
Настоятельно рекомендуется:
Обеспечить независимость программных объектов друг от друга.
Уменьшить общение или связь между разными классами.
Поместить связанные классы в один и тот же пакет, модуль или каталог для достижения согласованности.
Следование этой идее позволит вашему приложению быть более удобным в обслуживании, понятным и гибким.
10. S.O.L.I.D
Это аббревиатура обозначает пять принципов объектно-ориентированного программирования и дизайна.
S - Single Responsibility Principle (SRP) - Принцип единой ответственности.
O - Open/Closed Principle (OCP) - Принцип открытия / закрытия.
L - Liskov Substitution Principle - Принцип замещения Лискоа.
I - Interface Segregation Principle - Принцип разделения интерфейса.
D - Dependency Inversion Principle - Принцип инверсии зависимостей.
Давайте кратко рассмотрим каждый из этих принципов
Принцип единой ответственности (SRP)
Это принцип разработки программного обеспечения, который гласит, что класс должен иметь только одну причину для изменения. Другими словами, у него должна быть только одна ответственность.
Здесь мы говорим о связанности. Все элементы в структурах или модулях данного класса должны иметь функциональное родство друг с другом. Чётко определив ответственность своего класса, вы повысите его связанность.
Принцип открытости / закрытости (OCP)
Принцип гласит, что вы должны иметь возможность изменять поведение класса, не изменяя сам класс.
Следовательно, вы можете расширить поведение класса за счет композиции, интерфейса и наследования. Однако вы не можете открыть класс для незначительных изменений.
Принцип замещения Лисков (LSP)
В своей исследовательской работе 1988 года Барбара Лисков заявила, что производные классы должны быть заменены их базовыми классами. Таким образом, вам нужно проявлять осторожность при использовании наследования в проекте.
Хотя наследование выгодно, рекомендуется использовать его в контексте и умеренно. Принцип направлен на предотвращение случаев, когда классы расширяются только за счет общих вещей.
Перед выполнением наследования необходимо учитывать предварительные условия класса.
Принцип разделения интерфейса (ISP)
ISP предпочитает много конкретных интерфейсов одному общему. Цель состоит в том, чтобы иметь гранулярные и специфичные для клиента интерфейсы.
Вам необходимо повысить связанность в интерфейсах и разработать бережливые модули - с малым количеством поведения.
Интерфейсы с множеством поведений сложно поддерживать и развивать. Так что вам следует избегать их.
Принцип инверсии зависимостей (DIP)
Принцип утверждает, что программисты должны полагаться на абстракции, а не на конкретные классы. Мы можем разбить это на две части:
Модули высокого уровня должны быть независимыми от модулей низкого уровня. И те, и другие должны зависеть от абстракций
Абстракции не должны зависеть от деталей реализации. Детали должны зависеть от абстракций.
Итак, в чем причина этого принципа? Ответ состоит в том, что абстракции мало меняются. Следовательно, вы можете легко изменить поведение вашего приватного или публичного кода. Таким образом, вы ускорите его дальнейшую эволюцию.
Заключение
У каждого профессионала должны быть руководящие принципы. Подобные принципы способствуют единству среди профессионалов в обслуживании своих клиентов. Как благородная область деятельности, разработка программного обеспечения не должна оставаться в стороне.
Инженеры-программисты сделают себе одолжение, придерживаясь вышеуказанных принципов разработки и проектирования программного обеспечения. Таким образом вы сможете более эффективно обслуживать своих клиентов и сотрудничать с другими инженерами.
Для вас подготовил перевод Никита Ульшин, Team Lead & JS-разработчик, веду блог ulshin.me и ТГ-канал @ulshinblog.
Комментарии, пожелания и конструктивная критика приветствуются :)
