Comments 17
После прочтения книги Брукса или Ханта эти особенности развития систем ясны и понятны. Только где же собственный вывод из этих книг? Статья кончилась, не успев начаться. Куда идти и что делать? Может придумать алгоритм действий при возникновении «переписать все нафиг» или создать руководство «для разработчиков вторых систем»?
А мне вот нравятся такие выдержки на полторы страницы из американских книг по 800 листов, где раз по 15 повторяется одно и то же разными словами.
Книга Брукса гораздо менее объемна, чем тот же «Совершенный код» Макконела. Просто при обычных выдержках и пересказах может быть искажена основная мысль автора (не в упрек этому топику). Не зря же многие изучают английский язык, чтобы затем прочесть в оригинале «Алису в стране чудес».
Поэтому всегда хочется услышать мысли, рассуждения, вынесенные читателем из этих книг.
Поэтому всегда хочется услышать мысли, рассуждения, вынесенные читателем из этих книг.
Вывод такой: все люди идио несовершенны.
Следствия из вывода: Если вам вдруг показалось, что вы «очень умный» (грамотный манагер/тимлид/разработчик), и уж вы то точно всем покажете «как надо» — одной этой мысли недостаточно чтобы принимаемые вами (и навязываемые другим) решения были безусловно верными и не нуждались хорошей в мотивационной части с которой согласны другие участники процесса.
Следствия из вывода: Если вам вдруг показалось, что вы «очень умный» (грамотный манагер/тимлид/разработчик), и уж вы то точно всем покажете «как надо» — одной этой мысли недостаточно чтобы принимаемые вами (и навязываемые другим) решения были безусловно верными и не нуждались хорошей в мотивационной части с которой согласны другие участники процесса.
Вот блин, из-за проблем с инетом все обсуждение пропустил.
В целом смысл этой серии статей (в которую входит текущая статья, а также Технический долг и Синдром рефакторинга) заключается в желании показать типовые паттерны поведения команды разработчиков в ходе работы над проектом. Смысл этих статей в чем-то схожий с основной идеей последней книги Демарко, Листера и компании под названием «Adrenaline Junkies», в которой они прежде всего хотели обобщить некоторые паттерны поведения и придать им пригодную для повторного использования форму. Т.е. ты работаешь над проектом и вместо смутного предчувствия, типа че-то с этим проектом не так, ты легко можешь выразить это словами. «А… дело все в том, что „технический долг“ слишком велик», или «да у нас тут, батенька, классический эффект второй системы». Как мне кажется, увидеть существование подобной проблемы является первым и главным этапом на пути ее решения.
Теперь что касается решения. Как мне кажется, есть несколько ключевых идей, способных если не устранить, то, по крайней мере, существенно снизить риск подобных проблем. Во-первых, стараться не высекать решения в камне, а давать возможность от них отказаться за разумное время и количество усилий. Очень часто бывает, что вот, приняли решение использовать СОМ, и запихнули это дело в каждую дырку. Или взяли какую-то библиотеку и размазали ее использование тонким слоем по всей системе. Понятное дело, что от всего абстрагироваться нельзя (более того, это не нужно), но разумным образом минимизировать зависимости – просто необходимо.
Во-вторых, диктатура – это хорошо, и, наверное, должна быть одна голова, принимающая окончательные решения, но, мне кажется, нужно, чтобы у этой головы был как минимум один помощник, с не меньшим авторитетом и опытом. Я неоднократно сталкивался с ситуацией, когда проблемы у проекта были из-за того, что один человек значительно превосходил всех остальных по опыту и, соответственно, авторитету. Люди тупо начинают привыкать к тому, что этот человек прав и уже просто не думают самостоятельно. А ведь есть определенный круг задач, где без второго мнения просто не обойтись: это и ряд архитектурных решений, которые хорошо бы проверить на вшивость, да и разработка библиотечного кода (которым обрастает практически каждая команда), и много других задач, все это требует взгляда со стороны. Второй сильный чел, способный сыграть, когда нужно адвоката дьявола – это здорово.
Ну и в-третьих, и я об этом уже упоминал, прагматичное отношение к текущим задачам и избегание крайностей – это одно из ключевых условий спеха (хотя здесь, опять таки, без второй головы весьма тяжко). Нужно помнить, что мы работаем не ради работы (хотя, кого я обманываю, и сам процесс и эстетическая составляющая нам тоже безумно важна), иногда об этом вспоминать и принимать решения соответственно. Т.е. не страдать фигней в виде идеальных решений, а иногда забить на красоту и какие-то правила и каноны и сделать так, чтобы добиться результата; пусть не идеального, но зато в разумные сроки.
З.Ы. хз, стало ли понятнее, но в, в общем, где-то так.
В целом смысл этой серии статей (в которую входит текущая статья, а также Технический долг и Синдром рефакторинга) заключается в желании показать типовые паттерны поведения команды разработчиков в ходе работы над проектом. Смысл этих статей в чем-то схожий с основной идеей последней книги Демарко, Листера и компании под названием «Adrenaline Junkies», в которой они прежде всего хотели обобщить некоторые паттерны поведения и придать им пригодную для повторного использования форму. Т.е. ты работаешь над проектом и вместо смутного предчувствия, типа че-то с этим проектом не так, ты легко можешь выразить это словами. «А… дело все в том, что „технический долг“ слишком велик», или «да у нас тут, батенька, классический эффект второй системы». Как мне кажется, увидеть существование подобной проблемы является первым и главным этапом на пути ее решения.
Теперь что касается решения. Как мне кажется, есть несколько ключевых идей, способных если не устранить, то, по крайней мере, существенно снизить риск подобных проблем. Во-первых, стараться не высекать решения в камне, а давать возможность от них отказаться за разумное время и количество усилий. Очень часто бывает, что вот, приняли решение использовать СОМ, и запихнули это дело в каждую дырку. Или взяли какую-то библиотеку и размазали ее использование тонким слоем по всей системе. Понятное дело, что от всего абстрагироваться нельзя (более того, это не нужно), но разумным образом минимизировать зависимости – просто необходимо.
Во-вторых, диктатура – это хорошо, и, наверное, должна быть одна голова, принимающая окончательные решения, но, мне кажется, нужно, чтобы у этой головы был как минимум один помощник, с не меньшим авторитетом и опытом. Я неоднократно сталкивался с ситуацией, когда проблемы у проекта были из-за того, что один человек значительно превосходил всех остальных по опыту и, соответственно, авторитету. Люди тупо начинают привыкать к тому, что этот человек прав и уже просто не думают самостоятельно. А ведь есть определенный круг задач, где без второго мнения просто не обойтись: это и ряд архитектурных решений, которые хорошо бы проверить на вшивость, да и разработка библиотечного кода (которым обрастает практически каждая команда), и много других задач, все это требует взгляда со стороны. Второй сильный чел, способный сыграть, когда нужно адвоката дьявола – это здорово.
Ну и в-третьих, и я об этом уже упоминал, прагматичное отношение к текущим задачам и избегание крайностей – это одно из ключевых условий спеха (хотя здесь, опять таки, без второй головы весьма тяжко). Нужно помнить, что мы работаем не ради работы (хотя, кого я обманываю, и сам процесс и эстетическая составляющая нам тоже безумно важна), иногда об этом вспоминать и принимать решения соответственно. Т.е. не страдать фигней в виде идеальных решений, а иногда забить на красоту и какие-то правила и каноны и сделать так, чтобы добиться результата; пусть не идеального, но зато в разумные сроки.
З.Ы. хз, стало ли понятнее, но в, в общем, где-то так.
Цитата: «Если же это является требованием менеджера или даже заказчика...»
Идею «Переписать всю систему» обычно выдвигают технари-прогаммисты как универсальное решение требований пользователей или заказчика, реализация которых неочевидна, либо изначально вообще неподразумевалась. По хорошему, только анализ с точки зрения бизнес-перспективности и надобности второй системы, исходящий прежде всего от сути новых задач и их вариантов решения, с учетом рисков миграции на 2-ю систему может служить правильным толчком к ее разработке.
Идею «Переписать всю систему» обычно выдвигают технари-прогаммисты как универсальное решение требований пользователей или заказчика, реализация которых неочевидна, либо изначально вообще неподразумевалась. По хорошему, только анализ с точки зрения бизнес-перспективности и надобности второй системы, исходящий прежде всего от сути новых задач и их вариантов решения, с учетом рисков миграции на 2-ю систему может служить правильным толчком к ее разработке.
«Преждевременное обобщение» — хороший термин. Взял на заметку.
Кстати, если руководство умеет считать деньги, то мысли «переписать все нафиг» возникать точно не должно. С современным развитием систем программирования, есть все средства, чтобы этого избежать.
Вот пример на основе реального проекта развивающегося более 12 лет:
Есть модуль1 и модуль2.
Модуль2 использует АPI модуля1. Возникло желание к черту переписать оба модуля. Но руководство то умеет считать деньги, поэтому в модуль1 добавляется пакет модуль1версия2.
Модуль2 использует все тот же модуль1. Но весь новый код в модуле2 использует модуль1версия2.
Со временем модуль2 обрастает таким количеством кода, использующего модуль1версия2, что становится ясна стабильность и успешность принятого решения, тогда все API модуля1версия2 оборачивается API модуля1.
Постепенно API модуля1 исключается из кода, заменой API модуля1версии2.
Тем самым мы получаем взвешенное развитие успешной системы с огромной гибкостью в в расширении.
Вот пример на основе реального проекта развивающегося более 12 лет:
Есть модуль1 и модуль2.
Модуль2 использует АPI модуля1. Возникло желание к черту переписать оба модуля. Но руководство то умеет считать деньги, поэтому в модуль1 добавляется пакет модуль1версия2.
Модуль2 использует все тот же модуль1. Но весь новый код в модуле2 использует модуль1версия2.
Со временем модуль2 обрастает таким количеством кода, использующего модуль1версия2, что становится ясна стабильность и успешность принятого решения, тогда все API модуля1версия2 оборачивается API модуля1.
Постепенно API модуля1 исключается из кода, заменой API модуля1версии2.
Тем самым мы получаем взвешенное развитие успешной системы с огромной гибкостью в в расширении.
Поддерживаю VaiMR. Статья похожа на пересказ своими словами некоторых идей из упомянутых книг. Пересказ, кстати, хороший — кратко, ясно и приятным языком, но кроме этого никакой собственной работы автора не видно.
А надо?
Желательно.
Прочесть книгу я и сам могу (тем более что это практически классика), гораздо интереснее узнать личное мнение автора по поводу прочитанного. Может быть, он сталкивался с примерами в жизни, которые бы уточняли, поясняли или даже опровергали тезисы Брукса-Ханта — вот это было бы гораздо интереснее.
Прочесть книгу я и сам могу (тем более что это практически классика), гораздо интереснее узнать личное мнение автора по поводу прочитанного. Может быть, он сталкивался с примерами в жизни, которые бы уточняли, поясняли или даже опровергали тезисы Брукса-Ханта — вот это было бы гораздо интереснее.
Разработчику, у которого есть желание «переписать весь код», нужно понимать некоторые вещи:
— Любой код, даже по которому прошлась сотня индусов, можно всегда понять
— При оценке сроков всегда изучать предварительно код. Если действительно есть необходимость исправить какой-то кусок кода или сделать рефакторинг для удобства (а не переписать всё нафиг) — заложить это в оценку, при этом, для начала, объяснив себе, зачем это будет нужно, а уж потом руководителю/тимлиду
— Не забывать про обратную совместимость никогда. Лучше пусть кусок кода будет считаться устаревшим и помечен как deprecated на дальнейшее использования, но будет продолжать работать на вас и зарабатывать вам $, чем вы однажды его выкорчуете и потом приложения обрушится ещё в паре десятков мест
— Любой код, даже по которому прошлась сотня индусов, можно всегда понять
— При оценке сроков всегда изучать предварительно код. Если действительно есть необходимость исправить какой-то кусок кода или сделать рефакторинг для удобства (а не переписать всё нафиг) — заложить это в оценку, при этом, для начала, объяснив себе, зачем это будет нужно, а уж потом руководителю/тимлиду
— Не забывать про обратную совместимость никогда. Лучше пусть кусок кода будет считаться устаревшим и помечен как deprecated на дальнейшее использования, но будет продолжать работать на вас и зарабатывать вам $, чем вы однажды его выкорчуете и потом приложения обрушится ещё в паре десятков мест
Отличная статья. На собственном опыте заметил, что часто желание «все переписать» возникает тогда, когда программисты не могут понять терминологию (!) и общую логику предшественников. На мой взгляд, при создании очередной системы ее обязательно нужно сопровождать минимальной документацией. При этом документации должно быть достаточно лишь для понимания терминологии и общей логики, чтобы можно было быстро въехать, откуда растут ноги, и увидеть всю систему в целом, не погружаясь в детали. Документация должна содержать минимум «воды» и вообще текста в пользу графики (схемы, UML), чтобы время «вхождения в тему» было минимальным: взлянул и сразу все понял.
А детали реализации должны быть очевидны уже из кода. Тут важно придерживаться стандартов нейминга и «чистоты кода», чтобы читающий сразу понимал, что к чему.
Даже если делаешь систему «для себя» и «на один раз», составить ее общий план и не пренебрегать качественным неймингом очень полезно. Вообще, мне кажется, эти простые правила должны быть в крови, чтобы не копился технический долг.
К сожалению, приходится работать с кривыми системами, без документации и с кривым кодом. И вот тут важно четко понимать, с чем имеешь дело: с собственным непониманием логики, терминологии, общей архитектуры, с банальным отвращением к говнокоду, который просто не нравится, или с реальными проблемами в расширении системы. В последнем случае действительно дешевле бывает все переписать.
А детали реализации должны быть очевидны уже из кода. Тут важно придерживаться стандартов нейминга и «чистоты кода», чтобы читающий сразу понимал, что к чему.
Даже если делаешь систему «для себя» и «на один раз», составить ее общий план и не пренебрегать качественным неймингом очень полезно. Вообще, мне кажется, эти простые правила должны быть в крови, чтобы не копился технический долг.
К сожалению, приходится работать с кривыми системами, без документации и с кривым кодом. И вот тут важно четко понимать, с чем имеешь дело: с собственным непониманием логики, терминологии, общей архитектуры, с банальным отвращением к говнокоду, который просто не нравится, или с реальными проблемами в расширении системы. В последнем случае действительно дешевле бывает все переписать.
Да, и соглашусь с предыдущим комментом: иногда достаточно переписать лишь фрагмент системы. Решаться на переписывание сразу всего опасно: можно закопаться и уже не откопаться.
Полностью согласен. Подчеркивание значения терминологии — тоже очень важно.
Мое личное мнение в том что всегда должен быть компромисс между «вам шашечки или ехать?». Можно скатиться в постоянный рефакторинг и поиск идеала, а «воз и поныне там». Я наблюдал проект в разработку которого приходили совершенно новые группы разработчиков. Новая группа обьявляла что все написанное ранее — отстой, особенно код того кто ранее точно такое же говорил про код предшественников. А потом спустя время получалось как в анекдоте про три письма — вали на предшественника, вали на проблемы, пиши письма.
Мое личное мнение в том что всегда должен быть компромисс между «вам шашечки или ехать?». Можно скатиться в постоянный рефакторинг и поиск идеала, а «воз и поныне там». Я наблюдал проект в разработку которого приходили совершенно новые группы разработчиков. Новая группа обьявляла что все написанное ранее — отстой, особенно код того кто ранее точно такое же говорил про код предшественников. А потом спустя время получалось как в анекдоте про три письма — вали на предшественника, вали на проблемы, пиши письма.
Sign up to leave a comment.
Эффект второй системы