Scroll to top
Качественное создание и продвижение сайтов To-Dev.Ru

Основные принципы программирования


SirAix - 09.06.2018 - 0 комментариев

KISS («Keep it simple, stupid»)

Принцип KISS утверждает, что большинство систем работают лучше всего, когда они остаются простыми,без усложнений. Поэтому в области проектирования простота должна быть одной из ключевых целей, и следует избегать ненужной сложности.

Этот принцип лучше всего иллюстрируется историей, когда Кларенс Джонсон вручил команде инженеров-конструкторов несколько инструментов, бросив им вызов с тем, что реактивный самолёт, который они проектировали, должен быть ремонтируемым для среднего механика в поле в боевых условиях только с этими инструментами. Таким образом, «stupid» относится к отношению между тем, что всё ломается, и сложностью необходимого для этого ремонта.

 

DRY («Don’t repeat yourself»)

Принцип разработки программного обеспечения, нацеленный на снижение повторения информации различного рода, особенно в системах со множеством слоёв абстрагирования. Принцип DRY формулируется как: «Каждая часть знания должна иметь единственное, непротиворечивое и авторитетное представление в рамках системы»

Этот принцип сформировали Энди Хант и Дэйв Томас

Интересный момент: Нарушения принципа DRY называют WET — «Write Everything Twice» (Пиши всё по два раза) или «We enjoy typing» (Нам нравится печатать)

YAGNI («You aren’t gonna need it»)

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

Согласно адептам принципа YAGNI, желание писать код, который не нужен прямо сейчас, но может понадобиться в будущем, приводит к следующим нежелательным последствиям:

  • Тратится время, которое было бы затрачено на добавление, тестирование и улучшение необходимой функциональности.
  • Новые функции должны быть отлажены, документированы и сопровождаться.
  • Новая функциональность ограничивает то, что может быть сделано в будущем, — ненужные новые функции могут впоследствии помешать добавить новые нужные.
  • Это приводит к тому, что программное обеспечение становится более сложным (подчас чрезмерно сложным).
  • Добавление новой функциональности может привести к желанию ещё более новой функциональности, приводя к эффекту «снежного кома».

 

Чем хуже, тем лучше — подход к разработке программного обеспечения, объявляющий простоту реализации и простоту интерфейса более важными, чем любые другие свойства системы.

  1. Простота: реализация и интерфейс должны быть простыми. Простота реализации даже несколько важнее простоты интерфейса. Простота — самое важное требование при выборе дизайна.
  2. Правильность: дизайн должен быть правильным во всех видимых проявлениях. Простой дизайн немного лучше, чем правильный.
  3. Логичность (последовательность): дизайн не должен быть слишком нелогичным. Иногда можно пожертвовать логичностью ради простоты, но лучше отказаться от тех частей дизайна, которые полезны лишь в редких случаях, чем усложнить реализацию или пожертвовать логичностью.
  4. Полнота: дизайн должен охватывать как можно больше важных ситуаций. Полнотой можно жертвовать в пользу остальных качеств и обязательно нужно жертвовать, если она мешает простоте. Логичностью можно жертвовать в пользу полноты, если сохраняется простота (особенно бесполезна логичность интерфейса).

MIT (Massachusetts Institute of Technology)  – противопоставляется описанному подходу выше:

  1. Простота: реализация и интерфейс должны быть простыми. Простота интерфейса важнее простоты реализации.
  2. Правильность: дизайн должен быть правильным во всех отношениях. Неправильный дизайн категорически запрещён.
  3. Логичность так же важна, как и правильность. Ради логичности можно жертвовать простотой и полнотой.
  4. Полнота: дизайн должен охватывать как можно больше важных ситуаций. Все вероятные ситуации должны быть предусмотрены. Простота не должна слишком мешать полноте.

Ричард П. Гэбриел утверждает, что подход «чем хуже, тем лучше» предпочтительнее «подхода MIT». Простая в реализации система будет легко перенесена под разные операционные системы, то есть быстро распространится ещё до того, как система, сделанная по принципам MIT, будет написана. Более простая в реализации система привлечёт больше пользователей, понимающих, как она работает и желающих её улучшить. Улучшения будут продолжаться, пока система не станет почти идеальной.

 Эти стили описаны Ричардом П. Гэбриелом (Richard P. Gabriel) в работе «Lisp: Good News, Bad News, How to Win Big»

Пара подводящих советов от Filip Hanik (Senior Software Engineer в VMware):

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

Похожие записи

Добавить комментарий