Как мне сообщить (с доверием) своему боссу, что наше приложение представляет собой спагетти-код

В основном приложение представляет собой спагетти-код. Повсюду ужасные антипаттерны.

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

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

Как мне сообщить боссу, что код был плохим, и я делаю его хорошим

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

Изменить: согласно комментариям. Возможно, лучше не говорить «не соответствует передовой практике», поскольку передовая практика со временем меняется. Вместо этого вы можете просто сохранить преимущества, например: «Мне нужно реорганизовать часть кода, это поможет сделать код более читабельным, менее подверженным ошибкам и более простым в обслуживании». и т. д...

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

Зачем вносить изменения, которые не настолько важны, чтобы их заметили, это пустая трата времени!

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

Для чего вас наняли?

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

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

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

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

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

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

Ваша вторая задача — понять, почему вы проводите рефакторинг. Похоже, вы этого тоже не знаете, за исключением того, что «теоретически это плохо, а это теоретически лучше», и считаете, что никакой выгоды для пользователя нет. Это беспокоит. В идеале обработка большего количества ошибок помогла бы уменьшить количество ошибок и проблем, с которыми сталкиваются пользователи. Или внесение этих изменений упростит и ускорит добавление новых функций на несколько процентов. В конце концов, эти улучшения должны быть донесены до вашего босса таким образом. «Я могу сделать эти три новые вещи за месяц, или я могу провести этот рефакторинг в течение месяца, а потом эти три новые вещи займут всего неделю, а последующие тоже будут быстрее…»

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

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

Ответы flexi и mxyzplk — хорошие ситуационные ответы. Я хотел бы внести более буквальный ответ.

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

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

• они уже доверяют вам, потому что у них нет выбора.
• очень мало смысла в том, чтобы быть более подробным, чем «код был плохим, я делаю его хорошим».

Ключ в том, чтобы не злоупотреблять доверием, которое они (вынуждены) к вам уже иметь.

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

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

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

Мне нравятся ответы Флекси и Хелены , но это затрагивает очень тяжелый урок, который мне пришлось усвоить, оказавшись в ситуации ОП, которую другие ответы не вызывают.

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

Практический способ завоевать доверие — продемонстрировать постоянную способность оценивать задачи и давать оценки, близкие к этим. Дело не столько в личном доверии и интуиции, сколько в установлении модели общения и поведения, которые укрепляют уверенность в вашей способности работать.

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

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

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

• прежде чем приступать к капитальному ремонту, пусть даже маленькому, помните об этой диаграмме от xkcd: «Стоит ли это потраченного времени» . В этом случае время, которое вы пытаетесь сэкономить, — это время следующего разработчика или время, которое может потребоваться для выполнения следующего запроса.
  

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

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

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

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

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

• Сосредоточьтесь на процессе, который в первую очередь сокращает время выхода на рынок, но внедрение хорошего процесса запроса, оценки, реализации, проверки и развертывания новых изменений поможет установить стандарт для всей будущей работы.
• Рассмотрите возможность реализации стратегий DevOps, таких как CI/CD, а также уровень автоматизации тестирования. Вы хотите, чтобы вся ваша новая работа была надежной, если вы продвигаете новый процесс или парадигму, убедитесь, что ваша работа отражает то, как вы могли бы улучшить решение в целом.
  • Это не обязательно должно быть все включено , сосредоточьтесь на стратегиях экономии времени, которые делают вас более продуктивными изо дня в день.

Радикальный вариант — запросить выделение времени для работы над капитальным ремонтом, сделать это в отдельной ветке или как совершенно новое приложение, возможно, 1 день в неделю или каждые 2 недели. Со временем вы пытаетесь развивать этот побочный проект, пока он не достигнет функционального паритета с первым. Это часто представляет собой маркетинговый вариант для PO, в какой-то момент вы только добавляете новые функции в новое приложение и можете получать доход за счет продажи / распространения нового приложения, поскольку теперь вы создали четкое ценностное предложение.

Научитесь говорить на языке вашего босса

Чего хочет ваш босс?

• Увеличение прибыли
• Сокращение эксплуатационных расходов
• Уменьшите риск (обратите внимание, что во многих компаниях снижение операционных расходов важнее снижения рисков, потому что операционные расходы всегда видны в ваших квартальных отчетах, а риски лишь иногда превращаются в реальные инциденты)
• Предсказуемые результаты (новая функция готова, когда вы сказали, что она будет готова)
• Быстрые результаты (новая функция делается быстро)

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

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

Не делайте отдельные проекты качества кода. Каждый проект должен также удовлетворять потребности бизнеса, и таким образом, чтобы вы могли продемонстрировать его людям, ориентированным на бизнес. Если вы можете сказать: «Благодаря рефакторингу расчет заработной платы теперь занимает час, а не день», то бухгалтерия легко увидит ценность этого для бизнеса. Им все равно, что это потому, что вы убрали дурацкие конструкции петель.

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

Вы не знаете. Вместо этого измените свое повествование с «Код был полным дерьмом, и я делаю его в порядке» на «Код был в порядке, он дал то, что нужно, но я делаю его намного лучше, чем раньше». У такого подхода есть два преимущества: 1.) Ничего не делая по-другому, вы меняете восприятие от того, кто делает хороший код, к тому, кто делает еще лучший код.

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

Поскольку вы единственный технический специалист, обычно никого не интересуют какие-либо технические детали, метрики сложности, архитектура, покрытие тестами, CI/CD, для них это просто техническая болтовня. Вместо этого вы можете продвигать свою работу, сосредоточившись на результате с их точки зрения (см. также ответ ObscureOwl):

• Более быстрое развертывание и сокращение времени выхода на рынок
• Меньше открытых ошибок
• Меньше времени простоя сервера
• Больше новых функций быстрее
• Меньше повторяющихся проблем

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

• Если у вас есть доступный инструмент метрик кода, используйте его. Однажды мы использовали Sonar для Java-проекта, и не было ничего лучше, чем иметь четкую метрику для привлечения руководителя проекта.

• Определите рекомендации по кодированию, оцените изменения и расставьте приоритеты.

• Определение модульных тестов

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