Принципы, используемые в программировании.
YAGNI
Принцип «YAGNI» (англ. You Ain't Gonna Need It — «Вам это не понадобится») — процесс и принцип проектирования, при котором в качестве основной цели и/или ценности декларируется отказ от избыточной функциональности, — т.е. отказ добавления функциональности, в которой нет непосредственной надобности. Согласно адептам принципа YAGNI, желание писать код, который не нужен прямо сейчас, но может понадобиться в будущем, приводит к следующим нежелательным последствиям:
· Тратится время, которое было бы затрачено на добавление, тестирование и улучшение необходимой функциональности.
· Новые функции должны быть отлажены, документированы и сопровождаться.
· Новая функциональность ограничивает то, что может быть сделано в будущем, — ненужные новые функции могут впоследствии помешать добавить новые нужные.
· Пока новые функции действительно не нужны, трудно полностью предугадать, что они должны делать, и протестировать их. Если новые функции тщательно не протестированы, они могут неправильно работать, когда впоследствии понадобятся.
· Это приводит к тому, что программное обеспечение становится более сложным (подчас чрезмерно сложным).
· Если вся функциональность не документирована, она может так и остаться неизвестной пользователям, но может создать для безопасности пользовательской системы различные риски.
· Добавление новой функциональности может привести к желанию ещё более новой функциональности, приводя к эффекту «снежного кома».
KISS
KISS (англ. keep it simple, stupid — «не усложняй, тупица» или более вежливый вариант англ. keep it short and simple — «делай короче и проще») — процесс и принцип проектирования, при котором простота системы декларируется в качестве основной цели и/или ценности. Имеют хождение разные расшифровки этого акронима. Эрик Рэймонд в своей книге резюмирует философию Unix как широко используемый принцип KISS.
DRY
DRY (анг. Don’t repeat yourself, рус. не повторяйся) — это принцип разработки программного обеспечения, нацеленный на снижение повторения информации различного рода, особенно в системах со множеством слоёв абстрагирования. Принцип DRY формулируется как: «Каждая часть знания должна иметь единственное, непротиворечивое и авторитетное представление в рамках системы». Он был сформулирован Энди Хантом и Дэйвом Томасом в их книге The Pragmatic Programmer. Они применяли этот принцип к «схемам баз данных, планам тестирования, сборкам программного обеспечения, даже к документации». Когда принцип DRY применяется успешно, изменение единственного элемента системы не требует внесения изменений в другие, логически не связанные элементы. Те элементы, которые логически связаны, изменяются предсказуемо и единообразно.
Принцип DRY, известный также как Single Source of Truth (англ.), превалирует в системах с управляемой моделями архитектурой, в которых артефакты программы извлекаются из главной модели объекта и выражаются в такой форме, как UML. Код, написанный по принципу DRY, создаётся с помощью конвертации данных и генераторов кода, которые позволяют разработчику ПО избежать операций вырезания, копирования и вставки. Обычно код, написанный по этому принципу, позволяет легче управлять большими информационными системами. Такие инструменты, как XDoclet (англ.) и XSLT являются примерами техник программирования DRY.
Нарушения принципа DRY называют WET — «Write Everything Twice» (рус. Пиши всё по два раза). Это игра английских слов «dry» (рус. сухой) и «wet» (рус. влажный).
TMTOWTDI
Принцип TMTOWTDI (произносится «Тим Тоуди»), или «There’s More Than One Way To Do It» («Есть больше одного способа сделать это») — девиз языка Perl. В соответствии с этой идеей синтаксис языка предоставляет программисту множество возможностей для записи одного и того же алгоритма, позволяя выбирать ту из них, которая кажется наиболее удобной и эффективной в данном конкретном случае. С одной стороны, это упрощает написание кода — нужно знать лишь один способ из многих, с другой — усложняет чтение чужого кода, т.к. для этого нужно знать все способы, которые могут встретиться. Это делает возможным написание чрезвычайно запутанных и трудночитаемых программ, но, как утверждают сторонники принципа TMTOWTDI, позволяет в то же время проще создавать краткий, эффективный и качественный код.
«Дзэн языка Python» включает в себя обратный принцип: «There should be one—and preferably only one—obvious way to do it» («Должен быть один — и желательно только один — очевидный способ сделать это»).
Чем хуже, тем лучше
Чем хуже, тем лучше — подход к разработке программного обеспечения, объявляющий простоту реализации и простоту интерфейса более важными, чем любые другие свойства системы. Этот стиль описан Ричардом П. Гэбриелом в работе «Lisp: Good News, Bad News, How to Win Big» в разделе «The Rise of 'Worse is Better'» и часто перепечатывается отдельной статьёй.
Гэбриел описывает подход так:
1. Простота: реализация и интерфейс должны быть простыми. Простота реализации даже несколько важнее простоты интерфейса. Простота — самое важное требование при выборе дизайна.
2. Правильность: дизайн должен быть правильным во всех видимых проявлениях. Простой дизайн немного лучше, чем правильный.
3. Логичность (последовательность): дизайн не должен быть слишком нелогичным. Иногда можно пожертвовать логичностью ради простоты, но лучше отказаться от тех частей дизайна, которые полезны лишь в редких случаях, чем усложнить реализацию или пожертвовать логичностью.
4. Полнота: дизайн должен охватывать как можно больше важных ситуаций. Полнотой можно жертвовать в пользу остальных качеств и обязательно нужно жертвовать, если она мешает простоте. Логичностью можно жертвовать в пользу полноты, если сохраняется простота (особенно бесполезна логичность интерфейса).
Гэбриел считает язык C и систему Unix примерами такого подхода.
В статье ему противопоставляется подход, который называется «подход MIT» (MIT — Massachusetts Institute of Technology). Гэбриел так описывает этот подход к дизайну:
1. Простота: реализация и интерфейс должны быть простыми. Простота интерфейса важнее простоты реализации.
2. Правильность: дизайн должен быть правильным во всех отношениях. Неправильный дизайн категорически запрещён.
3. Логичность так же важна, как и правильность. Ради логичности можно жертвовать простотой и полнотой.
4. Полнота: дизайн должен охватывать как можно больше важных ситуаций. Все вероятные ситуации должны быть предусмотрены. Простота не должна слишком мешать полноте.
Гэбриел утверждает, что подход «чем хуже, тем лучше» предпочтительнее «подхода MIT». Простая в реализации система будет легко перенесена под разные операционные системы, то есть быстро распространится ещё до того, как система, сделанная по принципам MIT, будет написана. Более простая в реализации система привлечёт больше пользователей, понимающих, как она работает и желающих её улучшить. Улучшения будут продолжаться, пока система не станет почти идеальной. Как пример, Гэбриел приводит компиляторы для языков C и Лисп. В 1987 году, пишет Гэбриел, компиляторы с этих языков были почти одинаковы по качеству, но было гораздо больше желающих улучшить компилятор С, чем компилятор Лиспа (видимо, Гэбриел считает, что интерпретатор Лисп более сложный для реализации, чем компилятор C).
Хотя Гэбриел, возможно, первым сформулировал этот принцип, похожие идеи использовались гораздо раньше в идеологии UNIX и программного обеспечения с открытым кодом.
Утиный тест
Утиный тест (англ. duck-test, иногда дак-тест) — шутливый тест на очевидность происходящего. В переводе с английского выглядит как:Оно крякает как утка, плавает как утка и выглядит как утка. Вероятно, это утка. Выражение является калькой с английского и распространено в США и Великобритании.
Тест подразумевает, что сущность явления можно идентифицировать по типичным внешним признакам. В частности, «дак-тест» проводится в Википедии в целях проверки того, стоит ли за двумя или более учётными записями одна и та же личность.
Фразу впервые написал американский поэт Джеймс Уиткомб Райли (англ.) (1849—1916): Когда я вижу птицу, которая ходит как утка, плавает как утка и крякает как утка, я называю эту птицу уткой.
Бритва Оккама
Бритва О́ккама — методологический принцип, получивший название от имени английского монаха-францисканца, философа-номиналиста Уильяма Оккама (1285—1349). В кратком виде он гласит: «Не следует множить сущее без необходимости». Сам Оккам писал: «Что может быть сделано на основе меньшего числа, не следует делать, исходя из большего».
Принцип «бритвы Оккама» состоит в следующем: если некое явление может быть объяснено двумя способами: например, первым — через привлечение сущностей (терминов, факторов, фактов и проч.) А, В и С, либо вторым — через сущности А, В, С и D, — и при этом оба способа дают идентичный результат, то считать верным следует первое объяснение. Сущность D в этом примере — лишняя: и её привлечение избыточно.
Важно помнить, что бритва Оккама не аксиома, а презумпция, то есть она не запрещает более сложные объяснения в принципе, а лишь рекомендует порядок рассмотрения гипотез, который в большинстве случаев является оптимальным.
В современной науке под бритвой Оккама обычно понимают общий принцип, утверждающий, что если существует несколько логически непротиворечивых объяснений какого-либо явления, объясняющих его одинаково хорошо, то следует, при прочих равных условиях, считать верным самое простое из них.
Следует обратить внимание на употреблённые выше обороты «одинаково хорошо», «при прочих равных условиях» и «исчерпывающе»: бритва Оккама требует предпочесть простое объяснение только в том случае, если оно объясняет явление не менее точно, чем сложное, учитывая весь известный на текущий момент массив наблюдений, то есть если отсутствуют объективные основания для того, чтобы предпочесть более сложное объяснение простому.
Логически бритва Оккама базируется на принципе достаточного основания, введённом ещё Аристотелем, а в современном виде сформулированном Лейбницем: утверждать существование объекта, явления, связи, закономерности и т. п. можно лишь при наличии оснований, то есть фактов или логических выводов из фактов, подтверждающих это суждение. Рассматривая простое и сложное объяснения с точки зрения этого принципа, легко увидеть, что, если простое объяснение является полным и исчерпывающим, то для введения в рассуждение дополнительных компонентов просто нет достаточных оснований. С другой стороны, если такие основания есть, значит простое объяснение уже не является полным и исчерпывающим (так как не охватывает эти основания), то есть условия для применения бритвы Оккама не выполняются.
Значение термина «бритва». В философии под термином «бритва» понимается инструмент, помогающий отбрасывать (сбривать) маловероятные, неправдоподобные объяснения. А так как инструментом для бритья является бритва, лезвие (razor), то и на инструмент установления истины было перенесено то же название.
Примеры
· Среди наиболее известных примеров применения этого принципа — ответ, который дал императору Наполеону создатель первой теории возникновения Солнечной системы математик и физик Лаплас. Наполеон спросил, почему слово «Бог», беспрерывно повторяемое Лагранжем, в его сочинении не встречается вовсе, на что Лаплас ответил: «Это потому, что я в этой гипотезе не нуждался».
· Когда ученики попросили Платона дать определение человека, философ сказал: «Человек есть животное на двух ногах, лишённое перьев». Услышав это, Диоген поймал петуха, ощипал его и, принеся в Академию, объявил: «Вот платоновский человек!». После чего Платон добавил к своему определению: «И с плоскими ногтями».
· Переформулированный на языке теории информации, принцип бритвы Оккама гласит, что самым точным сообщением является сообщение минимальной длины.
· В этом смысле Альберт Эйнштейн так сформулировал принцип бритвы Оккама: «Всё следует упрощать до тех пор, пока это возможно, но не более того».
Ментальные модели.
Ментальной моделью в психологии называют трудно формализуемую совокупность эмпирических знаний, которая формируется в сознании человека при взаимодействии с объектом. Проще говоря, это то, как мы представляем себе некий предмет. В случае с высоко-технологичными устройствами, или информационными объектами, к которым относятся, прежде всего, программное обеспечение, в такое представление входит наше понимание принципов действия системы. Так или иначе, но работая со сложным интерфейсом, мы невольно запоминаем, что он работает «примерно вот так». Далеко не всегда это представление соответствует действительности.
На самом деле пользователь не знает как написан код того или иного модуля программы или как устроена админка. Пользователю нужно решить свои задачи, так как он это понимает. Если у него не получится он просто найдет другой инструмент. Если вы не знаете, как люди используют ваш продукт не сможете понять что им нужно, не сможете его улучшить.