Post main image

DRY

Don’t repeat yourself — это принцип разработки программного обеспечения, нацеленный на снижение повторения информации различного рода, особенно в системах со множеством слоёв абстрагирования. Принцип DRY формулируется как: «Каждая часть знания должна иметь единственное, непротиворечивое и авторитетное представление в рамках системы». Этот принцип применяется к схемам баз данных, планам тестирования, сборкам программного обеспечения, даже к документации. Когда принцип DRY применяется успешно, изменение единственного элемента системы не требует внесения изменений в другие, логически не связанные элементы. Те элементы, которые логически связаны, изменяются предсказуемо и единообразно. Помимо использования методов и функций в коде, Томас и Хант считают необходимым использование генераторов кода, автоматических систем компиляции.

Бритва Оккама

Что может быть сделано на основе меньшего числа предположений, не следует делать, исходя из большего. По А. Эйнштейну - «Всё следует упрощать до тех пор, пока это возможно, но не более того».

KISS

Принцип, запрещающий использование более сложных средств, чем необходимо.

  • Разбивайте задачи на подзадачи которые не должны по вашему мнению длиться более 4-12 часов написания кода
  • Разбивайте задачу на множество более маленьких задач, каждая задача должна решаться одним или парой классов
  • Сохраняйте ваши методы маленькими. Каждый метод должен состоять не более чем из 30-40 строк. Каждый метод должен решать одну маленькую задачу, а не множество случаев. Если в вашем методе множество условий, разбейте его на несколько. Это повысит читаемость, позволит легче поддерживать код и быстрее находить ошибки в нем. Вы полюбите улучшать код.
  • Сохраняйте ваши классы маленькими. Здесь применяется та же техника что и с методами.
  • Придумайте решение задачи сначала, потом напишите код. Никогда не поступайте иначе. Многие разработчики придумывают решение задачи во время написания кода и в этом нет ничего плохого. Вы можете делать так и при этом придерживаться выше обозначенного правила. Если вы можете в уме разбивать задачу на более мелкие части, когда вы пишете код, делайте это любыми способами. И не бойтесь переписывать код еще и еще и еще… В счет не идет число строк, до тех пор пока вы считаете что можно еще меньше/еще лучше.
  • Не бойтесь избавляться от кода. Изменение старого кода и написание нового решения два очень важных момента. Если вы столкнулись с новыми требованиями, или не были оповещены о них ранее, тогда порой лучше придумать новое более изящное решение решающее и старые и новые задачи.

YAGNI

Процесс и принцип проектирования ПО, при котором в качестве основной цели или ценности декларируется отказ от избыточной функциональности, — то есть отказ добавления функциональности, в которой нет непосредственной надобности.