Как убедить руководство очистить код после перехода

Ответ 1

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

Ответ 2

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

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

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

Ответ 3

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

Надеюсь, что это сработает для вас.

Ответ 4

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

Один из моих друзей однажды ожидал попасть в административную стенку в отношении очистки после производства, поэтому он установил несколько команд sleep() в приложении, чтобы заставить его работать медленно. При демонстрации его он постоянно убеждал руководство, что "это может быть улучшено с некоторой очисткой". Они с радостью рекомендовали очистку после производства в этот момент, потому что они могли ПОСМОТРЕТЬ необходимость.

Это немного обманчиво, но это сработало. В итоге приложение было чище, быстрее (очевидно) и хорошо написано.

Ответ 5

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

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

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

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

Нижняя строка заключается в том, что код не был чистым в версии 1, очистка может быть только частью выпуска 2. И если нет релиза 2, или у вас нет времени на его работу, вы можете также забыть об этом.

Ответ 6

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

Ответ 7

Скажем, вы делаете Test Driven Development, и поэтому ваш процесс разработки должен выглядеть примерно так:

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

Кроме того, в вашем случае вы переходите с шага 2 на шаг 5 (пропустите шаги 3 и 4) - и теперь вы хотите наказать управление за то, что вы делаете быструю и грязную работу. Фактически, вы собираетесь управлять и говорить: "Мы хотим переписать все приложение, которое клиент уже принял и оплатил, не добавляет новых функций, тратит много времени на разработку, за которое вам не платят, и потенциально ввести новые ошибки, чтобы мы могли сделать программы красивее, чтобы посмотреть на нас разработчиков". Никто не собирается идти на это.

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

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

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

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

Ответ 8

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

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

Ответ 9

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

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

Ответ 10

Вы можете попытаться утверждать, что после первоначального "go live" должно быть время обслуживания и поддержки, когда какие-либо производственные проблемы не были обнаружены до того, как будут исправлены и обработаны, и что это также время для подготовки к будущим улучшениям или ошибкам исправления. Если руководство может сказать и согласиться с тем, что "Мы больше не будем требовать каких-либо изменений, когда-либо", то я не думаю, что есть веская причина вернуться и очистить код, если не считать, что такое требование не очень хорошо perpituitiy или как доктор Хаус сказал бы: "Люди лгут".

Ответ 11

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