Как доказать, что приложение построено на плохой базе кода?

В настоящее время я рассматриваю систему, созданную некоторыми разработчиками, которые ранее работали на моей работе. Система работает довольно хорошо с точки зрения пользователя, но при углубленном рассмотрении кода это полный беспорядок. Я более чем убежден, что способ создания приложения не выдержит будущих обновлений, не говоря уже о значительном увеличении использования.

Проблема в том, что я знаю, насколько это плохо, а мои начальники - нет. Как я могу доказать это своему менеджеру, чтобы он действительно увидел проблему и мог быть убежден в том, чтобы выполнить минимальную сортировку на текущей кодовой базе и в ближайшем будущем начать новую линию разработки для следующей версии приложения?

«Но это работает сейчас» - это стандартная реакция руководства на законные разочарования разработчиков программного обеспечения. Первое, что я хотел бы сделать, - это скомпилировать документацию (если есть) и использовать ее для демонстрации противоречий между кодом и документацией.

Если можете, соберите комплексный набор модульных тестов. Запускайте их при каждом изменении, чтобы вы могли задокументировать регрессии, которые можно обвинить в существующей кодовой базе.

Наконец, если вы можете привлечь разработчика из другого отдела, работе которого вы доверяете, взгляните на код вторую пару. Один разработчик, говорящий «это дерьмо», легче отмахнуться, чем когда старший разработчик, который уже некоторое время ручается за него, говорит: «Нет, Джим, он прав. Это дерьмо на взломщике.

Конечно, все зависит от вашей среды, размера компании и т. Д.

Я всегда рекомендую взглянуть на прагматичного программиста, если вы еще не читали его. Мало того, что это должно быть обязательным чтением для каждого специалиста по программному обеспечению, но у него есть несколько хороших советов по работе с руководством, коллегами, пользователями и т. Д., Которые не рассматривают разработку программного обеспечения как ремесло.

С точки зрения руководства, в системе нет ничего плохого, и вы просто жалуетесь, потому что [вы просто хотите переписать ее / вы не понимаете, что делали предыдущие инженеры / вы хотите, чтобы ваша работа была легкой]. Немного соломенный человек, но когда кто-то наверху видит, что сейчас все работает нормально, он не склонен видеть кризис, когда вы это делаете (я уверен, что где-то там есть аллегория об изменении климата ...) ,

В какой-то степени они имеют смысл. Руководство видит проблемы, когда выпуски выходят далеко за рамки их первоначальных оценок, оценки кажутся слишком высокими для выполняемой работы, «это невозможно с нашей существующей кодовой базой», и большое количество ошибок проскальзывает мимо QA. Если что-то мурлыкает хорошо, легко похлопать вас по голове и сказать, что вы делаете все возможное, потому что это не влияет на результат.

Что делать, зависит от вашей организации и самого программного обеспечения. Тем не менее, в принципе, я предлагаю документировать все сложности, возникающие в результате плохого устаревшего кода. Оценивая задачи, объясните руководству, почему, по вашему мнению, это займет много времени, с подробными объяснениями того, какие аспекты старой кодовой базы добавляют эту дополнительную стоимость. Когда ошибки вводятся в код, укажите причины, по которым эта ошибка была допущена, и то, как ответственны за проблемы в старой кодовой базе.

Я бы предложил выразить ваши опасения заинтересованным сторонам таким образом, чтобы можно было предположить, что программное обеспечение переросло свой первоначальный дизайн и в настоящее время проблематично продолжать его совершенствование.

Существуют различные инструменты, которые могут выполнять покрытие кода и проверку кода. Инструменты Google, подходящие для вашей технологии, обычно это инструменты промышленного стандарта. Я бы посоветовал вам использовать эти инструменты, подготовить отчет о качестве кода и представить его менеджеру. Убедитесь, что ваша критика носит конструктивный и неполитический характер.

Выберите пример, который легко понять, где руководство считает, что это простой запрос на изменение, но из-за существующего дизайна это намного сложнее.

Вы не хотите, чтобы они останавливались на конкретном запросе, но обязательно дайте им знать, что это будет ЛЮБОЙ запрос на изменение. Никто не хочет быть нарисованным в углу с заявлением. Разработчики верят в YAGNI, но руководство верит в CYA.

Предложения по нагрузочному тестированию могут быть хорошим подходом, но они не могут быть уверены в том, что возросшие проблемы использования соответствуют какому-либо реальному потенциалу роста (Компания не собирается удваиваться в течение одного года.).

Все относительно. Возможно, они не захотят вкладывать ресурсы в этот проект, если у них есть планы на более важные проекты, на которые можно потратить ваше время. Не отмечайте, что вы не видите общую картину.

Когда вы говорите о доказательстве чего-либо, все эти научные методические материалы вступают в игру, и часть того, что это означает, заключается в том, что если вы собираетесь принять объективные стандарты принятия решения, что является правдой, вы должны принять возможность того, что при расследовании эти досадные факты Оказывается, чтобы не быть на вашей стороне.

В вашем случае, я думаю, есть 2 вещи, которые нужно доказать.

Во-первых, текущая кодовая база является «плохой». Что вы, вероятно, можете доказать, так это то, что «профессиональное мнение почти всех разработчиков, изучающих этот код, состоит в том, что он плохой».

Во-вторых, компании лучше переписать кодовую базу. Это проблема, потому что даже если первая точка верна, вторая может не быть. Кроме того, вы не знаете достаточно, чтобы сделать это определение. Это работа руководства, и если вы хотите, чтобы они уважали ваше профессиональное суждение по первому пункту, вы должны уважать их по второму.

Но они не могут принять решение по второму вопросу без предоставленной вами информации. Вам нужно сообщить, что вы знаете о том, как проблемы в коде повлияют на бизнес, и что вы знаете о том, как переписывание повлияет на бизнес. Это сложно, так как оба предполагают предсказание будущего с большой неопределенностью.

Но вы можете попытаться сформулировать проблему с точки зрения бизнеса. Сколько дополнительного времени уходит на изменения и регрессии? Что будет стоить переписать? Как быстро будут расти расходы на текущую систему, если не будут переписаны? Что, если будет увеличение использования, какова вероятность катастрофы, если текущий код будет сохранен? Вы не можете ничего знать об этом, но вы можете дать лучшее предположение, чем кто-либо еще. Дайте диапазон, или что-то, чтобы сообщить, насколько точно вы можете предсказать эти вещи.

Большинство разработчиков не любят поддерживать паршивый код. Вот почему может быть прискорбно, что код, который легко переписать с точки зрения разработчика, может не стоить переписывать с точки зрения бизнеса.

Например, даже если перезапись окажется прибыльной, она может стоить меньше, чем альтернативная стоимость расходов денег в другом месте компании. Или плохая кодовая база может занять больше времени, чтобы измениться и иметь больше регрессий, но не настолько, чтобы сделать переписывание выгодным. Они могут рассчитывать на то, что их выкупят в ближайшие несколько месяцев, и, потратив деньги на переписывание, они появятся в книгах, а программное обеспечение с ошибками - нет.

Постарайтесь думать об этом с точки зрения бизнеса и не готовьте цифры, чтобы получить то, что вы хотите. Большое переписывание с деловой точки зрения почти никогда не бывает легким делом. Если вы хотите доказать что-то, чего нельзя доказать, постарайтесь опровергнуть это. Если вы продолжаете стараться изо всех сил придумать способ не переписывать с нуля, но ничего, что вы придумали, не имеет смысла, возможно, тогда действительно пришло время переписать с нуля. И эти усилия покажут вашему руководству, что вы серьезно относитесь к представлению интересов компании, а не своих собственных (вы представляете интересы компании, а не свои, верно?).

Думаю, это зависит от того, что плохо в коде базы. Быть «не так, как я бы делал» не означает, что это плохая кодовая база.

Вещи, которые на самом деле делают плохую кодовую базу:

• Дыры в безопасности

  Проблемы, которые делают Сервер, приложение и / или данные уязвимыми. Особенно все, что подвергает риску конфиденциальные данные компании, клиента или клиента. Это должно быть легко документировать.

• Работа сломана

  Это работает только потому, что вы массируете данные и почти постоянно выполняете обслуживание приложения, чтобы оно работало. Если бы вы ушли, и никто не воспользовался этим, он больше не работал бы. - Документируйте, сколько времени вы тратите на это. И обратите внимание, сколько вы могли бы сэкономить. Довольно часто эти процессы неэффективны и для пользователей, и вы можете также документировать это.

• На самом деле не работает

  Кажется, работает, но результаты неверны. Как правило, это вызывает проблемы в будущем, такие как несовпадение чисел, высокий уровень дефектов и т. Д.

Чем не плохая кодовая база (просто не хорошая):

• Написано на устаревших неподдерживаемых технологиях. (VB6, COBOL, .net1.1 и т. Д.)

Обратите внимание на преимущества перехода на новую технологию. Попытайтесь найти путь миграции, который перемещает части за раз, чтобы вы могли минимизировать риск и повысить доверие пользователей и руководства. Убедитесь, что логика работает в основном так же, как оригинал.

• Недокументированный / плохо отформатированный код

Это проще всего исправить, потому что обычно вы можете добавлять комментарии и корректировать форматирование, не влияя на код. Но это не требует переписывания. Если вы чувствуете, что это сочетается с другими проблемами, первое, что нужно сделать, это исправить это, чтобы вы могли лучше оценить жизнеспособность кода.

Вы ответили на свой вопрос в некотором роде.

Чтобы убедить их потратить деньги на систему, нужно подождать, пока она не будет работать нормально для пользователя. Если вы думаете, что он не будет масштабироваться, либо подождите, пока это произойдет, либо проведите нагрузочный тест, чтобы доказать это.

Тогда простое предложение очистки этой шкалы обойдется в X часов.

Это сложная ситуация, потому что с точки зрения пользователя все сейчас находится на приемлемой и стабильной точке. В первую очередь с нетехническими менеджерами в данный момент не о чем беспокоиться, но просьба переписать кодовую базу является огромным решением, и его не следует воспринимать легкомысленно, особенно в отношении мнения и усилий одного человека (себя). ,

Таким образом, вы находитесь в трудном положении, пытаясь обосновать необходимость переписывания, из-за огромного технического долга (по вашему мнению, у нас нет примеров и мы должны принять ваше слово), а также из-за того, что оказались в трудном положении. трудности с поддержанием и добавлением функций в эту систему.

Ваши оценки новых функций будут высокими, обоснуйте это большое количество фактами, доказав, что эти вещи действительно потребуют много времени. Если вы не передадите это должным образом, тогда ваш менеджер может просто предположить, что вы некомпетентны, и вы, конечно, этого не хотите. Когда он подвергает сомнению высокие оценки, объясните, почему вы чувствуете, что накопленный технический долг мешает быстро и дешево добавлять функции в текущее программное обеспечение. Если у вашего менеджера есть две мозговые клетки, чтобы он начал тереться, он начнет понимать это очень быстро.

Суть в том, что вы не должны пытаться убедить своего менеджера, а направить своего менеджера соответствующей (и тщательно отобранной) информацией, чтобы он / она могли убедить себя в том, что переписывание является приемлемым курсом. Вы должны заставить менеджера думать, что это была его / ее идея все время.

Сначала определите накопленный технический долг в вашей кодовой базе. Затем взгляните на этот вопрос и ответы , где объясняется, как убедить руководство погасить техническую задолженность, прежде чем продолжить.

Есть причина, по которой все зрелые программы выглядят как беспорядок:

1. Весь беспорядок кодирует критическую логику, на которую опирается бизнес. Без этого ничего не работает. Все это было необходимо для решения проблемы пользователя.
2. Он использует слегка устаревшую технологию. Современные программисты, похоже, считают, что если он не использует магию шаблонов, это просто беспорядок. Это неправильный взгляд. Любой, кто опаздывает в какой-либо более крупный проект, проходит этот этап, изучая все детали.
3. Требования, которые были критически важны некоторое время назад, уже не так критичны. Это потому, что программное обеспечение уже исправило эти проблемы. Опаздывая в проект, может показаться, что программное обеспечение является сложным без веской причины - проблема больше не существует, но сложность в коде все еще остается.