Пиши код бл***!

А лучше бы русский учили

...поняв, найдя и пофикся все ошибки в ТЗ, не сразу бежишь писать код, а потом тесты (ну или тест/код/тест/код), а сначала пишешь документацию на основании ТЗ, копипастя requests и responses.

Потом ты предоставляешь тому, кто написал ТЗ мок-сервис, который проверятся в тестовом клиенте.

Потом ТЗ корректируется/уточняется мной и/или заказчиком - привет возможность редактирования.

А уж потом я начинаю кодирование на основании документации.

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

Вообще DDAD - это намного более низкий уровень, к ТЗ слабо относящийся. Просто когда пишешь API к публичному классу или сервису - сначала пишешь метод в документацию, потом кодируешь в код. И с изменениями точно так же. Уходит на это 5 минут.

Поддерживаю

Итак, вопрос: реально ли может DDAD принести пользу проекту?

Может. Хорошо, что ТЗ уже не в ворде, но в Markdown'е. Следующий этап ТЗ в виде сценариев на Gherkin'е (русский язык поддерживается) и прогон Cucumber'ом сценариев на суррогатном (mock) сервисе. Потом кодирование и PROFIT.

Количество сделанных проектво

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

Отвечает Йоэль Спольски:

Почему люди не хотят писать спецификации? Они утверждают, что экономят время, пропуская эту стадию разработки. Люди ведут себя так, словно создание спецификаций – это роскошь, позволительная только для инженеров NASA, проектирующих космические шаттлы, или сотрудников крутых страховых компаний. Чепуха. Прежде всего, отказ от написания спецификаций – это ваш самый большой ненужный риск при разработке программного продукта. Это так же глупо, как намерение перейти пустыню Мохаве, взяв с собой в рюкзаке только постельное белье, и в надежде импровизировать по пути. Программисты, которые погружаются в кодирование без написания спецификации, склонны думать, что они похожи на крутых гангстеров, стреляющих с бедра. Это не так. Они ужасно непродуктивны. Они пишут плохой код, выпускают низкопробное ПО и подвергают свои проекты совершенно неоправданному риску.

т.е. инвертирование подхода ничего по сути не меняет?

При каком подходе вероятность «перепиать все нахер заново» ниже?

Типичный случай ошибки выжившего. Человек увидел несколько проектов, успешно сделанных при наличии спецификации, и считает что именно спецификация была причиной успеха. А на самом деле может с руководителями повезло, или конкурентам не повезло с исполнителями, да мало ли что еще. В жизни и проекты со спецификацией проваливаются, и без спецификации выстреливают, т.к. кроме спецификаций есть много других факторов. Если память не изменяет, более 60% проектов проваливается.

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

Затраты времени на такие прототипы сами по себе немаленькие, а в случае постоянного согласования с третьими лицами будут огромны, потому что у тех тоже хватает дел, они не будут немедленно подрываться читать документацию и тестировать прототипы. И проще сделать сразу какой-то софт по первоначальным требованиям. Если вдруг окажется не совсем то что нужно - переделать частично, переписать заново или, что бывает чаще, запустить в том виде в котором есть и постепенно дорабатывать до кондиции.

я пробовал писать на Gherkin, потом забросил.

До меня не дошло сначала, КАК нужно писать там спецификации для REST сервиса. Я сначала думал, что нужно там описывать внутренние процессы: положил в базу/взял из нее, скачал FTP с сервера, положил на него ну и т.д.

Потом посмотрел примеры: оказывается там нужно тупо описывать, что получает клиент. А для этого уже есть Apiary, который документирует сервис в Markdown. И используется для генерации, которую будут читать люди.

А кто потом будет читать cucumber спецификации? Как будет происходить перевод спецификаций в код в JavaScript?

То, что я смотрел - привело меня в тихий ужас. Даже аффтар книжки по BDD в JS не доволен Gherkin-ом и выбирает mocha.

А еще есть плагины Gherkin для mocha: mocha-cakes, mocha-gherkin .

И хрен его знает как его интегрировать в уже существующий процесс. Gherkin нужно переводить в тесты? Какие? Юнит? А может я их пишу уже после кода? И как их сопоставить со спецификациями?

прогон Cucumber'ом сценариев на суррогатном (mock) сервисе

чем ты будешь прогонять это на ноде? Чем будешь мокировать? Откуда будет браться информация для мок сервера?

Зы. Реквестирую в тред годные примеры спецификаций для Rest сервисов

Cool story Bro

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

Отличный комментарий, уважаю. Вот ещё картинка в тему.

Человек есть мера всех огурцов

Прежде всего: Gherkin это язык, очень похожий на естественный, но специально обеднённый для задания строгой формы повествования в формате «Когда...Если...То». Cucumber это программа, которая сопоставляет сценарии на Gherkin'е с кодом на Ruby, и этот самый код прогоняющая.

Как будет происходить перевод спецификаций в код в JavaScript?

Человек. Кто же ещё? Вы думали вы написали на естественном языке спецификацию, а машина сама её переварит в код?

И хрен его знает как его интегрировать в уже существующий процесс.

Это всегда болезненно.

Gherkin нужно переводить в тесты? Какие? Юнит?

Gherkin это и есть тесты. Точнее типичные сценарии. И это не модульные (unit) тесты, но приёмочные. Приёмочные тесты не заменяют и не отменяют модульных, но дополняют их.

А может я их пишу уже после кода?

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

И как их сопоставить со спецификациями?

В идеале спецификации сразу должны быть в Gherkin'е. Если это не так, то сопоставлять приходится вручную. Например если в спеках сказано «обработка запроса на переформатирование занимает не более секунды», то на Gherkin'е это будет

Когда я кладу в БД тестовые данные
И посылают запрос на переформатирование
То его обработка занимает не более 1 секунды

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

Но и это еще не все. Наличие хорошего PM (или другого лидера, который решает вопросы, принимает решения, ставит задачи и контролирует) - это очень полезная вещь, так абзац выше можешь не читать, он так, для раздумий. Только вот как связано наличие PM с многомесячным перекидыванием спецификаций между инстанциями и тратами человекомесяцев на написание бесполезного кода? Грамотный PM как раз и скажет, чтобы прекратили заниматься херней под видом согласований деталей «какого цвета кнопка должна стоять в правом углу» и начали наконец думать своей головой и работать, программистов не на должность биороботов нанимали. Это первое.
А второе - мерилом успеха проекта не является отсутствие в нем бардака. Есть еще такие вещи как сроки и издержки например. Так что графики эти рисовали программисты, т.к. бардак и соотвествующие лишние усилия по его разгребанию - это в первую очередь их проблемы. Бывают и успешные проекты с таким бардаком, что волосы встают дыбом. Но программисты привыкли, справляются, обладают достаточной для этого квалификацией и проект приносит деньги. А бывает наверно и идеальный код (хотя я не встречал), за который никто не заплатил, т.к. заказчику просто надоело перекидываться спецификациями без какого-то видимого результата.

Масштаб решает

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

Мне кажется вы недостаточно внимательно рассмотрели картинку. Обратите внимание на масштаб по оси ординат.

Сложности использования технологии

- Требуется крайняя вовлеченность PO и его интерес к этому (technical skills background)

- Жесткие требования на оформление мыслей в виде текста - это даже лучше. Потом читать легче

- Требуется большой разогрев команды, прежде чем BDD будет эффективно работать

unit -тесты все еще нужны

Т.е. теперь мне нужно не только писать и поддерживать юнит-тесты, но и Cucumber тоже?

Тестирование разных вещей

Т.е. теперь мне нужно не только писать и поддерживать юнит-тесты, но и Cucumber тоже?

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

Если я загружаю заказы
То получаю маршрутные листы

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

Главное

Ещё раз отмечу главное, вслед за уважаемым shimshimshim: никакая методология разработки не сделает вас супер-программистом, а вашу команду супер успешной. Стремиться надо к лучшему, избегать худшего, быть за всё хорошее и против всего плохого. И возможно даже не стоит пытаться что-то менять в сложившемся стиле работы, особенно если это позволяет достигать результатов в приемлемые сроки.

Что только не придумают лишь бы не делать по нормальному.

Я предлагаю супер-дупер-мега-революционную идею: платить за результат.

а что такое по-нормальному?

Это когда ты не пляшешь на тему «бесконечной разработки», а работаешь чтобы получить продукт. И тебе платят за него, а не за процесс.

Платят не за процесс

Это когда ты не пляшешь на тему «бесконечной разработки», а работаешь чтобы получить продукт. И тебе платят за него, а не за процесс.

Ваша супер-дупер-мега-революционная идея называется «капитализм».

мне платят за процесс, а не за результат.

За результат платят клиенты фирме.

Просветление

мне платят за процесс, а не за результат.
За результат платят клиенты фирме.

Подписываюсь под каждым словом. Вы достигли просветления. Всякое документирование и BDD помогает сделать этот процесс более плодотворным в долгосрочной перспективе, развитие поступательным, без регрессий. Я тут уже давал ссылку на статью о стрельбе от бедра. Вот почему нужны всякие документы, спецификации и тесты.

а что делать, когда все постоянно меняется?

Медитация лучше мастурбации

а что делать, когда все постоянно меняется?

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

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

требования. Мне сегодня сеньор сказал, что я зря написал документацию сначал. Типа все будет изменяться

Мастурбация хуже медитации

требования. Мне сегодня сеньор сказал, что я зря написал документацию сначал. Типа все будет изменяться

А зачем тогда вообще что-то делать, если всё будет изменяться? В таком случае надо хотя бы подумать какие части меняться не будут, и к ним написать документацию.

а хрен иво знаед