Удивительное количество проблем с качеством, масштабируемостью и нагрузкой возникло в приложении, которое я в настоящее время поддерживаю и которое я изначально не писал. К счастью, у меня есть новые проекты, которые я делал с нуля, чтобы сохранить некоторое подобие моего здравомыслия.
Первоначальная команда состояла из 20 разработчиков (большинство из них с устаревшими наборами навыков), без документов о требованиях к бизнесу или с тестерами по обеспечению качества, и с самого начала плохо управлялась водопадным способом. Первые дни производства были неловким кошмаром, который включал исправление хрупкого процедурного кода с еще более хрупкими исправлениями. Позже были добавлены функции, которые были забиты кувалдой в модель данных, которая никогда не предназначалась для их поддержки, и нередко можно увидеть, как один и тот же код дублируется 10 раз, и увидеть, как ресурсы не закрываются безопасным образом, и запросы ORM, которые выбирают десятки тысяч объектов, просто выбросить все, кроме горстки.
Теперь только я, и каждый раз, когда возникает новая проблема, я переписываю модуль в соответствии с более высокими стандартами и делаю его НАМНОГО более стабильным, но руководству необходимо надлежащее объяснение того, почему все это происходит.
Они кажутся шокированными и озадаченными тем, что это приложение некачественное и затягивает технические долги. К счастью, они понимают концепцию технического долга и поддерживают меня в моем стремлении искоренить его, и они очень меня поддерживают и благодарят, но мне кажется, что я просто продолжаю обвинять оригинальную команду (которая все оставила, чтобы разрушить другой проект в другом проекте). деление).
Суть в том, что я не хочу быть «тем парнем», который всегда жалуется на разработчиков проекта до него. Я видел такое отношение раньше от людей в моей карьере, которые лично я чувствовал, что они неосведомлены и не учитывают обстоятельства и влияние дизайна, которые побуждают вещи быть такими, какими они были.
Обычно я вижу такую позицию обвинения предыдущей команды в плохом дизайне и реализации со стороны идеалистических младших разработчиков, у которых не было жизненного опыта, который был у более старших членов и которые были им полезны.
Считаете ли вы, что есть лучший способ, возможно, более мягкий способ сообщения о таких проблемах руководству без ущерба для репутации человека / команды до вас?
источник
bad-codeпотому что код действительно вызывает ошибки и проблемы. Я назвал это,bad-programmerпотому что я боюсь, что я становлюсь единым целым, обвиняя предыдущую команду, усталое и штампованное оправдание, которое мы все слышали раньше. Что касается первых трех абзацев, возможно, мне не нужно было описывать это, но я хотел нарисовать точную картину моей непосредственной ситуации и рассказать историю того, что я собрал до сих пор.Ответы:
Технический долг похож на финансовый долг. Вы принимаете это (надеюсь) стратегически при разработке программы с намерением, что она будет окупаться в будущем. Иногда люди принимают плохие решения по техническому долгу (например, используют кредитную карту), но иногда определенная сумма технического долга является просто нормальной. Решение не тратить время на то, чтобы сделать что-то «правильным» сегодня с предположением, что это нужно будет изменить в будущем, является совершенно нормальным и должно быть ожидаемым. Конечно, есть тонкая грань, но если вы подумаете, что в первый раз все сделаете правильно, то это может вызвать ряд проблем (паралич анализа).
В итоге, любой нетривиальный проект, который длится более двух лет, должен посвятить какое-то время новому развитию, чтобы погасить техническую задолженность. Дело в том, что это правда, даже если вы правильно пишете свое заявление . Если вы этого не сделаете, вы накапливаете долги по долгу, и руководство, безусловно, может понять это, если вы представите это таким образом.
Объясните это руководству, и вместо того, чтобы постоянно «обвинять» предыдущую команду, вы можете представить это как «обычный бизнес».
источник
ИМО, вы уже в большинстве случаев делаете это правильно: вы не предлагаете переписывание, потому что «старый код отстой», но исправляете одну вещь за раз.
Чтобы не чувствовать, что вы обвиняете старую команду, просто представьте, что им, вероятно, пришлось создавать этот код под большим давлением времени. Руководство в то время, вероятно, не очень понимало это только потому, что код «более или менее работает» не означает, что любое обслуживание возможно без большой боли и переделок.
Цените старую команду за то, что удалось создать продукт, который действительно приносит некоторую ценность для бизнеса - он больше не будет использоваться, если не будет. Вы можете быть удивлены тем, как часто проект не приносит коммерческой ценности, даже если он прекрасно написан.
источник
Когда меня просят прокомментировать текущее состояние проблемного продукта, я всегда возвращаюсь к теме «это то, что есть», а затем начинаю говорить о планах по его улучшению.
Вы не знаете всех факторов, которые повлияли на решение, которое создало эту проблему - возможно, они были даже разумными в то время. Все, что вы можете сделать, это двигаться вперед и делать вещи завтра лучше. И звучит так, будто вы делаете хорошую работу - у вас правильное отношение к этой ситуации.
Сосредоточьтесь на том, чтобы просто сообщать факты, когда их спрашивают. Вам не нужно добавлять рассказ или комментарий; просто скажите «система отказывает в случае X» или «отчеты неверны для случая Y». Затем быстро добавьте, как вы планируете улучшить текущую ситуацию.
источник