Метод разработки «давай-давай наваливай» (CDD)

стартап

Хаос-менеджмент.

https://ru.wikipedia.org/wiki/Экстремальное_программирование

Да никак не называется. Ну или «тяп-ляп». Как называется метод сборки мотоцикла из говна и палок, по пути понимая, как их вообще объединять между собой, и как сделать, чтобы в итоге это как-то ехало? Как называется метод готовки еды без рецепта, а от балды, во время готовки решая, что добавить и не зная, что получится? Никак? Ну вот и в программировании никак.

Это самый распространённый и естественный метод разработки доминирующий над всеми остальными по части количества написания кода на всей плонете. =)

Да.

Метод компоспеца.

Если есть непреодолимое желание всем возможным совокупностям явлений и их качеств дать отдельные красивые термины, наверное это можно назвать Импровизационным Программированием.

Как называется метод готовки еды без рецепта, а от балды, во время готовки решая, что добавить и не зная, что получится?

Батин суп же.

Ну вот значит сабж у нас будет BSOP — Batin Soup Oriented Programming. Можно, конечно, DSOP — Dad’s Soup Oriented Programming, но по моему, Batin Soup звучит эпичнее.

По-русски, если без мата, называется «чик-чик и в продакшн»: https://www.youtube.com/watch?v=R4sTvHXkToQ&t=2071s

Не не не… Там про тонны лапши вообще ни слова. Там наоборот, минимум телодвижений в чем либо

Это больше от заказчика зависит, а не квалификации исполнителя.

Да, помнится, мы так и называли, сначала сокращая до ХХиП, затем до просто ХХП. Но поскольку два Х на одну П это тройничок, метод стали называть тройничком.

Короче, народное творчество ушло в народ.

https://www.youtube.com/watch?v=ir5rj2yYH_8

Скорее фристайл, как реп

этот способ называется БИЗНЕС :-) всего важнее результат

прочие подходы в 90% случаях продают не только код/результат, но и процесс (вместе с менеджерами и разрабами)

Мол, сразу тонну спагетти - и сразу в прод.

Похоже на то, как разрабатывается X.Org

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

Вы, видимо, не были студентом в 90е

Вы, видимо, не были студентом в 90е

Не был. Был в самом начале нулевых, но сей метод застал. А что, в 90-е у него было название?

Тогда мы об этом не думали. Просто творили.

https://www.youtube.com/watch?v=F2skk6RFFos

Cowboy coding:
https://en.wikipedia.org/wiki/Cowboy_coding

Ещё duct-tape coding:
https://www.joelonsoftware.com/2009/09/23/the-duct-tape-programmer/

Программистам клейкой ленты нужно обладать большим талантом, чтобы провернуть эту штуку. Они должны быть достаточно хорошими программистами, чтобы отправлять код, и мы простим им, если они никогда не напишут модульный тест или если они объединят указатели «next» и «prev» своего связанного списка в одно DWORD, чтобы сэкономить 32 бита, потому что они достаточно красивы и достаточно умны.

В принципе то, что и спрашивалось в конце топика.

Ну так а я, собственно, о чём.

Франч, русский менеджмент

Подскажите, как называется способ написания кода без прототипирования?

Официально «Хуяк хуяк и в продакшен»

Спасибо. Будем стремиться к этому.

2Д2П - давай делай, потом посмотрим. Всегда так называлось.

«правим на проде»

Только дурак нуждается в порядке — гений господствует над хаосом

:-P

Как называется метод готовки еды без рецепта, а от балды, во время готовки решая, что добавить и не зная, что получится?

Так себе пример. Если умеешь хорошо готовить, можешь готовить по рецепту или импровизировать, всё равно получится круто.

Ну вот и в программировании

Возможно так же.

Метод разработки «давай-давай наваливай» (CDD)

Я всегда думал, что CDD - это сокращение Community-driven development, т.е. разработка управляемая сообществом. Но ничего, что вы написали далее, не соответствует этому… 🤔

Так себе пример. Если умеешь хорошо готовить, можешь готовить по рецепту или импровизировать, всё равно получится круто.

В принципе в программировании, если проект небольшой, то всё то же самое. Проблемы начинаются, когда к такой «готовке» присоединяются другие. Или если это что-то очень крупное.

Причин много. Расплывчатые причины: нехватка кадров, нехватка квалифицированных кадров, нехватка времени.

Можно попытаться каждый раз строить идеальный хрустальный дворец архитектуры, и затратить на это 10 лет, но кто все эти 10 лет будет оплачивать офисы, электричество, и платить зарплату. И из каких средств? И где гарантия, что за эти 10 лет получится адекватный результат, который будет удовлетворять заказчика?

По опыту, долгое проектирование и разработка чаще приводит только к раздуванию сроков и созданию излишней сложности. Что-то вроде «эффекта второй системы», описанного Бруксом (книгу читал более 15 лет назад, поэтому могу переврать название), когда создаётся очень долго «идеальная» система, в которой слишком много функций, на которые было затрачено слишком много труда, и которые в реальной жизни оказываются не нужны или не тем, что нужно заказчику.

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

В общем, мир несовершенен, не существует какого-либо метода, который гарантированно даёт хороший результат. Со временем просто набираешься опыта, начинаешь лучше понимать, что работает хорошо, что работает плохо, как-то использовать эти эвристики (сильно упрощенный пример — принципы SOLID).

Если создать какую-то всеобъемлющую методологию, в которой будет чётко прописано:

1. Сначала рисуем архитектуру используя все методы документирования UML и C4
2. Затем делаем прототип
3. Затем делаем проект, учитывая опыт, полученный при создании прототипа.

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

Не существует гарантированных способов чего-то добиться в этом мире.

Натуральное программирование.

1. Сначала рисуем архитектуру используя все методы документирования UML и C4
2. Затем делаем прототип
3. Затем делаем проект, учитывая опыт, полученный при создании прототипа.

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

У меня разработка ведется примерно так.
Сначала производится разработка (как бы это сказать) «костяка» архитектуры.
Затем разработка API (но не «сверху вниз»).

Мне проще (нет «советольщиков» и «указателей»).
Сея плеяда как раз и приводит к тому, что проекты разрабатываются «вечно».

Методологий придумано много. Ни одна из них не подходит ко всем ситуациям. У меня есть печальный недавний опыт, когда в компании есть множество проблем, причём по очень объективным причинам:

• древняя кодовая база, в которой наговнокодено различными людьми за 30 лет очень много разнообразного кода, который непонятно как работает, невозможно модифицировать, невозможно даже удалить части, т.к. совершенно непонятно, что из этого нужно, а что уже нет
• практически полное отсутствие документации по коду, включая комментарии (хотя бы докстринги для классов и функций)
• разработка под пропиетарные системы, у которых отсутствует вменяемая документация, и взаимодействие с их API приходится реализовывать методом тыка: вызвали метод с таким набором параметров, вызвали метод с другим набором, после каждого шага пытаемся понять, что изменилось в поведении системы. Это очень долгий способ, и сильно фрустрирует разработчиков

И т.д. и т.п.

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

В итоге, где-то одна неделя из четырёх в месяце затрачивается только на созвоны!

Ну и естественно, разработка не ускоряется, а только ещё сильнее замедляется, т.к. существующие разрабы тратят 25-50% времени на совещания и отчетность… Однако, руководство продолжало гнуть прежнюю линию, что надо больше СКРАМа, надо тщательнее следовать всё новым разновидностям скрама, и т.д.

Ну и естественно, разработка не ускоряется, а только ещё сильнее замедляется,

Это же прекрасно!
Зато мы всегда «при деле».

Предыдущий пост был об своих разработках.
Что касаемо работы, то здесь иной подход (при этом он видоизменяется от руководителя к руководителю).

К примеру, предыдущий мой начальник никому не шел навстречу предложениям от сотрудников.
Типа «Огурцова» («Карнавальная ночь»).

Как же мне удавалось добиваться того, что «Огурцов» давал мне правильные задания?

Да просто!

Вел беседы «вокруг да около того, как нужно», но не утверждал, что нужно сделать «так».

Поэтому «Огурцов» «подумав», давал мне то распоряжение которое мне как раз и было кстати.

В шестой палате (знаете ли) не так то легко находиться ...

Предыдущий пост был об своих разработках.

Немного об разработке нового API.

Ныне (к примеру) принял решение разработать «встроенный язык».
Вместо грамматик для его разработки будут использованы метаданные.
Так вот самый трудный этап для меня обычно заключается в проектировании (продумывании что-ли) архитектуры.
В разработке же кода самая большая трудность - победить свою лень.

Проблемы начинаются, когда к такой «готовке» присоединяются другие.

Вот это кстати интересный момент. При работе небольших команд у меня работала следующая схема: один программист пишет прототип своей части, интерфейс к ней, краткую документацию и пример использования. Затем подключается следующий программист и из примера использования делает свою часть.

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

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

Декомпозиция на подзадачи - это, на мой взгляд, вообще 'must have' в проектах, где требуется Super-Hero.

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

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

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

В данном случае у нас простоев не будет, если кто-то в отпуске и заболел. Каждый день обновления - видно, что команда работает.

называется «современная разработка ПО»

Не ну реально, какое к черту прототипирование? Во всяком случае, в ширпотребе… Сначала набранные программисты и архитекты доучиваются, въезжают в тему, пишут всякие «хелловорлды со спецификой предметной области», в это время трындят на митингах о том, какое крутое ТЗ составили. А потом просто хреначат код. Хорошо если хоть юнит-тесты есть. Критерий работоспособности - армия тестеров и просто на юзерах-потребителях.

вместо прототипирования могут быть маленькие эксперементальные тулзы, которые демонстрируют возможность подхода и используемых компонент в тех аспектах, которые вызывают наибольшие опасения

А почему без прототипирования обязательно будет спагетти? Это же разного рода проблемы

Тактика без стратегии, спонтанный менеджмент, матерное - ХХивП :)