kurmanka

Categories:

Сложность при разработке software

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

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

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

Как?

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

Во-первых, это увеличение объёма текста, информации. По мере роста объёма текста, требуются всё новые и новые введения, индексы и перекрёстные ссылки; по мере добавления комментариев в код, он становится "разбавленным". В какой-то момент возникает соблазн/необходимость составить список документов, а затем и список списков и возникает новый "фронт" нагромождения.

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

Итак, я отправляюсь в thinking aloud поход в поиске способов конструктивно управляться с нагромождением сложности в долгосрочных software проектах.


Error

Anonymous comments are disabled in this journal

default userpic

Your reply will be screened

Your IP address will be recorded