О приоритетах, их влиянии на разработку, и рефакторинге
G>>наличием приоритетов по срочности работ (что приводит к "грязным решениям")
I>перечитывал старую тему, с целью вырости над собой и увидел оставленную фразу. не сможете более подробно её прокомментировать? что имели в виду когда писали одновременно приоритетность срочности и грязные решения? заранее спасибо.
Пример из реальной жизни №1. Приходит дефект, приоритета 1, северити feature failure (полная неработоспособность фичи). До релиза - день. Разбирательство показывает, что год назад неправильно исправили другой дефект, который породил два новых. Они были найдены, и их закрыл другой человек, у него это почти получилось, но в одном неочевидном, однако - распространенном сценарии, случается задница.
По хорошему, надо все безобразие откатывать, и исправлять правильно. Однако, времени нет, и мы серьезно рискуем сорвать релиз. Собрали консилиум. Приняв во внимание все факторы, решили хирургически хачить поверх, и доказать корректность поведения формально. Операция заняла примерно 3 часа, два человека (я и Дима Осовский) "накладывали швы", внимательно следя, что учтены все побочные эффекты. Баг закрыли.
Пример номер два.
Делали одну штуковину, при ее дизайне упусти один юзкейс. Вспомнили о нем тогда, когда все было написано, и проверено, и пришло время его добавлять. Он был такой неудобный, при внешней безобидности, что пришлось бы все выбрость, и переписать - он менял весь дизайн радикально, и ничего "порефакторить" просто не получится.
Приняли решение делать "грязно". Сделали.
Через несколько месяцев, на последнем этапе тестирования (угроза срыва релиза), тестеры нашли маленький, но жутко неприятный дефект. Класса feature failure. Я заглянул в код, и понял, что наше "грязное решение" содержит ошибку - оно целиком полагалось на побочные эффекты, и мы кое-что пропустили. Я это быстро заткнул, и отправил исправление. На протяжении последующих двух недель ко мне пришло еще 4 подобных дефекта по этому же коду. Я понял, что надо было сразу переписать, и зарядил одному из программеров его переписывание. Однако, когда я затыкал его в пятый раз, и на код ревью корректность работы кода была доказана формально, я не стал чекинить новый "чистый" код, оставив старый. Новый код был отложен. Понятно почему?
Это важно, и требует пояснения. Этот модуль, который был "грязный", и из него перли баги, был очень хорошо изолирован от остального кода, и я не ожидал в нем никаких правок в ближайшие несколько лет с вероятностью 99,9%. Мы закрыли дефекты в нем с высокой вероятностью быстро, подняв "хрупкость" этого кода и цену внесения изменений в него до невообразимых высот. Но штука в том, что в него не будет внесено изменений в ближайшие несколько лет! А за очередную багу в этом релизе тестеры с дельмом съедят, они были в бешенстве.
Таким образом, принятые нами меры на каждом отдельном этапе были оправданы. Ну, а на тот невероятный случай, если вдруг в него будет вносится правка (типа риск), мы запланировали его рефакторинг, и в загашник был отложен новый код, который менее "хрупок" (типа mitigation plan). Вот так в реальной жизни и живем.
И не надо мне говорить, что надо предварительное проектирование лучше делать . Сам знаю . Это, во-первых, ошибки молодости, на которых я учился, во-вторых, именно о важности предварительного проектирования я и говорю во всей этой теме . Так что, можно считать это еще одним аргументом против agile в понимании XP и scrum.
***
А>Важно при этом также иметь вес и аргументы для того, чтобы в дальнейшем "пробивать" время не рефакторинг и тестирование "грязных" решений.
Видишь ли какая штука. По секрету говорю крамольную вещь - как бывший разработчик, а теперь как менеджер. Не надо иметь для этого ни веса, ни аргументов. Разработчик всегда имеет возможность сказать, что "время исправления дефекта займет много времени, он архитектурный". И все. Менеджер проверить не может никак. А вот как только ему дадут выбор - "могу быстро, могу медленно" - угадай результат.
Как менеджер говрю. Не надо ставить меня, менеджера, в положении выбора, когда у менеджера объективно недостаточно информации, чтобы принять решение. Это решение - уровня тимлида, только у него достаточно информации (еще один плюс к необходимости должности тимлида, которые полупрограммеры, полуменеджеры). Оно должно подниматься выше только при серьезных случаях. Обычно, в таких случаях уже поздно .
I>перечитывал старую тему, с целью вырости над собой и увидел оставленную фразу. не сможете более подробно её прокомментировать? что имели в виду когда писали одновременно приоритетность срочности и грязные решения? заранее спасибо.
Пример из реальной жизни №1. Приходит дефект, приоритета 1, северити feature failure (полная неработоспособность фичи). До релиза - день. Разбирательство показывает, что год назад неправильно исправили другой дефект, который породил два новых. Они были найдены, и их закрыл другой человек, у него это почти получилось, но в одном неочевидном, однако - распространенном сценарии, случается задница.
По хорошему, надо все безобразие откатывать, и исправлять правильно. Однако, времени нет, и мы серьезно рискуем сорвать релиз. Собрали консилиум. Приняв во внимание все факторы, решили хирургически хачить поверх, и доказать корректность поведения формально. Операция заняла примерно 3 часа, два человека (я и Дима Осовский) "накладывали швы", внимательно следя, что учтены все побочные эффекты. Баг закрыли.
Пример номер два.
Делали одну штуковину, при ее дизайне упусти один юзкейс. Вспомнили о нем тогда, когда все было написано, и проверено, и пришло время его добавлять. Он был такой неудобный, при внешней безобидности, что пришлось бы все выбрость, и переписать - он менял весь дизайн радикально, и ничего "порефакторить" просто не получится.
Приняли решение делать "грязно". Сделали.
Через несколько месяцев, на последнем этапе тестирования (угроза срыва релиза), тестеры нашли маленький, но жутко неприятный дефект. Класса feature failure. Я заглянул в код, и понял, что наше "грязное решение" содержит ошибку - оно целиком полагалось на побочные эффекты, и мы кое-что пропустили. Я это быстро заткнул, и отправил исправление. На протяжении последующих двух недель ко мне пришло еще 4 подобных дефекта по этому же коду. Я понял, что надо было сразу переписать, и зарядил одному из программеров его переписывание. Однако, когда я затыкал его в пятый раз, и на код ревью корректность работы кода была доказана формально, я не стал чекинить новый "чистый" код, оставив старый. Новый код был отложен. Понятно почему?
Это важно, и требует пояснения. Этот модуль, который был "грязный", и из него перли баги, был очень хорошо изолирован от остального кода, и я не ожидал в нем никаких правок в ближайшие несколько лет с вероятностью 99,9%. Мы закрыли дефекты в нем с высокой вероятностью быстро, подняв "хрупкость" этого кода и цену внесения изменений в него до невообразимых высот. Но штука в том, что в него не будет внесено изменений в ближайшие несколько лет! А за очередную багу в этом релизе тестеры с дельмом съедят, они были в бешенстве.
Таким образом, принятые нами меры на каждом отдельном этапе были оправданы. Ну, а на тот невероятный случай, если вдруг в него будет вносится правка (типа риск), мы запланировали его рефакторинг, и в загашник был отложен новый код, который менее "хрупок" (типа mitigation plan). Вот так в реальной жизни и живем.
И не надо мне говорить, что надо предварительное проектирование лучше делать . Сам знаю . Это, во-первых, ошибки молодости, на которых я учился, во-вторых, именно о важности предварительного проектирования я и говорю во всей этой теме . Так что, можно считать это еще одним аргументом против agile в понимании XP и scrum.
***
А>Важно при этом также иметь вес и аргументы для того, чтобы в дальнейшем "пробивать" время не рефакторинг и тестирование "грязных" решений.
Видишь ли какая штука. По секрету говорю крамольную вещь - как бывший разработчик, а теперь как менеджер. Не надо иметь для этого ни веса, ни аргументов. Разработчик всегда имеет возможность сказать, что "время исправления дефекта займет много времени, он архитектурный". И все. Менеджер проверить не может никак. А вот как только ему дадут выбор - "могу быстро, могу медленно" - угадай результат.
Как менеджер говрю. Не надо ставить меня, менеджера, в положении выбора, когда у менеджера объективно недостаточно информации, чтобы принять решение. Это решение - уровня тимлида, только у него достаточно информации (еще один плюс к необходимости должности тимлида, которые полупрограммеры, полуменеджеры). Оно должно подниматься выше только при серьезных случаях. Обычно, в таких случаях уже поздно .