UNIX.Разработка.Уроки

Ожидайте, что выходные данные каждой программы станут входными данными для другой, пока неизвестной программы.

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

Вы не знаете, где программа будет проводить своё время. Узкие места встречаются в неожиданных местах, поэтому не пытайтесь преждевременно оптимизировать скорость, пока не упрётесь в узкое место.

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

Правила 6 не существует.

Если есть сомнения, используйте грубую силу.

Модульность: создавайте простые части, соединенные чистыми интерфейсами.

Брайан Керниган, «Управление сложностью —  сущность компьютерного программирования»

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

Ясность лучше, чем ум

Обслуживание важно и дорого — пишите программы, как если бы самая важная миссия, которую они делают, — это не компьютер, который их выполняет, а люди, которые будут читать и поддерживать исходный код в будущем (включая вас).

Увеличения производительности при увеличении сложности — плохая сделка — сложный код с большей вероятностью скрывает ошибки.
Код изящный и понятный, с меньшей вероятностью будет нарушен — и, скорее всего, его быстро поймёт  следующий.

Композиция: разрабатывать программы, связанные с другими программами.

Традиция Unix настоятельно рекомендует писать программы, которые читают и пишут простые текстовые, ориентированные на поток, независимые от устройства форматы.

Отделить политику от механизма; отдельные интерфейсы от двигателей.

Бизнес-логика меняется гораздо быстрее, чем механизм. Моды внешнего вида и инструментария могут приходить и уходить, но компоновка — навсегда.
Разделяя их, позволяем экспериментировать с новой политикой, не нарушая механизмов, облегчаем написание хороших тестов.

Дизайн простой, сложность только там, где нужно.

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

Чрезмерная сложность возникает из-за требований маркетинга, а не на реальности того, что программное обеспечение может на самом деле предоставить. Многие хорошие дизайны были задушены кучей «функций контрольного списка» маркетинга — функций, которые зачастую ни один клиент никогда не использует.
Замкнутый круг; конкуренция считает, что она должна конкурировать с хромом, добавляя больше хрома.
Довольно скоро массовое раздувание станет отраслевым стандартом, и все используют огромные, глючные программы.
В итоге все проигрывают.
Способ избежать ловушек в том, чтобы поощрять культуру программного обеспечения, которая знает, что маленький — это красиво, активно противостоит раздутию и сложности: инженерная традиция ценит простые решения и ищет способы разбить программные системы на маленькие сотрудничающие части, и это рефлексивно борется с попытками смешать программы с большим количеством хрома (или, что еще хуже, разрабатывать программы вокруг хрома).

Скупость: пишите большую программу только, когда ясно, что больше ничего не поделаешь.

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

Прозрачность: упростить проверку и отладку.

Работа, проделанная на ранних этапах для облегчения отладки, окупится сторицей. Особенно эффективный способ облегчить отладку — создать прозрачность и возможность обнаружения.
Когда вы можете посмотреть на неё и сразу понять, что она делает и как.

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

Робастность — дитя прозрачности и простоты.

Большая часть программного обеспечения хрупкая и глючная, потому что большинство программ слишком сложны для человеческого мозга, чтобы понять всё сразу.
Важно применять бессмысленную генерацию ввода при тестировании, что кажется бесполезным, даже в неочевидных местах.
Ошибки часто скрываются в коде для обработки особых случаев.
Просто = когда можно рассуждать обо всех потенциальных случаях без напряжения.

Представьте знания наглядно = логика должна быть глупой и надёжной.

Даже простейшую процедурную логику людям сложно проверить, но довольно сложные структуры данных довольно легко моделировать и рассуждать.
Сравните выразительность и объяснительную силу диаграммы дерева указателей из пятидесяти узлов с блок-схемой программы из пятидесяти строк.
Или сравните инициализатор массива, выражающий таблицу преобразования, с эквивалентным оператором switch.
Разница в прозрачности и ясности драматична.

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

Принцип наименьшего удивления.

Наиболее простыми в использовании являются те программы, которые наиболее эффективно соединяются с ранее существовавшими знаниями пользователя.
Избегайте необоснованной новизны и излишней сообразительности в дизайне интерфейса.
Традиции: формат файлов конфигурации и управления запуском, параметры командной строки и тому подобные, существуют по уважительной причине: приручить кривую обучения.

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

Когда программе нечего сказать, она ничего не должна сказать.

Одно из старейших и наиболее постоянных правил проектирования Unix: когда программе нечего сказать интересного или удивительного, её следует закрыть . Хорошо ведущие себя программы выполняют свою работу незаметно, с минимумом суеты и беспокойства. Молчание — золото.
Причины для краткости остаются.
Краткость Unix-программ является центральной чертой стиля.
Необходимость человеческого фактора — важная информация не должна смешиваться с многословием внутреннего поведения программы. Чтобы важную информацию легко найти.
Хорошо продуманные программы рассматривают внимание и концентрацию пользователя как ценный и ограниченный ресурс, который требуется только в случае необходимости.

Ошибки показывайте рано, шумно и быстро.

Диагностику делайте простой.

Время программиста стоит дорого.

Если бы мы действительно серьезно относились к этому принципу в процессе разработки программного обеспечения, большинство приложений было бы написано на языках более высокого уровня, таких как Perl, Tcl, Python, Java, Lisp и даже в оболочках — языках, которые облегчают нагрузку программиста, выполняя собственное управление памятью.
Большинство по-прежнему застряли со старой стратегией кодирования Unix в C (или C ++ ).

Берегите руки, создавайте программы, которые напишут программы.

Люди плохо разбираются в деталях — любой трюк в коде станет источником задержек и ошибок.
Сгенерированный код дешевле и надежнее, чем созданный человеком.
В традиции Unix генераторы кода активно используются для автоматизации подверженных ошибкам деталей. Генераторы парсера / лексера являются классическими примерами; Генераторы makefile и GUI-интерфейсы являются более новыми.

Оптимизация: прототип перед полировкой. Получите прототип, прежде чем его оптимизировать.

Kernighan & Plauger’s: «80% функциональности, предоставляемой сейчас, лучше, чем 100%, предоставляемой никогда».

Прототипирование в первую очередь может помочь вам не тратить слишком много времени на незначительную прибыль.

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

Кент Бек: «Сделай чтобы работало, потом правильно, затем быстрее».

Прототипирование важно как для проектирования системы, так и для оптимизации — гораздо проще судить, делает ли прототип то, что вы хотите, чем читать длинную спецификацию.
Помню одного менеджера который боролся с культурой «требований» за годы до того, как кто-либо говорил о «быстром прототипировании» или «гибкой разработке».
Он не выдавал длинные спецификации, он собрал воедино некоторую комбинацию сценариев оболочки которые делали примерно то, что нужно, велел клиентам посылать ему несколько клерков на несколько дней, а затем заставлял клиентов приходить и смотреть на своих клерков, использующих прототип и сообщать ему понравилось или нет. И говорил им : «Вы получите производительность через столько-то дней с такими-то затратами».

Использование прототипов, чтобы узнать, какие функции вам не нужно реализовывать, помогает оптимизировать производительность; вам не нужно оптимизировать то, что вы не пишете.

Разнообразие: не доверяйте претензиям на «один верный путь».

Даже лучшие программные инструменты ограничены фантазиями их дизайнеров. Никто не достаточно умён, чтобы оптимизировать всё, ни предвидеть все возможности использования их программного обеспечения. Разработка жесткого, закрытого программного обеспечения, которое не будет общаться с остальным миром, является нездоровой формой высокомерия.

Традиция Unix включает в себя здоровое недоверие к «единственно верному» подходу к разработке или реализации программного обеспечения. Он охватывает несколько языков, открытые расширяемые системы и настройки повсюду.

Расширяемость: дизайн для будущего, потому что оно  будет здесь раньше, чем вы рассчитываете.

Если неразумно доверять притязаниям других людей на «один верный путь», ещё более глупо верить им в  собственных замыслах.
Никогда не думайте, что у вас есть окончательный ответ.
Поэтому оставьте место для ваших форматов данных и кода для роста; в противном случае вы часто обнаружите, что вы заблокированы неразумным ранним выбором, потому что вы не можете изменить их, сохраняя обратную совместимость.

Когда вы разрабатываете протоколы или форматы файлов, делайте их достаточно самоописываемыми, чтобы их можно было расширять. Всегда или включайте номер версии, или составьте формат из отдельных, самоописываемых предложений таким образом, чтобы можно было легко добавлять новые предложения и удалять старые без запутанного кода чтения формата. Опыт Unix говорит нам, что незначительные дополнительные затраты на создание самоописаний макетов данных в тысячу раз окупаются возможностью развивать их, не нарушая ничего.

Когда вы разрабатываете код, организуйте его так, чтобы будущие разработчики могли включать новые функции в архитектуру без необходимости пересматривать и перестраивать архитектуру . Это правило не является лицензией на добавление функций, которые вам пока не нужны; это совет , чтобы написать код так, чтобы добавлять позже, когда вы действительно нуждаетесь в них легко. Сделайте суставы гибкими и добавьте комментарии «Если вам когда-нибудь понадобится …» в ваш код. Вы получите благодать от людей, которые будут использовать и поддерживать ваш код.

Вы будете в будущем и сами, поддерживая код, который забыли под прессом более свежих проектов.
Планируя будущее, сохраняйте здравомыслие.