Когда технический долг команды потихоньку начинает превышать все мыслимые и немыслимые границы, то у команды появляется как минимум два способа его погашения: отрефакторить систему таким образом, чтобы стоимость будущих изменений была не столь высокой или оставить текущую версию системы в покое и переписать все заново. В первом случае легко столкнуться с синдромом рефакторинга, когда изменения делаются не с расчетом уменьшения стоимости будущих изменений, а вносятся просто ради изменений. Во втором же случае может возникнуть «эффект второй системы», когда развиваются и совершенствуются уже никому не нужные функции системы, а мысль «а не переписать ли все нафиг» является первой и единственной, которая приходит в голову команде, как только она сталкивается с чужим кодом.
И хотя в классическом понимании «эффект второй системы» немного отличается от паталогической нелюбви к чужому коду и постоянному его переписыванию, оба эти случая имеют и что-то общее, так что имеет смысл оба эти симптома рассмотреть совместно.
Если посмотреть внимательно по сторонам, то можно заметить замечательное проявление эффекта второй системы при… воспитании детей. Бабушки и дедушки зачастую относятся к воспитанию внуков совсем не так, как они относились к воспитанию собственных детей. Да и сами родители очень часто стараются исправить свои собственные проблемы, прививая детям любовь к тому, что интересно им, стараясь, чтобы дети добились их недостигнутых целей.
Поскольку многие разработчики и архитекторы тоже вкладывают свою душу при создании программных систем, совсем не удивительно, что приступая к новой версии своего детища, они стараются исправить все ошибки и недочеты, и пытаются создать идеальную систему. Кроме того, окрыленные успехом первой системы (в случае неудачи все просто, до второй версии системы дело просто не доходит) разработчики начинают думать, что у них достаточно знаний и опыта в данной предметной области, чтобы на основе существующий частных знаний делать общие выводы. Это зачастую приводит к преждевременному обобщению (premature generalization) решения, что очень часто считается злом не меньшим, чем преждевременная оптимизация (*).
Другой проблемой при создании второй системы является неправильная переоценка ценностей, когда доводятся до совершенства морально устаревшие функции системы, а принципиально новые подходы и решения не развиваются. Это приводит к потрясающей реализации никому не нужных функций, что может и полезно с чисто эстетической точки зрения, но вряд ли полезно для успеха системы.
Все эти проблемы описаны еще Фредериком Бруксом в его «Мифическом человеко-месяце», где помимо описания этой проблемы даются и рекомендации по ее решению. И хотя она вышла задолго до другой замечательной книги Энди Ханта и Дэйва Томаса «Программист-прагматик», Брукс дает тот же самый совет, что и постоянно звучит в книге прагматиков: не нужно крайностей, и побольше прагматизма и самодисциплины.
Согласитесь, что мы-то с вами знаем, почему разработка предыдущей системы, которую делала соседняя команда, провалилась. Вот если бы я руководил бы ее разработкой (был бы ее архитектором/лидом/девелопером подчеркнуть нужный вариант), я бы все сделал по-другому, и мы бы точно не сорвали сроки на полгода, да и глюков было бы в 4 раза меньше.
Однако проблема заключается в том, что большинство людей с некоторым высокомерием смотрит на неудачи других людей, близоруко считая, что они бы справились лучше. 87,5 процентов программистов считают, что они бы эту работу сделали лучше, и лишь 2,5 процента (**) из них сделали бы ее лучше на самом деле. Остальные же просто сделали бы ее «по своему», правда с тем же успехом в плане сроков, качества и функциональности.
Помимо программистов подобной фигней страдают еще руководители и заказчики. Сколько раз вы сталкивались с ситуацией, когда вам «предлагали» переписать систему, просто потому что в текущей версии уже никто не разбирается? Причем требования пред��агалось выуживать самостоятельно из кода этой же системы, по которому прошлось стадо индусов. Так что понять, что за хрень там происходит уже весьма сложно, и что должно быть в результате также понятно, как теория относительности десятилетнему ребенку.
В результате качество новой системы определяется самым слабым звеном всей цепочки разработки, а при отсутствии требований, высоким оно уже никак быть не может. Вот и получаются те же яйца, но вид сбоку, правда на некоторое время новая система становится более «расширяемой», поскольку она пока что понятна той паре бойцов, рассекретивших существующую логику в процессе ее переноса в новую систему.
Если синдромом второй системы при желании можно побороть или, по крайней мере, существенно снизить риск клинических случаев, то с проблемой переписывания справиться несколько сложнее. Если склонность к переписыванию таится в душе программиста или архитектора, то бороться с ней нужно аналогичным образом. Действительно существуют случаи, когда не просто можно, но именно нужно сжечь мосты и начать все с чистого листа, но в большинстве случаев к таким попыткам нужно точно так же относиться с прагматизмом и осторожностью.
Если же это является требованием менеджера или даже заказчика, то в этом случае, скорее всего альтернатив просто не останется: придется переписывать; при этом просто стоит постараться не променять шило на мыло и постараться максимально учесть основные ошибки предыдущей системы.
--------------------------------------
(*) В некотором роде преждевременное обобщение можно рассматривать, как преждевременную оптимизацию архитектурных решений. Разница заключается лишь в том, что когда речь заходит о преждевременной оптимизации, то это касается ненужного расточительства трудовых ресурсов, направленных на ненужное повышение производительности приложения. А когда речь заходит о преждевременном обобщении, то это касается аналогичной по смыслу траты времени и сил, но на ненужное обобщение решения.
(**) Научно доказано, что 78,5% статистических данных берутся с потолка:)
И хотя в классическом понимании «эффект второй системы» немного отличается от паталогической нелюбви к чужому коду и постоянному его переписыванию, оба эти случая имеют и что-то общее, так что имеет смысл оба эти симптома рассмотреть совместно.
Классический эффект второй системы
Если посмотреть внимательно по сторонам, то можно заметить замечательное проявление эффекта второй системы при… воспитании детей. Бабушки и дедушки зачастую относятся к воспитанию внуков совсем не так, как они относились к воспитанию собственных детей. Да и сами родители очень часто стараются исправить свои собственные проблемы, прививая детям любовь к тому, что интересно им, стараясь, чтобы дети добились их недостигнутых целей.
Поскольку многие разработчики и архитекторы тоже вкладывают свою душу при создании программных систем, совсем не удивительно, что приступая к новой версии своего детища, они стараются исправить все ошибки и недочеты, и пытаются создать идеальную систему. Кроме того, окрыленные успехом первой системы (в случае неудачи все просто, до второй версии системы дело просто не доходит) разработчики начинают думать, что у них достаточно знаний и опыта в данной предметной области, чтобы на основе существующий частных знаний делать общие выводы. Это зачастую приводит к преждевременному обобщению (premature generalization) решения, что очень часто считается злом не меньшим, чем преждевременная оптимизация (*).
Другой проблемой при создании второй системы является неправильная переоценка ценностей, когда доводятся до совершенства морально устаревшие функции системы, а принципиально новые подходы и решения не развиваются. Это приводит к потрясающей реализации никому не нужных функций, что может и полезно с чисто эстетической точки зрения, но вряд ли полезно для успеха системы.
Все эти проблемы описаны еще Фредериком Бруксом в его «Мифическом человеко-месяце», где помимо описания этой проблемы даются и рекомендации по ее решению. И хотя она вышла задолго до другой замечательной книги Энди Ханта и Дэйва Томаса «Программист-прагматик», Брукс дает тот же самый совет, что и постоянно звучит в книге прагматиков: не нужно крайностей, и побольше прагматизма и самодисциплины.
Синдром «А не переписать ли все нафиг»
Согласитесь, что мы-то с вами знаем, почему разработка предыдущей системы, которую делала соседняя команда, провалилась. Вот если бы я руководил бы ее разработкой (был бы ее архитектором/лидом/девелопером подчеркнуть нужный вариант), я бы все сделал по-другому, и мы бы точно не сорвали сроки на полгода, да и глюков было бы в 4 раза меньше.
Однако проблема заключается в том, что большинство людей с некоторым высокомерием смотрит на неудачи других людей, близоруко считая, что они бы справились лучше. 87,5 процентов программистов считают, что они бы эту работу сделали лучше, и лишь 2,5 процента (**) из них сделали бы ее лучше на самом деле. Остальные же просто сделали бы ее «по своему», правда с тем же успехом в плане сроков, качества и функциональности.
Помимо программистов подобной фигней страдают еще руководители и заказчики. Сколько раз вы сталкивались с ситуацией, когда вам «предлагали» переписать систему, просто потому что в текущей версии уже никто не разбирается? Причем требования пред��агалось выуживать самостоятельно из кода этой же системы, по которому прошлось стадо индусов. Так что понять, что за хрень там происходит уже весьма сложно, и что должно быть в результате также понятно, как теория относительности десятилетнему ребенку.
В результате качество новой системы определяется самым слабым звеном всей цепочки разработки, а при отсутствии требований, высоким оно уже никак быть не может. Вот и получаются те же яйца, но вид сбоку, правда на некоторое время новая система становится более «расширяемой», поскольку она пока что понятна той паре бойцов, рассекретивших существующую логику в процессе ее переноса в новую систему.
Если синдромом второй системы при желании можно побороть или, по крайней мере, существенно снизить риск клинических случаев, то с проблемой переписывания справиться несколько сложнее. Если склонность к переписыванию таится в душе программиста или архитектора, то бороться с ней нужно аналогичным образом. Действительно существуют случаи, когда не просто можно, но именно нужно сжечь мосты и начать все с чистого листа, но в большинстве случаев к таким попыткам нужно точно так же относиться с прагматизмом и осторожностью.
Если же это является требованием менеджера или даже заказчика, то в этом случае, скорее всего альтернатив просто не останется: придется переписывать; при этом просто стоит постараться не променять шило на мыло и постараться максимально учесть основные ошибки предыдущей системы.
--------------------------------------
(*) В некотором роде преждевременное обобщение можно рассматривать, как преждевременную оптимизацию архитектурных решений. Разница заключается лишь в том, что когда речь заходит о преждевременной оптимизации, то это касается ненужного расточительства трудовых ресурсов, направленных на ненужное повышение производительности приложения. А когда речь заходит о преждевременном обобщении, то это касается аналогичной по смыслу траты времени и сил, но на ненужное обобщение решения.
(**) Научно доказано, что 78,5% статистических данных берутся с потолка:)
