Колхоз программистов
Thursday, 1 March 2007 12:04![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
andrzejnСкорость развития информационных технологий сейчас ограничена только способностью разработчиков и пользователей эти новые технологии осваивать. Это, в общем, известно всем, кому надо. Средних размеров проект годовой длительности начинается на свежайших, даже порой бета-версиях платформ и библиотек - а к завершению успевает устареть на одну-две версии всего, чем пользуется. Через три-четыре года после релиза его почти наверняка захотят заменить, переписав на свежих технологиях того времени. Возьмутся ли немедленно заменять - это отдельный вопрос, но захотят. И если к тому времени разработчики предыдущей версии окажутся всё ещё под рукой, а не перейдут в более интересное место, то можно считать, что повезло.
Требование "система должна быть способна прослужить хотя бы лет пятнадцать", которое сегодня озвучили в статье "What Could Possibly Be Worse Than Failure?", в таких условиях напоминает издевательство. Хотя требование вполне здравое: зачастую системы таки служат лет по пятнадцать-двадцать, несмотря на то, что у всех давно чешутся руки их переписать. Бюджетные ограничения, что поделать.
Получается, что нынешняя база программного обеспечения - это громадная сложносвязанная куча сравнительно небольших кусков кода, вокруг которой вьются разработчики. Слетаются на запах денег, добавляют или заменяют несколько кусков и вновь теряются в дымке. Энтузиасты-разработчики бесплатного софта поступают точно так же, только их привлекает не запах денег, а интересный блеск отдельных частей кучи. Суть от этого не меняется: любая полезная программа за время своей жизни многократно переходит из рук в руки, причём даже не целиком, а фрагментами.
Отсюда с очевидностью следует, что внимание в современной разработке софта переносится с начальных затрат создания первой версии на обеспечение долгосрочной поддержки и модификаций. Должно переноситься. Это тоже известная вещь. Любой код нужно писать так, чтобы человек со стороны мог в нём разобраться за разумное время и доработать по необходимости, не поломав остальную систему.
Однако затраты на начальную разработку тоже никто не отменял. Релиз первой версии подгоняют не менее, а то и более, чем последующие версии и апгрейды. Как заставить разработчиков следить за доступностью кода в таких условиях?
Решение - коллективное владение кодом. Абсолютный коммунизм экстремального программирования, когда кто угодно может когда угодно влезть куда угодно и дописать, что нужно - это чересчур, это работает не со всякой командой. Но за время разработки каждый модуль должен хотя бы раз перейти от одного разработчика к другому. Это замедляет разработку, зато программисты удерживаются от соблазна писать невнятный код, когда знают, что вскоре в нём будет копаться коллега, приставая к автору с вопросами и ехидными замечаниями. Да оно и вообще полезно на случай, когда кто-нибудь вдруг заболевает или увольняется - никто не уносит с собой уникальные знания о системе.
Требование "система должна быть способна прослужить хотя бы лет пятнадцать", которое сегодня озвучили в статье "What Could Possibly Be Worse Than Failure?", в таких условиях напоминает издевательство. Хотя требование вполне здравое: зачастую системы таки служат лет по пятнадцать-двадцать, несмотря на то, что у всех давно чешутся руки их переписать. Бюджетные ограничения, что поделать.
Получается, что нынешняя база программного обеспечения - это громадная сложносвязанная куча сравнительно небольших кусков кода, вокруг которой вьются разработчики. Слетаются на запах денег, добавляют или заменяют несколько кусков и вновь теряются в дымке. Энтузиасты-разработчики бесплатного софта поступают точно так же, только их привлекает не запах денег, а интересный блеск отдельных частей кучи. Суть от этого не меняется: любая полезная программа за время своей жизни многократно переходит из рук в руки, причём даже не целиком, а фрагментами.
Отсюда с очевидностью следует, что внимание в современной разработке софта переносится с начальных затрат создания первой версии на обеспечение долгосрочной поддержки и модификаций. Должно переноситься. Это тоже известная вещь. Любой код нужно писать так, чтобы человек со стороны мог в нём разобраться за разумное время и доработать по необходимости, не поломав остальную систему.
Однако затраты на начальную разработку тоже никто не отменял. Релиз первой версии подгоняют не менее, а то и более, чем последующие версии и апгрейды. Как заставить разработчиков следить за доступностью кода в таких условиях?
Решение - коллективное владение кодом. Абсолютный коммунизм экстремального программирования, когда кто угодно может когда угодно влезть куда угодно и дописать, что нужно - это чересчур, это работает не со всякой командой. Но за время разработки каждый модуль должен хотя бы раз перейти от одного разработчика к другому. Это замедляет разработку, зато программисты удерживаются от соблазна писать невнятный код, когда знают, что вскоре в нём будет копаться коллега, приставая к автору с вопросами и ехидными замечаниями. Да оно и вообще полезно на случай, когда кто-нибудь вдруг заболевает или увольняется - никто не уносит с собой уникальные знания о системе.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: Thursday, 1 March 2007 10:25 (UTC)no subject
Date: Thursday, 1 March 2007 10:56 (UTC)no subject
Date: Thursday, 1 March 2007 16:27 (UTC)