Глобальное проектирование впереди разработки.
Прежде чем переходить к реализации, созданию проекта, необходимо убедиться, что все хорошо продумано.
Концептуальные решения и возможные нюансы лучше обсудить как с заказчиками, так и с членами группы разработки, до начала действий.
Это позволит минимизировать непонимание внутри команды разработки. Снизит вероятность выбора неверных подходов и инструментов для решения задачи.
Делай короче и проще / не усложняй, тупица.
Этот принцип был разработан ВМС США в 1960 году, и он гласит, что простые системы будут работать лучше и надежнее.
Применительно к разработке он значит следующее – не придумывайте к задаче более сложного решения, чем ей требуется.
Одна из самых распространенных ошибок нашего времени – использование разработчиками новых инструментов исключительно из-за того, что они на хайпе. Новейшие технологии следует применять не потому, что они новые, а потому что они подходят для работы.
Не повторяйте себя.
Прежде чем что-либо писать, проявите прагматизм - осмотритесь. Возможно, эта функция уже где-то реализована, и эта бизнес-логика существует в другом месте. Повторное использование кода – всегда разумное решение.
Этот принцип разработки программного обеспечения, нацелен на снижение повторения информации различного рода, особенно в системах со множеством слоёв абстрагирования.
Эта концепция была впервые сформулирована в книге Энди Ханта и Дэйва Томаса «Программист-прагматик: путь от подмастерья к мастеру» в следующем виде: «Каждая часть знания должна иметь единственное, непротиворечивое и авторитетное представление в рамках системы».
Вам это не понадобится.
Если пишете код, то будьте уверены, что он вам понадобится. Не пишите код, если думаете, что он пригодится позже. Вам следует реализовывать новую функциональность и писать код тогда, когда в нем возникает необходимость.
Избыточная функциональность в коде усложняет его понимание. К тому же, достаточно сложно проверить правильность функционирования тех частей кода, которые не используются или функциональность которых четко не сформулирована.
Single responsibility - принцип гласит, что объекты и классы (а также функции и методы) нужно организовывать так, чтобы каждый из них имел только одну зону ответственности. Если ваш объект/класс/метод делает слишком много, вы получите спагетти-код.
Open-closed - принцип открытости/закрытости означает, что программные сущности(классы, интерфейсы и т. д.) должны быть открыты для расширения, но закрыты для модификации.Если вам понадобилось добавить дополнительный функционал, то необходимо создать наследника этого класса или использовать композицию. Но, изменять исходный класс запрещено. Это необходимо, что-бы не испортить код, использующий этот класс.
Liskov substitution - принцип гласит, что поведение методов в дочернем классе должно следовать принципам базового класса, а не изменять их. То есть, дочерний класс переопределяя методы или переменные, не должен менять заложенную логику базового класса.
Interface segregation - принцип разделения интерфейса, лучше создавать много отдельных узкоспециализированных интерфейсов, чем один, который включает в себя много функций. Это позволит сделать архитектуру более гибкой, и использовать интерфейсы при необходимости по отдельности.
Dependency Inversion - принцип инверсии зависимостей служит для создания слабосвязанных сущностей, которые легко тестировать, модифицировать и обновлять. Модули верхних уровней не должны зависеть от модулей нижних уровней. Если по простому, то нужно делать код так, что-бы этот код имел как можно меньше зависимостей и не было круговых зависимостей