Философия Unix

Собственно, может кто не читал, советую ознакомиться. Хоть ее и называют философией UNIX, все те же принципы и подходы к проектированию работают и в веб-разработке. Впервые я встретил эту философию совсем недавно (раньше как-то не попадалось). И с удивлением обнаружил в ней принципы, которые мне пришлось усваивать через боль и кровь. Вместо того, чтобы прочитать эту красоту, которую аккумулировали пацаны в результате десятилетий опыта разработки.

Чуть более детальный вариант[en] описан в книге Эрика Реймонда «The Art of Unix Programming»[en].

1 симпатия

Отличная тема.

Моя проблема с рафинированным знанием в том чтобы “замапить” его на реальные проблемы. Желательно такие, с которыми я достаточно знаком чтобы понять какие аспекты проблем влияют на рафинированные знания.

Интуитивно юникс философия понятна и звучит правильно. Но если меня спросить привести пример одного из пунктов философии, то я не смогу достать из головы годного примера.

Вижу способ показать полезность юникс философии только вкупе с примерами. Запишу как мысль на будущее “Разобрать конкретные примеры обзепринятых философий”.

1 симпатия

Для меня философия юникс отражается в первую очередь на организации кода. Самыми влиятельными мне показались некоторые тезисы самого Реймонда:

  • Правило модульности: Пишите простые части, соединяемые понятными интерфейсами. Это переформулировка вот этого: «Пишите программы, которые делают что-то одно и делают это хорошо». Это напрямую можно соотносить с разбиением кода на отдельные независимые абстракции (функции), каждая из которых хорошо выполняет свою единственную роль и может быть переиспользована. Очень часто ловлю себя на мысли, что я начинаю фигачить все монолитом и потом, закономерно, меня догоняет кара при отладке и расширении функционала.
  • Правило ясности: Ясность лучше заумности. Все мы знаем этих умников, которые могут написать решение проблемы в 1-2 строки. Но на деле лучше писать пусть многословней, зато понятней. Через пол года мозг не будет перенапрягаться при парсинге такого кода.
  • Правило разделения: Отделяйте правила (policy) от механизма (mechanism); отделяйте интерфейс от движка (engine). Это больше всего напоминает конечно же модель MVC. Тоже очень дельный совет: держать все в разных ящиках (M и V), а взаимодействие между ними настраивать через специальный интерфейс (C).
  • Правило представления: Храните знания в данных так, чтобы логика программы была тупой и надёжной. Это подталкивает использовать максимально простые структуры данных, не впадая в ухищрения ради ухищрения.
  • Правило оптимизации: Сначала — опытный образец, потом — «причесывание». Добейтесь стабильной работы, только потом оптимизируйте. Это вообще золото. Сколько раз я буквально тонул в попытках сразу родить идеальный код. Потом так противно, когда понимаешь, что надо было рабочий прототип запилить сразу, а теперь столько переделывать… Сюда же можно приписать преждевременную оптимизацию, которая обычно ничего кроме раздутого эго разработчика бизнесу не дает.

На данный момент вообще вся эта философия у меня в голове лежит примерно так:

  • Модульность везде. Модули решают. Когда все по модулям, тестирование, отладка и расширение функционала – дается легко.
  • Простой читабельный код. Пусть там будет еще один дополнительный блок if, вместо трех-километрового тернарного оператора. Пусть имена переменных будут длинные, зато понятные.
  • Separation of concerns (разделение отвественности) это хорошо. Без этого все спутывается в клубок, который только мазохисты захотят потрогать.
  • Чем проще, тем лучше. Сложность добавлять только тогда, когда нет способа сделать просто. Энтропия постоянно растет, у всего есть цена. Каждый раз когда возникает желание добавить очередной узел в экосистему, надо убедиться, что он решает проблем больше, чем создает. А создает он всегда много: он завязывает на себе работу остальных частей; его надо обновлять и поддерживать; он вносит в систему еще одну часть, с которой нужно знать как работать.

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


На закуску -- «Дзен Питона»
  • Красивое лучше, чем уродливое.
  • Явное лучше, чем неявное.
  • Простое лучше, чем сложное.
  • Сложное лучше, чем запутанное.
  • Плоское лучше, чем вложенное.
  • Разреженное лучше, чем плотное.
  • Читаемость имеет значение.
  • Особые случаи не настолько особые, чтобы нарушать правила.
  • При этом практичность важнее безупречности.
  • Ошибки никогда не должны замалчиваться.
  • Если не замалчиваются явно.
  • Встретив двусмысленность, отбрось искушение угадать.
  • Должен существовать один — и, желательно, только один — очевидный способ сделать это.
  • Хотя он поначалу может быть и не очевиден, если вы не голландец.
  • Сейчас лучше, чем никогда.
  • Хотя никогда зачастую лучше, чем прямо сейчас.
  • Если реализацию сложно объяснить — идея плоха.
  • Если реализацию легко объяснить — идея, возможно, хороша.
  • Пространства имён — отличная штука! Будем делать их побольше!
1 симпатия