Я занимаюсь разработкой софта уже почти 30 лет и на моих глазах происходило развитие отрасли. Рождались и умирали технологии, менялись языки разработки. Причем я наблюдал эти процессы не просто как сторонний наблюдатель. Менялись языки, на которых я писал код, умирали технологии, которые я использовал.
Сегодня я хочу рассказать об эволюции методологии разработки. Как она менялась с развитием отрасли и как это отражалось на работе обычных разработчиков. Я хочу рассказать эту историю простыми словами. Так, как ее видел обычный разработчик.
waterfall
Сначала была модель водопада waterfall. Она зародилась где то в 70-х годах и слава богу я ее не застал. Тогда компьютеры были уделом больших корпораций. Персональных компьютеров еще не существовало и к разработке софта подходили примерно также, как к разработке больших инженерных продуктов, например автомобиля или ракеты.
Работа над продуктом велась строго итеративно. Сначала проводился сбор требований. Затем разрабатывалось ТЗ. После этого разработчики приступали к написанию кода. После завершения наступал этап тестирования. И только поле этого внедрение продукта.
Все было очень жестко регламентировано. Процесс разработки продукта занимал несколько лет. Сама разработка стоила огромных денег. Но почему то на выходе, в отличии от автомобиля, почти всегда получался продукт, который никого не устраивал.
Это происходило потому, что компьютеры и отрасль в целом развивались бешеными темпами. И требования к продукту, которые собирались в начале разработки, успевали устаревать за один, два года. К моменту выпуска готового продукта он уже как правило был безнадежно устаревшим и не устраивал заказчика.
Spiral model
С появлением на рынке персональным компьютеров, программирование перестало быть уделом только больших корпораций. Стали появляться небольшие компании, такие как Apple и Microsoft, которые занимались разработкой программных продуктов.
Жесткая модель водопада уже просто не вписывалась в реалии рынка и отрасли. В 1986 г. была предложена новая, итерационная модель разработки Spiral Model. По сути это был тот же водопад. Но теперь к разработке продукта подходили не как к цельному процессу, а разбивали процесс разработки на этапы, на маленькие кусочки.
Сначала разрабатывался прототип, затем с каждым этапом, этот прототип развивался и чуть чуть улучшался. На выходе из каждого этапа мы каждый раз получали чуть улучшенный продукт.
Сами этапы все также разрабатывались по схеме водопада, но за счет большого числа итераций, появилась возможность адаптировать продукт под меняющуюся реальность.
Появление этой модели дало толчок к бурному развитию отрасли. По ней работали все крупные компании разработчики.
Scrum
Итерационная модель разработки позволяла выпускать адекватные продукты, которые удовлетворяли быстро меняющимся требованиям рынка. И в целом все всех устраивало.
Программистов было немного и программирование все еще было достаточно новым явлением для человечества. И в какой то момент у компаний разработчиков стали возникать проблемы уже не с самими продуктами, а с внутренними процессами их планирования и разработки.
В то время никто еще не понимал, как правильно организовать процесс разработки и как им правильно управлять. Быстро меняющиеся требования нарушали процессы планирования и приводили к постоянным срывам сроков выпуска продуктов. Менеджмент не понимал как рулить этим процессом. Разработчиков бесило, что требования и задачи постоянно меняются. Стало назревать недовольство уже внутри компаний разработчиков.
И в 90-х годах появилась такая методология как Scrum. В ее основу заложен очень простой принцип.
Спринт - это небольшой интервал времени (обычно 2 недели), который полностью управляется разработчиками. Менеджеры могут менять требования и вносить новые задачи только в будущие спринты. Вносить изменения в активный спринт запрещено.
Таким образом разработчики могли спокойно делать задачи в рамках активного спринта и быть уверенными в том, что никто не прибежит к ним с горящими глазами с требованием все бросить и переключится на совсем другую задачу.
В результате, внутри больших этапов, появились еще более мелкие итерации - спринты, которые управлялись только разработчиками. На самом деле эта модель получилась настолько удачной, что с минимальными изменениями она дожила до наших дней. И большинство компаний сейчас работают именно по методологии Scrum.
По сути Scrum - это такой договор между разработчиками и менеджерами. Вы можете менять все что угодно, пока мы не взяли это в работу. Но когда спринт в работе, идите лесом...
XP - Extreme Programming
До этого момента с разработкой все было хорошо. Люди занимались делом и пытались как то организовать свои процессы, чтобы сделать их удобными и рабочими.
Но в 2000-х годах появилась новая, модная методология с броским названием Экстремальное программирование и в мир разработки пришел маркетинг.
По сути своей, это была очень правильная штука, которая описывала разные полезные практики, которые можно было использовать в разработке:
разработка через тестирование (test-driven development)
игра в планирование (scrum poker)
парное программирование (pair programming)
непрерывная интеграция (continuous integration)
простота проектирования (simple design)
и другие полезные практики
Эти практики можно было использовать в конкретных ситуациях, а можно было не использовать, если ситуация не подходит под эту практику. В целом они действительно полезны и многие практики из XP сейчас по сути стали стандартами: continuous integration, code style, scrum poker, small releases.
Но почему то мир воспринял эту методологию как догму. Менеджеры увидели в этой методологии свой святой грааль и спустили на разработчиков эту методологию не как набор полезных практик, а как догму и религию.
Я очень хорошо помню наши шутки того времени про парное программирование.
Отличная штука это парное программирование. Можно сэкономить на дорогих компьютерах, 1 компьютер на 2 разработчика.
В 2000-х годах менеджмент реально заставлял разработчиков сидеть вдвоем за одним компьютером и пытаться писать код.
Все доводы разработчиков про то, что это не догма, а гибкая методология, игнорировались менеджментом. Все ждали от внедрения XP того чуда, которое дало внедрение scrum. Но чуда не случилось по понятным причинам (точнее оно случилось чуть позже, когда все немного успокоились). Причем это помешательство на XP было массовым и так или иначе затронуло пожалуй все компании на рынке.
Agile
Примерно к 2005 году первые страсти по XP спали. Менеджмент успокоился и отстал от разработчиков. Разработчики вздохнули с облегчением и стали внедрять практики XP уже не как догмы, а именно как полезные практики и это довольно сильно изменило подход к разработке софта. Многие элементы XP позволили кардинально изменить подходы к разработке и выпуску продуктов.
Например сейчас уже никого не удивишь тем фактом, что релиз продукта выходит каждые две недели. Но в 2000-х годах это казалось фантастикой. В то время средний релизный цикл продукта занимал 1-2 года.
В 2010-2015 годах в России стал появляться Agile. По сути это было просто обобщение практик XP программирования и дополнение их базовыми принципам:
люди и взаимодействие важнее процессов и инструментов
работающий продукт важнее исчерпывающей документации
готовность к изменениям важнее следования первоначальному плану
самый эффективный метод обмена информацией в команде — личная встреча
работающее программное обеспечение — лучший измеритель прогресса
Agile пропагандирует разработку в виде небольших, максимально независимых и самодостаточных команд. Основной приоритет, максимально частые релизы. Основная ценность - это фича, которая полезна пользователям. Все процессы должны быть максимально простыми. Ничто не должно мешать быстрой разработке и внедрению фичи.
И началось второе пришествие маркетинга в мир разработки софта. Несмотря на то, что в манифесте Agile прямо прописано, что это гибкая методология и ее нельзя воспринимать как догму, менеджмент начал насаждать Agile именно как догму.
Роль скрам мастера стала полноценной профессией. Мы все стали считать часы в попугаях, играть в скрам покер, забивать на документацию и аналитику. А также иногда и на полноценное тестирование.
Сейчас, когда вторая волна маркетинга схлынула, Agile трансформировался в рабочую концепцию. На первое место вышел процесс выпуска регулярных релизов. Крупные компании адаптировались к Agile следующим образом:
Появилось большое количество фича-команд, которые отвечают за очень ограниченные функциональные блоки. Команды самодостаточны и развивают свою функциональную область и зону ответственности. Как правило команда имеет своего собственного аналитика, дизайнера, разработчиков и тестировщиков.
Появились платформенные команды, которые решают общие вопросы и отвечают за технологический стек и архитектуру проекта в целом.
Появились релизные команды, которые отвечают за регулярный выпуск релизов. Они собирают со всех команд финализированные фичи и включают их в плановые релизы. Релизная команда имеет своих тестировщиков, которые занимаются тестированием релиза в целом, а не отдельной фичи. Релизы стали выходить строго по графику, как правило 1 раз в 2 недели.
Появились механизмы фича-рубильников, которые физически, на уровне кода выключают отдельные фичи. Если фича не готова к релизу, то релизная команда просто выключает рубильник, связанный с фичей. Это позволило командам спокойно разрабатывать фичи, не блокируя общий релизный процесс.
В целом бизнес и разработка адаптировались к Agile методологии и переварили ее, слегка изменив по дороге. Ждем следующую волну...
Следующая волна
Сейчас уже очевидно, что следующая волна изменений в методологиях разработки будет связана с появлением LLM моделей и ChatGPT.
Уже сейчас ChatGPT выдает вполне работоспособный код для решения локальных задач. Единственная проблема, что этот код сложно использовать в больших проектах, так как ChatGPT пока не может учитывать контекст большого проекта. Но крупные компании разработчики, такие как Microsoft и Google вполне в состоянии прикрутить исходные коды своих проектов к контексту языковой модели. И в этом случае качество кода и решений, выдаваемое LLM моделями должно кардинально вырасти.
Очевидно, что вектор развития идет именно в этом направлении и очень скоро профессия программист выродится во что то иное. Станет не важно знание языков программирования. Да и сами языки программирования скорее всего исчезнут, так как LLM модели могут переводить аналитику сразу в машинные коды.
Думаю я еще успею застать время, когда профессия программист исчезнет полностью и мы все превратимся либо в аналитиков, либо в безработных.
Ведь что такое программист, программист это просто высокооплачиваемый транслятор кода. Он переводит язык аналитики в язык программных кодов.
ChatGPT делает ровно тоже самое, только дешевле и возможно даже лучше.
Это немного грустно, так как на моих глазах прошла целая эпоха. Программирование развивалось очень бурно и достаточно сильно изменило наш мир. Это было веселое и интересное время и мне повезло, что расцвет моей профессиональной карьеры попал именно на этот период. Но технологический прогресс не остановить и думаю что очень скоро это время станет историей.
Комментарии (21)
LyuMih
05.12.2023 06:28+3Не уверен, что ChatGPT повлияет на "Методологию разработки".
ChatGPT скорее всего следует сравнивать с StackOverflow или поиском в гугле.MaxSidorov Автор
05.12.2023 06:28+1В том то и дело, что нет. Я думаю, что со временем мы просто перестанем писать код, также как давно уже перестали писать на ассемблере. Я вот в детстве еще писал на нем, но сейчас этот навык уже не актуален, так как появились высокоуровневые языки.
Сейчас следующий этап, мы все также будем оставаться инженерами и будем продумывать решения, но кодироваться скорее всего они будут уже без нашего участия.
weirded
05.12.2023 06:28Автор всё же говорит о принципиально другой ситуации, когда языковая модель в полном контексте общей кодовой базы проекта и может переиспользовать имеющиеся в ней функции и библиотеки, плясать от того, какие зависимости уже подключены, какие ещё нет. И если у неё не получается это, у компании есть ресурсы ей помочь научится так делать, даже если это не выгодно в моменте - они вполне могут относиться к этому как к капитальному вложению и, в принципе, будут правы. При этом вопроса утечки кода не стоит, т.к. для них это будет in-house система. При этом у такой модели будут дополнительные возможности для исполнения, например прогон линтеров, тестов, профилировщиков и бенчмарков, доступом к системам мониторинга, сбора метрик и ошибок, как обратной связи для самоанализа. Да даже тестовым стендом можно обеспечить, чтобы обкатывала релизы, которые сама и сгенерировала. С таким подспорьем моделька, как мне кажется, таки может обеспечивать качественный сдвиг по сравнению с условным copilot / чатом.
Вряд ли в ближайшие пять лет это будет доступно всем, но если будут делать as a service, на бизнес и отношение к собственным наработкам оно таки может повлиять и сдвинуть грань, между
да в смысле выложить в гугл исходники, в разработку которых мы вбухали не один лям?!
в смысле дать third party системе с доступом из интернета права на управление закрытым контуром информационной системы?!
и
да нахер мне ещё N лямов в зарплаты разработчиков вбухивать, когда за 24 часа и месячную ЗП миддла эта моделька пять фич до прода докатит с меньшим числом багов и простоев чем эти остолопы?!
Разумеется в какой-то момент что-то будет идти не так, но когда такого не было? :)
MaxSidorov Автор
05.12.2023 06:28В том то и дело, что Microsoft и Google уже это делают со своей кодовой базой в своих собственных in-house решениях. А недавний релиз Open AI уже говорит о том, что эта модель выходит за пределы больших корпораций. Я думаю у нас осталось 5-10 лет, прежде чем это станет мейнстримом.
nikolz
05.12.2023 06:28Не соглашусь с авторам. Полагаю, что следующее утверждение ошибочно:
"Сначала была модель водопада waterfall. Она зародилась где то в 70-х годах и слава богу я ее не застал. Тогда компьютеры были уделом больших корпораций. Персональных компьютеров еще не существовало и к разработке софт подходили примерно также, как к разработке больших инженерных продуктов, например автомобиля или ракеты. "
Да персональных еще не было, так как Интел выпустили свой 8080 а моторола свой 6800 в 1974.
Но были мини ЭВМ PDP8, PDP11 и их аналоги в СССP СМ400, СМ6000, СМ1...СМ4, на которых писали программы даже студенты, и я в том числе.
----------------------
Да были крупные разработки например OS360 - IBM. Но такие проекты и сейчас делают лишь крупные игроки.
MaxSidorov Автор
05.12.2023 06:28+1Тут речь идет о том, что в то время еще не было персональных компьютеров и все программирование было уделом больших компаний. В СССР это были НИИ и вычислительные центры на предприятиях. В те времена ни у кого дома еще не было персональных компьютеров.
sukhe
05.12.2023 06:28+3Программирование свернуло куда-то не туда. Раньше, например, что-то типа персонального To-Do List-а программист спокойно писал за пару дней в одиночку. Сейчас чтобы это написать, нужен скрам-мастер, проджект-менеджер, девопс, фронтендер, бекендер, тестировщик, дизайнер, и вся эта балалайка разворачивается на AWS c возможностью масштабирования до миллионов пользователей, хотя это тот-же самый туду лист для одного человека.
xxxDef
05.12.2023 06:28+1самый эффективный метод обмена информацией в команде — личная встреча
Так вот откуда все началось. Все эти бесконечные созвоны, все эти "надо проговорить", все эти дейлики и стендапы.
Когда уже появится методология в которой первым пунктом будет требование "никаких менеджеров на проекте"?
MaxSidorov Автор
05.12.2023 06:28+1Статья как раз об этом, что судя по всему скоро будет "никаких программистов на проекте"). Менеджеры всегда выигрывали эту войну и видимо на этот раз победа будет окончательной)
Gromilo
05.12.2023 06:28+1У нас в компании нет менеджеров, но я полностью согласен, что
самый эффективный метод обмена информацией в команде — личная встреча
VitalyOborin
05.12.2023 06:28ChatGPT - это все-таки инструмент, а не методология. Уже сейчас его можно использовать для решения каких-то небольших вопросов, например, написать какой-то небольшой класс и ChatGPT его напишет. Но программист всё равно нужен, чтобы его проверить, скорректировать, встроить в систему. На современных автозаводах почти все делается роботами, но проверка качества их работы и детальная точная сборка все-таки выполняется людьми. Также и в ИТ будет - самую простую и нудную работу будет делать ИИ, а человек ее проверять и интегрировать.
MaxSidorov Автор
05.12.2023 06:28Да, но кодирование - это как раз ты самая нудная и простая работа, за которую нам платят много денег. Потому что обычный человек не может кодировать. Но обычный человек вполне может неплохо думать и генерировать идеи и для этого ему не нужно учится десятки лет. Сейчас в программировании очень высокий порог входа, а будет низкий.
ChatGPT это транслятор. Сейчас аналитик продумывает систему. Разработчик переводит аналитику в программный язык, по сути выполняя роль транслятора. С LLM моделями в перспективе 10 лет разработчик в этой схеме станет лишним.gatoazul
05.12.2023 06:28+1Вы не пробовали с помощью нейросеток нарисовать то, что нужно именно вам? Попробуйте и оптимизма насчет программирования у вас поубавится.
MaxSidorov Автор
05.12.2023 06:28У меня проблемы с пессимизмом)
Я пробовал генерировать код с помощью chatGPT и результаты уже сейчас поражают.
Krawler
05.12.2023 06:28Не путайте пожалуйста разработчиков и кодеров) Разработчик - это человек, который при необходимости способен по всему SDLC практически пройти (если мы говорим про честных Software Engineer). А вы его сводите к роли "транслятора"
MaxSidorov Автор
05.12.2023 06:28+1Мне кажется когда то давно таксисты тоже говорили по контр-аварийное вождение и все такое.
В работе разработчика на самом деле есть две большие составляющие. Кодирование и использование типовых паттернов и подходов для проектирования типового решения. Тот высокий термин Software Engineer - это просто опыт, который равен знанию многих типовых паттернов. ИИ вполне способен решать обе эти задачи. И есть крайне редкие моменты, когда мы действительно создаем что то новое, что никто никогда не делал или то, что еще не стало типовым подходом. Вы часто в своей жизни создавали что то подобное?ALexKud
05.12.2023 06:28Лично я только и занимаюсь нетиповыми задачами. Как
архитектор и как разработчик. И в той области где я работаю и через 5 лет никакой ИИ не построит архитектуру приложения. Сейчас я использую тот же Bard просто как интеллектуальный поиск по некоторым софтверным фрагментам и не более потому что тон точнее чем поиск в гугле. И вряд ли что изменится через пять лет для меня. Для web разработки возможно будут изменения но не в области встраиваемого софта электроники.
BlackSCORPION
05.12.2023 06:28Вы правы, но добавлю ложку дёгтя в вашу бочку меда. Текущий ИИ обучается на том что придумали люди, если он заменит людей в программировании, он размоет основу на которой стоит и застрянет в своём развитии иза отсутствия новых данных для обучения. А люди разучаться программировать и мы вместе потонем в океане легаси
MaxSidorov Автор
05.12.2023 06:28Мне кажется в перспективе все будет еще хуже. ИИ учится за дни тому, чему люди учатся десятилетиями. Я боюсь, что в какой то момент образование может обесценится. Зачем учится 10-20 лет тому, что ИИ уже и так умеет. И тогда начнется деградация. Скорее всего, к тому времени ИИ уже будет вполне самостоятельной и независимой веткой в общей эволюции разума на нашей планете. А люди со временем просто вымрут, как когда то вымерли динозавры.
По сути для полноценного разума ИИ не хватает реализации самосознания, которое даст ему мотивации и цели.
Вроде мы сами еще не до конца понимаем, что это такое и как оно работает. Но как только мы поймем и опишем что это такое, с человечеством можно будет простится.
Ravager
05.12.2023 06:28Но обычный человек вполне может неплохо думать и генерировать идеи и для этого ему не нужно учится десятки лет.
кодирование - это как раз ты самая нудная и простая работа, за которую нам платят много денег
на словах и идеях оно всегда просто. а машина увы это не человек, ей нужны конкретные инструкции. и вот тут начинается проблема. проблема эта отсутствие системного и логического мышления.
profFortran
Я вижу примерно так:
2009 - примерно 2013: мы фигачим код, манагеры сношают мозг.
примерно 2013 - н.в.: мы фигачим код, манагеры сношают мозг. Но уже типа по аджайлу. Полнейший срам, тьфу, скрам.
Всё как в методологии Programming, Motherfucker.