Как-то на днях я с товарищем разговорился на тему того, что есть процесс разработки, работают ли программисты или давят клопов? Может ли любой стать разработчиком? В чем вообще сложность процесса разработки ПО? Надеюсь наш диалог поможет разобраться в деле тем, кто сам не занимается программированием или просто любит поразмышлять о своем любимом занятии.
И началось всё с достаточно популярного вопроса.
— Почему бюджет на разработку проекта часто оказывается превышен?
— Это непростой вопрос. Предлагаю взять за основу одну метафору, которая поможет мне объяснить положение вещей. Конечно это моё мнение, основанное на том опыте, что получил я.
Так вот, разработчики – творцы новых миров. Виртуальных миров.
— Ты бы ещё про фильм Матрица мне рассказал!
— На самом деле метафора оттуда. Так вот. Входные требования дают представление о том, какой мир нужен заказчику (заказчик может быть и внутри компании).
Чаще всего требования широкие и размытые.
— Погоди. Почему сразу размытые? Например, у меня проект который я хочу запустить. Я чётко понимаю как он должен работать. Более того, у меня есть ТЗ!!!
— Хах. Да, но о многих аспектах этого нового мира заказчик не думает и не должен, ведь это работа разработчиков. Как организовать исходный код? Какой конвенции именования переменных следовать? Какие библиотеки использовать? Какую стратегию разделения на ветки использовать? Как обеспечить быстродействие?
По большому счету, задача разработчика – заложить в этот новый мир такие законы, чтобы этот мир решал исходную задачу. Соотнести бизнес или функциональные требования с требованиям к законам нового мира. Более того, этот мир постоянно должен изменяться под воздействием новых требований и информации.
— Допустим, но какое это имеет отношение к бюджету и срокам?
— Давай подумаем, что влияет на количество времени, а следовательно и на бюджет, необходимый для создания новой фичи на проекте?
Ну вот есть некая фича. Есть время чтобы понять как ее делать. Чтобы ее реализовать и протестировать. И допустим что разработчик обладает всей информацией о том как делать – он отлично знает нужные технологии, языки программирования и подходы. Он понимает требования – знает как должно работать в итоге.
Будет ли время реализации задачи равно времени написания кода? Конечно нет. Помимо всего этого, разработчик должен встроить новую фичу в уже существующий мир. Встроить в существующие законы. Добавить новые законы или изменить существующие, так чтобы и старые и новая фича работала.
Это как раз и есть самое сложное, потому что сложность этих вопросов чаще всего в разы выше сложности реализации самой фичи.
— Это как строить дом? Например если я хочу добавить ещё одно окно в комнату, я должен учесть хватит ли отопления? Не нарушу ли я законы теплообмена?
— Именно. А теперь представь, что теплообмен это всего лишь один аспект. В сложных программных системах таких аспектов сотни, если не тысячи. Представь, при реализации каждой небольшой новой фичи необходимо уделить внимание на все аспекты. И только сейчас я могу попробовать объяснить основную идею. По мере создания и развития таких миров (проектов), количество законов и правил внутри постоянно растет. Отследить, что какой-то закон этого мира устарел и от него нужно избавиться — не так-то и просто.
Мир обрастает лишними правилами. Члены команды разработки начинают жить в более сложном мире, их трудозатраты возрастают.
— А почему нельзя постепенно пересматривать что было понаделано и упрощать, убирать лишнее?
— Так можно. Есть даже конкретные практики — непрерывный рефакторинг и так далее. Но провести само-рефлексию на уровне команды удаётся редко, особенно на техническом уровне. Да и найти все проблемы сложно — размер проектов всё больше и больше. Можно только присматривать за тем чтобы архитектура при реализации конкретных задач не становилась хуже.
Как результат разработчик живет с пониманием того что задача сложно решаема — ведь много связей нужно перестроить, в этом его выдуманном мире. Оценки завышаются. Задачи действительно занимают больше времени чем могли бы.
Это как бег с отягощением — энергии тратится значительно больше на преодоление того же расстояния.
— Другой сценарий – разработчики не завышают оценки, потому что не видят возрастающей сложности, хотя она есть. Законы в их мире уже есть, они просто их не знают. И как в реальной жизни – незнание законов не освобождает от ответственности. Это ведёт либо к накоплению технического долга – проблемы есть, но всплывут впоследствии. Либо реализация новых фич ведёт к обрушению других частей системы, и это может быть не сразу заметно – вы не всегда перепроверяете всю работу и что то всплывет потом (что по сути увеличивает стоимость конкретной фичи). Ах да, автотесты скажешь ты – но дешево ли обходится их разработка? Проверяют ли они работоспособность на 100%?
— Да брось, мне кажется ты нагнетаешь – а как же модульность? Даже я – не программист, понимаю как бороться со сложностью. Разделить на части. Разделить зоны ответственности.
— Ты прав. Именно на это направлено большинство современных практик программирования. Например, может ты слышал про микросервисную архитектуру. Разработчики пытаются понизить сложность систем путем ограничения объема ответственности.
Но проблемы остаются все те же, просто часть из них переходит в другую плоскость – интеграция. Налаживание связей между теми самыми модулями или сервисами.
Хотел привести тебе ещё один пример о предыдущем тезисе – сложности внесения изменений в существующие законы.
Люблю философствовать на эту тему. Почему сложно увидеть необходимость изменений?
Когда ты создал мир, и не просто знаешь его законы, они рождены тобой, тяжело воспринимать вещи по-другому. Самому же подвергнуть свою логику сильной критике – так можно и до шизофрении дойти. И перекраивать эти законы может быть очень сложно. Не всегда долго, но сложно, потому что это требует смены какой-то парадигмы этого мира в голове конкретного разработчика или всей команды. Представь что тебе нужно переосмыслить все в реальном мире если измениться понимание закона гравитации. Или например вдруг, ты выяснил, что земля всё-таки плоская? Это настолько базовые понятия и они настолько вплетены в нашу жизнь, что процесс переосмысления может занять всю жизнь. И по сути реально ничего не изменит кроме твоего восприятия этого мира. Поэтому разработчики не любят менять свои парадигмы. Во всяком случае большинство. Комфортнее написать больше кода в старой парадигме, чем изменить парадигму чтобы упростить какую-то частность.
— Кажется, я начинаю понимать. Конечно сложно сходу примерить на себя и осознать всю эту сложность просто поговорив с тобой, но как минимум я начал больше понимать специфику работы. Пожалуй, на сегодня мне достаточно пищи для размышлений, но с удовольствием продолжу наш диалог при следующей встрече…
И началось всё с достаточно популярного вопроса.
— Почему бюджет на разработку проекта часто оказывается превышен?
— Это непростой вопрос. Предлагаю взять за основу одну метафору, которая поможет мне объяснить положение вещей. Конечно это моё мнение, основанное на том опыте, что получил я.
Так вот, разработчики – творцы новых миров. Виртуальных миров.
— Ты бы ещё про фильм Матрица мне рассказал!
— На самом деле метафора оттуда. Так вот. Входные требования дают представление о том, какой мир нужен заказчику (заказчик может быть и внутри компании).
Чаще всего требования широкие и размытые.
— Погоди. Почему сразу размытые? Например, у меня проект который я хочу запустить. Я чётко понимаю как он должен работать. Более того, у меня есть ТЗ!!!
— Хах. Да, но о многих аспектах этого нового мира заказчик не думает и не должен, ведь это работа разработчиков. Как организовать исходный код? Какой конвенции именования переменных следовать? Какие библиотеки использовать? Какую стратегию разделения на ветки использовать? Как обеспечить быстродействие?
По большому счету, задача разработчика – заложить в этот новый мир такие законы, чтобы этот мир решал исходную задачу. Соотнести бизнес или функциональные требования с требованиям к законам нового мира. Более того, этот мир постоянно должен изменяться под воздействием новых требований и информации.
— Допустим, но какое это имеет отношение к бюджету и срокам?
— Давай подумаем, что влияет на количество времени, а следовательно и на бюджет, необходимый для создания новой фичи на проекте?
Ну вот есть некая фича. Есть время чтобы понять как ее делать. Чтобы ее реализовать и протестировать. И допустим что разработчик обладает всей информацией о том как делать – он отлично знает нужные технологии, языки программирования и подходы. Он понимает требования – знает как должно работать в итоге.
Будет ли время реализации задачи равно времени написания кода? Конечно нет. Помимо всего этого, разработчик должен встроить новую фичу в уже существующий мир. Встроить в существующие законы. Добавить новые законы или изменить существующие, так чтобы и старые и новая фича работала.
Это как раз и есть самое сложное, потому что сложность этих вопросов чаще всего в разы выше сложности реализации самой фичи.
— Это как строить дом? Например если я хочу добавить ещё одно окно в комнату, я должен учесть хватит ли отопления? Не нарушу ли я законы теплообмена?
— Именно. А теперь представь, что теплообмен это всего лишь один аспект. В сложных программных системах таких аспектов сотни, если не тысячи. Представь, при реализации каждой небольшой новой фичи необходимо уделить внимание на все аспекты. И только сейчас я могу попробовать объяснить основную идею. По мере создания и развития таких миров (проектов), количество законов и правил внутри постоянно растет. Отследить, что какой-то закон этого мира устарел и от него нужно избавиться — не так-то и просто.
Мир обрастает лишними правилами. Члены команды разработки начинают жить в более сложном мире, их трудозатраты возрастают.
— А почему нельзя постепенно пересматривать что было понаделано и упрощать, убирать лишнее?
— Так можно. Есть даже конкретные практики — непрерывный рефакторинг и так далее. Но провести само-рефлексию на уровне команды удаётся редко, особенно на техническом уровне. Да и найти все проблемы сложно — размер проектов всё больше и больше. Можно только присматривать за тем чтобы архитектура при реализации конкретных задач не становилась хуже.
Как результат разработчик живет с пониманием того что задача сложно решаема — ведь много связей нужно перестроить, в этом его выдуманном мире. Оценки завышаются. Задачи действительно занимают больше времени чем могли бы.
Это как бег с отягощением — энергии тратится значительно больше на преодоление того же расстояния.
— Другой сценарий – разработчики не завышают оценки, потому что не видят возрастающей сложности, хотя она есть. Законы в их мире уже есть, они просто их не знают. И как в реальной жизни – незнание законов не освобождает от ответственности. Это ведёт либо к накоплению технического долга – проблемы есть, но всплывут впоследствии. Либо реализация новых фич ведёт к обрушению других частей системы, и это может быть не сразу заметно – вы не всегда перепроверяете всю работу и что то всплывет потом (что по сути увеличивает стоимость конкретной фичи). Ах да, автотесты скажешь ты – но дешево ли обходится их разработка? Проверяют ли они работоспособность на 100%?
— Да брось, мне кажется ты нагнетаешь – а как же модульность? Даже я – не программист, понимаю как бороться со сложностью. Разделить на части. Разделить зоны ответственности.
— Ты прав. Именно на это направлено большинство современных практик программирования. Например, может ты слышал про микросервисную архитектуру. Разработчики пытаются понизить сложность систем путем ограничения объема ответственности.
Но проблемы остаются все те же, просто часть из них переходит в другую плоскость – интеграция. Налаживание связей между теми самыми модулями или сервисами.
Хотел привести тебе ещё один пример о предыдущем тезисе – сложности внесения изменений в существующие законы.
Люблю философствовать на эту тему. Почему сложно увидеть необходимость изменений?
Когда ты создал мир, и не просто знаешь его законы, они рождены тобой, тяжело воспринимать вещи по-другому. Самому же подвергнуть свою логику сильной критике – так можно и до шизофрении дойти. И перекраивать эти законы может быть очень сложно. Не всегда долго, но сложно, потому что это требует смены какой-то парадигмы этого мира в голове конкретного разработчика или всей команды. Представь что тебе нужно переосмыслить все в реальном мире если измениться понимание закона гравитации. Или например вдруг, ты выяснил, что земля всё-таки плоская? Это настолько базовые понятия и они настолько вплетены в нашу жизнь, что процесс переосмысления может занять всю жизнь. И по сути реально ничего не изменит кроме твоего восприятия этого мира. Поэтому разработчики не любят менять свои парадигмы. Во всяком случае большинство. Комфортнее написать больше кода в старой парадигме, чем изменить парадигму чтобы упростить какую-то частность.
— Кажется, я начинаю понимать. Конечно сложно сходу примерить на себя и осознать всю эту сложность просто поговорив с тобой, но как минимум я начал больше понимать специфику работы. Пожалуй, на сегодня мне достаточно пищи для размышлений, но с удовольствием продолжу наш диалог при следующей встрече…