"В информатике мы все -- дети Дейкстры"
Сделал итерацию по последним веяниям в BDD (behaviour driven development), и в очередной раз понял, что всё это не то. Когда скорость разработки с сохранением качества играет ключевую роль, ну нету времени на подробные сценарии BDD (или спеки в TDD).
Но в 99% случаев скорость приводит к тому, что изображено на картинке.
-- Прошло уже две недели разработки - покажите что-нибудь.
-- Смотрите: вот архитектура, вот документация, вот тесты, вот прототип.
-- Вы что же, за две недели НИЧЕГО НЕ СДЕЛАЛИ?
http://habrahabr.ru/company/evilmartians/blog/148264/
"Самый писк моды -- приблизиться к человеческому языку, так что бы тесты были как бы метаописаниями, как бы объясняли на примерах как должен работать код"
http://habrahabr.ru/post/126747/
Когда время есть, это безусловно один из наиболее правильных подходов. Но суровая практика -- это много [говно]кода, навянного в коллективе с такими же [говно]кодерами:)
Из наиболее близких по духу подходов, который лично я использую много лет, это фактически Readme Driven Development (или, по-русски, пиши-код-блять.рф) с помощью task-менеджера или какого-нибудь redmine. Но формализация в RDD отсутствует в принципе, и это ее главный минус.
Реально оптимистичный вывод под катом.
На самом деле самые умные вещи в прикладной программной инженерии были придуманы Дейкстрой 50 лет назад в форме структурного программирования (еще в 60-е Дейкстра создавал весьма сложные программы, не содержащие ни одной ошибки), и с тех пор ничего концептуально нового фактически не появилось. С тех пор развитие ее хардкорной части, которая ближе к искусству+науке, прежде всего математике (в оппозиции к ремесленному мэйнстриму) проходило витками от Дейкстры к Алану Кею и обратно.
Одним из гуру того времени, развившим идеи Дейкстры на масштабные проекты, был Glenford Myers. Он замечательно переведен в 80-е ("Искусство тестирования программ" и "Надежность программного обеспечения"). Интересно, что с тех пор он так и не причалил к какой-либо модной методологии, хотя всю жизнь проработал в софтверных фирмах, в последние годы занимаясь системами электронной прослушки (прежде всего по той причине, что существенное внимание всегда уделял виртуализации). Glenford Myers предложил т.н. "композиционное проектирование" (http://www.realcoding.net/dn/docs/G.Myers.pdf), включающее два набора правил:
- набор явных мер проектирования которые решают ключевые проблемы и, кроме этого, много дополнительных проблем;
- набор мыслительных процессов для декомпозиции приложения на множество модулей, интерфейсов и связей между модулями.
По самому большому счету, Дейкстра, Майерс и Кей всегда говорили об одном и том же содержании, просто разными формами: про минимизацию сцепки (cohesion; ну или внешних связей) модулей без добавления ненужных абстракций типа объектов или аспектов. Уровни абстракций Дейкстры как раз про другое, да и Кей по тому же большому счету говорил прежде всего не столько про объекты, сколько про схемы взаимодействия между независимыми модулями через обмен сообщениями, дабы уменьшить cohesion. А сам объект -- это тоже фактически лишь удобное средство повышения прочности (внутренней связности) модуля.
И вот какой должна быть, серебряная пуля Метакода:
-- собрать основные правила искусства программирования как дисциплины программирования, ориентированные на минимизацию внешней связности (которые развивались в контексте Дейкстры и К, по форме весьма условны и существуют прежде всего как рекомендации по стилю программирования);
-- выделить в них прикладные паттерны;
-- выделить в них мета-паттерны ("набор мыслительных процессов для декомпозиции приложения");
-- добавить современные технологические "прикладухи" типа RESTful и моделей высоконагрузочных систем.
И получится самое оно.
"Выбирайте проект настолько продвинутый, насколько вы можете себе представить, настолько претенциозный, насколько вы можете это оправдать. Поднимите ваши стандарты качества так высоко, как можете, избегайте тратить ваше время на рутинные проблемы, и всегда старайтесь работать настолько близко к границе ваших способностей, насколько это возможно. Делайте так потому, что это -- единственный способ эту границу определить и отодвинуть".