Собственно, может кто не читал, советую ознакомиться. Хоть ее и называют философией UNIX, все те же принципы и подходы к проектированию работают и в веб-разработке. Впервые я встретил эту философию совсем недавно (раньше как-то не попадалось). И с удивлением обнаружил в ней принципы, которые мне пришлось усваивать через боль и кровь. Вместо того, чтобы прочитать эту красоту, которую аккумулировали пацаны в результате десятилетий опыта разработки.
Моя проблема с рафинированным знанием в том чтобы “замапить” его на реальные проблемы. Желательно такие, с которыми я достаточно знаком чтобы понять какие аспекты проблем влияют на рафинированные знания.
Интуитивно юникс философия понятна и звучит правильно. Но если меня спросить привести пример одного из пунктов философии, то я не смогу достать из головы годного примера.
Вижу способ показать полезность юникс философии только вкупе с примерами. Запишу как мысль на будущее “Разобрать конкретные примеры обзепринятых философий”.
Для меня философия юникс отражается в первую очередь на организации кода. Самыми влиятельными мне показались некоторые тезисы самого Реймонда:
Правило модульности: Пишите простые части, соединяемые понятными интерфейсами. Это переформулировка вот этого: «Пишите программы, которые делают что-то одно и делают это хорошо». Это напрямую можно соотносить с разбиением кода на отдельные независимые абстракции (функции), каждая из которых хорошо выполняет свою единственную роль и может быть переиспользована. Очень часто ловлю себя на мысли, что я начинаю фигачить все монолитом и потом, закономерно, меня догоняет кара при отладке и расширении функционала.
Правило ясности: Ясность лучше заумности. Все мы знаем этих умников, которые могут написать решение проблемы в 1-2 строки. Но на деле лучше писать пусть многословней, зато понятней. Через пол года мозг не будет перенапрягаться при парсинге такого кода.
Правило разделения: Отделяйте правила (policy) от механизма (mechanism); отделяйте интерфейс от движка (engine). Это больше всего напоминает конечно же модель MVC. Тоже очень дельный совет: держать все в разных ящиках (M и V), а взаимодействие между ними настраивать через специальный интерфейс (C).
Правило представления: Храните знания в данных так, чтобы логика программы была тупой и надёжной. Это подталкивает использовать максимально простые структуры данных, не впадая в ухищрения ради ухищрения.
Правило оптимизации: Сначала — опытный образец, потом — «причесывание». Добейтесь стабильной работы, только потом оптимизируйте. Это вообще золото. Сколько раз я буквально тонул в попытках сразу родить идеальный код. Потом так противно, когда понимаешь, что надо было рабочий прототип запилить сразу, а теперь столько переделывать… Сюда же можно приписать преждевременную оптимизацию, которая обычно ничего кроме раздутого эго разработчика бизнесу не дает.
На данный момент вообще вся эта философия у меня в голове лежит примерно так:
Модульность везде. Модули решают. Когда все по модулям, тестирование, отладка и расширение функционала – дается легко.
Простой читабельный код. Пусть там будет еще один дополнительный блок if, вместо трех-километрового тернарного оператора. Пусть имена переменных будут длинные, зато понятные.
Separation of concerns(разделение отвественности) это хорошо. Без этого все спутывается в клубок, который только мазохисты захотят потрогать.
Чем проще, тем лучше. Сложность добавлять только тогда, когда нет способа сделать просто. Энтропия постоянно растет, у всего есть цена. Каждый раз когда возникает желание добавить очередной узел в экосистему, надо убедиться, что он решает проблем больше, чем создает. А создает он всегда много: он завязывает на себе работу остальных частей; его надо обновлять и поддерживать; он вносит в систему еще одну часть, с которой нужно знать как работать.
Вообще весь этот комплекс принципов формирует определенный ментальный настрой, с которым нужно подходить к разработке.
На закуску -- «Дзен Питона»
Красивое лучше, чем уродливое.
Явное лучше, чем неявное.
Простое лучше, чем сложное.
Сложное лучше, чем запутанное.
Плоское лучше, чем вложенное.
Разреженное лучше, чем плотное.
Читаемость имеет значение.
Особые случаи не настолько особые, чтобы нарушать правила.
