Принципы программирования. Best Practices

1.

Принципы программирования
Best Practices

2.

Принципы программирования
KISS
Всем известный принцип простоты (с английского — Keep It Simple, Stupid) критически важен для всех проектов
среднего уровня сложности. Если у вас закралась мысль, что ваш код может стать проще, выполните это
упрощение. При этом не забывайте выполнять все работы начиная с малого, плавно переходя к сложным
задачам (дабы не создавать себе массу технических неприятностей).
Когда вы начинаете писать код, делайте его простым и удобным в дальнейшем использовании. Сложный
программный код требует массу времени для создания, да и появления багов в нем на порядок выше, нежели в
простом коде.
DRY
Принцип «без повторов» (с английского — Don’t Repeat Yourself) является фундаментальным фактором при
создании простого и читаемого программного кода. Во время написания кода нужно избегать дублирования
информации и логики. Если вы поняли, что какой-либо фрагмент кода встречается снова и снова, данный
принцип был нарушен!

3.

Принципы программирования
WET
Полной противоположностью DRY-кода является WET-код (с англ. – Write Everything Twice / We Enjoy Typing),
который говорит о том, что программные компоненты можно и нужно дублировать. Самый хороший способ
диагностировать WET-код — задать самому себе вопрос, каким образом можно изменить поведение ПО, сколько
функциональных частей можно изменить и к чему это может привести?
OPEN/CLOSED
Программный код должен быть максимально открытым для имплементации новых сфер, но закрытым для
редактирования, вне зависимости от того, создаете ли вы объекты на Java или совокупность модулей на Python.
Подобный принцип относится ко всем типам проектов. Он также крайне важен при релизе библиотек или
системных структур, которые предназначаются для применения сторонними пользователями.

4.

Принципы программирования
ПРИНЦИП ЕДИНОЙ ОТВЕТСТВЕННОСТИ
Данный принцип означает, что каждый используемый класс и модуль в программном обеспечении должен
заниматься исключительно одним набором определенных функций. Все модули и классы создаются только на
основе этого принципа. Так как функционал постоянно расширяется, они превращаются в модули и классы,
которые могут всё, но при этом занимают много сотен строк кода.
Если вы всё же столкнулись с подобным, разбивайте классы на мелкие составные части и модули.
КЛАССИФИКАЦИЯ «ИНТЕРЕСОВ»
Principle of interest sharing — это принцип единой ответственности, но при более абстрактных ситуациях. По
факту, программное обеспечение должно быть разработано таким образом, чтобы оно содержало массу
неперекрывающихся инкапсуляций, а эти инкапсуляции не могли функционировать между собой.
Другими словами, этот принцип максимально упрощает техническое обслуживание ПО со стороны компании по
обеспечению качества. И в будущем, когда вам нужно будет переписать программный код, вы легко сможете это
сделать, не боясь за целостность и сохранность информации и логики

5.

Принципы программирования
YAGNI
You aren’t gonna need it (с англ. — вам это не понадобится). Этот принцип базируется на том, что пользователю
не нужно разрабатывать определенную функциональность, которая может быть понадобится ему в будущем.
Скорее всего, программисту данный функционал не потребуется, и это будет банальная трата времени, что
дополнительно усложнит программный код.
Порой неопытные программисты пробуют создать общий, абстрактный код, дабы не сталкиваться с WET-кодом.
Но слишком внушительная абстракция заканчивается тем, что его невозможно будет поддерживать в недалеком
будущем. Разумность заключается в том, чтобы использовать принцип DRY только тогда, когда это крайне
необходимо.

6.

Best Practices
Осмысленные имена. Называйте объект так, чтобы название соответствовало его
функционалу и назначению
Повторное использование и гибкость. Различные модули приложения должны легко
повторно использоваться в контексте одного проекта или легко переноситься в другой
проект.
Единая ответственность. Любая сущность должна отвечать за один и только один
функционал.
Простота. Код должен быть таким, чтобы через некоторое время, открыв его, и вы, и
любой другой человек легко могли понять смысл написанного.

7.

Best Practices
Дальновидность и ошибки. Пиши свой код со взглядом в будущее, чтобы избежать
дорогостоящих ошибок и багов, вызванных позже в процессе разработки.
"Магические числа" должны быть помещены в константы.
Функции и аргументы. Функция не должна принимать большое количество аргументов.
Если аргументов слишком много, это может указывать на необходимость еще одной
функции.

8.

Best Practices - Функции
Избегайте передачи boolean в функцию. Это намек на то, что код выполняет несколько
действий, а это нехорошо.
Функции должны или делать что-то или отвечать на что-то, а не одновременно обе задачи.
Это гарантирует, что со временем не вылезут скрытые побочные эффекты. Например, функция
isPresent() должна возвращать только bool и ничего более не выполнять.
Для обработки исключений и для возврата кодов ошибок используйте только блоки try-catch.
Остерегайтесь выходных аргументов. Функция должна (если должна) изменить состояние своего
объекта-родителя.
Код всегда должен быть разделен пустой строкой, чтобы объединить логические блоки вместе.
Реализация функции всегда должна следовать за ее вызовом.
Не возвращайте значение null

9.

Best Practices
Объекты и структуры данных
Переменные должны быть private, чтобы можно было изменять их тип или реализацию, когда это
потребуется. Используйте геттеры и сеттеры.
Сокрытие реализации. Тебе следует не раскрывать детали данных, а скорее выражать данные в
виде абстрактных терминов.
Исключения
Возвращайте исключения вместо кодов ошибок.
Каждое созданное исключение должно обеспечивать достаточный контекст для определения
источника и местоположения ошибки – конкретизируйте, и вам же будет проще.

10.

Best Practices - Комментарии
Действительно хороший комментарий – это комментарий, в наличии которого нет
необходимости.
Не используй комментарий, если можно придумать хорошее и понятное имя для функции
или переменной.
Любой комментарий, заставляющий искать смысл происходящего в другом куске кода или
модуле, не должен существовать

11.

Best Practices - Организация кода
Каждый блок кода должен нести смысловую нагрузку. Эти блоки должны быть отделены
друг от друга пустыми строками.
Локальные переменные должны быть объявлены как можно ближе к их использованию.
Переменные экземпляра должны быть объявлены в верхней части класса, так как в
хорошо спроектированном классе они будут использоваться несколькими методами.
Если одна функция вызывает другую, вызывающая должна быть выше вызываемой (если
это возможно). Это придает программе естественный поток.