Юрий Ковалев Yoschi

Существует много модных современных концепций: Agile, Lean Startup, Customer Development, Worse is Better, TDD, SaaS. Все они хороши. Вникание, а тем более использование, сильно расширяет горизонты. Но надо понимать, что это всё довольно общие вещи. Нужно не забывать использовать голову и чётко осознавать применимость в собственном проекте.

Фанатичное следование методологии напоминает восторг от осознания какой-то возможности в языке программирования. Я сам поддавался такому не раз: «Круто, в Python есть метаклассы — срочно используем в проекте» — несмотря на то, что того же самого можно было добиться обычными атрибутами класса. «Вау, макросы Lisp — это супер, накодим их побольше» — хотя можно было обойтись функциями высшего порядка. Сначала делаешь так, а со временем свыкаешься и уже не суёшь эту мощную возможность куда попало, а используешь, только если она действительно нужна.

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

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

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

Внимание, раздвоение истории!

Ветка 1
А к чёрту этот Модуль! Открываю текстовый редактор и пишу статью. Так как мысли лезут в голову сами, за день она легко делается. На следующий день, уже ни на что не отвлекаясь, пишу Модуль.
«Малодушно», скажете вы? Давайте рассмотрим альтернативное развитие событий.

Ветка 2
К чёрту эту Статью! Я мужественный программист и должен сначала закончить важное дело!
Целый день пытаюсь отмахиваться от мух посторонних мыслей. Стараюсь раскладывать Модуль на функции, а не на главы, и согласовывать интерфейсы, а не падежи. Итого, к концу дня едва начатый Модуль и чуть-чуть разрозненных записок по Статье, которые я всё-таки скинул в блокнот, чтобы выкинуть из головы.
На следующий день Статья забыта окончательно, и я спокойно доделываю Модуль.
На третий(!) день я пытаюсь вспомнить, что имел в виду в своих заметках по Статье. Но так как я от неё хорошо отгородился, получается так себе. Может быть, за этот день напишу. А может и нет, вдохновение то ушло.

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

Разумеется, не всё так просто. В таком поведении есть известные (и не очень известные) риски.

Одним из главных преимуществ фреймворков является их предопределённая архитектура. Открываешь незнакомый проект и сразу знаешь, где и как искать код связи с БД, или HTML, или схему url. Кроме того, она позволяет разработчику не задумываться над структурой хранения кода и при этом быть уверенным, что проект будет выглядеть более менее адекватно. Но хочу рассказать о случае, когда реализация MVC в Django, а именно распределение логики по файлам models, forms, views, templates оказалась неудобной и какую на её основе построили альтернативу.

Встала у нас задача сделать движок для статистической отчетности на Django. Мы создали селекторы для получения данных из Oracle и виджеты для отображения этих данных в виде таблиц или графиков (с помощью HighChart). Но это всё чисто технологические решения, без особой магии. Если появятся интересующиеся, расскажу в отдельном посте. А сейчас хотелось бы обратить внимание на более необычную часть проекта. На предоставление составителям отчетов удобного способа эти отчеты составлять.

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

Теперь я пишу на Питоне и с ООП знаком. И паттерны мне теперь намного понятней. Но меня по-прежнему воротит от развесистых схем классов. Многие паттерны прекрасно работают в функциональной парадигме. Опишу несколько примеров.

Хочу вернуться к подзабытой теме о «10 однострочниках» на любимом языке. Бурное обсуждение на Хабре было несколько месяцев назад. К сожалению, не многие приводили действительно однострочники и не многие из них были читабельны. Хочу предложить версию на Racket, которая по этим параметрам местами даже превосходит изначальный пример на Scala.