Как вы оправдываете работу по рефакторингу перед вашим скупым на мелочи боссом?[закрыто]
https://stackoverflow.com/questions/77193
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Вы только что написали кучу кода, чтобы предоставить какую-то важную функцию под давлением.Вы срезали несколько углов, вы переделали некоторый код в несколько раздутых классов с именами вроде SerialIndirectionShutoffManager..
Ты скажешь своему боссу, что тебе понадобится неделя, чтобы привести все в порядок.
- Что убирать? - спросил я.
"Мой код - это свинарник!"
"Ты имеешь в виду, что нужно исправить еще какие-то ошибки?"
"Не совсем, это больше похоже на..."
"Ты собираешься заставить его работать быстрее?"
"Возможно, но это не так..."
- Тогда тебе следовало написать это как следует, когда у тебя была такая возможность.Теперь я рад, что ты здесь, да, я собираюсь пойти дальше и попросить тебя приехать на эти выходные.."
Я читал книгу Мэтина Фаулера, но я не уверен, что согласен с его советом по этому вопросу:
- Поощряйте регулярные проверки кода, чтобы работа по рефакторингу поощрялась как естественная часть процесса разработки.
- Только не говорите, что вы разработчик, и это часть вашей обязанности.
Оба эти метода избавляют от необходимости общаться с вашим менеджером.
Что вы говорите своему боссу?
Решение
Важно включить время рефакторинга в ваши первоначальные оценки.Идти к своему боссу после того, как вы доставили продукт, а затем говорить ему, что вы на самом деле еще не закончили, - значит лгать о том, что вы закончили.На самом деле вы не уложились в установленный срок.Это как хирург, делающий операцию, а потом не удостоверяющийся, что он вернул все на место так, как оно должно было быть.
Важно включить все этапы разработки (например,рефакторинг, исследование юзабилити, тестирование, контроль качества, ревизии) в ваших первоначальных расписаниях.В конечном счете, это проблема не столько руководства, сколько программиста.
Однако, если вы унаследовали беспорядок, вам придется объяснить боссу, что последняя группа программистов, спешивших запустить проект, срезала углы и что он хромает.Вы можете залепить проблему пластырем на некоторое время (как они, вероятно, и делали), но каждый пластырь просто откладывает проблему и в конечном итоге делает ее устранение намного более дорогостоящим.
Будьте честны со своим боссом и поймите, что проект не завершен, пока он не будет завершен.
Другие советы
Говорите на языке, который он может понять.
Рефакторинг - это выплата долга по дизайну.
Спросите своего босса, почему он оплачивает счет по кредитной карте компании каждый месяц, а не не оплачивает его до получения уведомления о взыскании.Скажите ему, что рефакторинг - это все равно что вносить ежемесячный платеж.
Просто сделайте это и включите в свой обычный процесс.Оцените время рефакторинга для начала нового изменения или для завершения изменения (в идеале).Я всегда выполняю рефакторинг, когда изначально изучаю новый код (методы извлечения и т.д.).
Ложь.Скажите ему, что это исследование новой технологии.Затем скажите ему, что вы решили, что затраты не оправдывают выгоды.Он подумает, что ты проделал отличную работу.
lol @ people down моддинг / пометка оскорбительная.
На самом деле, если это начальник, жадничающий на копейках, который не отличает хорошее программное обеспечение от дешевого, то то, чего он не знает, в конечном счете сделает его счастливее.если бы это был я, я бы ушел из компании и уехал куда-нибудь, где уважают способность своих разработчиков писать хороший код.Но опять же, именно поэтому я занимаю руководящий пост.
Скажите ему, что 80% затрат, связанных с программным проектом, приходится на фазу обслуживания жизненного цикла.Любой рефакторинг, проведенный сейчас для решения будущих проблем и приведения нескольких примеров, принесет существенную экономическую выгоду позже, когда возникнет необходимость в поддержании этого кода.
Это предполагает, что вы проводите рефакторинг по какой-то причине, а не из тщеславия программиста.
Рефакторингом вы должны заниматься постоянно....так что вам не нужно это оправдывать.
Очистка от больших проблем / редизайн может включать рефакторинг, чтобы взять его под контроль, однако это не "рефакторинг"
Рефакторинг должен занять считанные минуты ... или, если у вас нет поддержки инструментов, минуты.
В одной из недавних книг Роберта Гласса (мне нужно будет посмотреть ссылку) он упомянул исследование о стоимости хорошо поддерживаемого кода.Они обнаружили, что хорошо поддерживаемый код редактировался чаще, чем плохо поддерживаемый код.Это звучит нелогично, но когда они копнули глубже, то обнаружили причину:
Хорошо поддерживаемый код содержит больше функций, добавленных в него за тот же период времени, чем плохо поддерживаемый код.
Нравится ли вашему боссу функциональность?Конечно, они все так делают.Чем больше вы улучшаете удобство сопровождения кода, тем больше функций вы сможете реализовать при таком ограниченном бюджете.
Мне нравится ответ, данный в "Рефакторинге" Мартина Фаулера.Скажите своему боссу, что вы собираетесь разрабатывать программное обеспечение самым быстрым способом, который вы знаете.Бывает, что в большинстве случаев самый быстрый способ разработки программного обеспечения - это проводить рефакторинг по ходу работы.
Еще одна вещь, которую следует сказать своему боссу, - это то, что вы снижаете затраты на будущие улучшения.
Теперь у меня меньше денег на рефакторинг...
или больше денег позже, чтобы исправить все, что пойдет не так, и чтобы я провел рефакторинг.
Иногда просто пора устраиваться на новую работу.Есть определенные люди, которые просто хотят, чтобы вы "сделали это".Если вы когда-нибудь окажетесь в одной из таких ситуаций, и я был там, тогда просто уходите.
Но да, вся эта прочая чепуха о будущих расходах и тому подобном - хорошая идея.Я просто думаю, что большинство боссов лгут самим себе, потому что они хотят того, чего хотят, когда хотят этого, и они просто не способны предвидеть, что произойдет в будущем.
Так что, удачи тебе с твоим боссом.К счастью, он или она разумны.
Я думаю, вам следует просто начать работать над этим, не сообщая об этом своему боссу.Это действительно то, как я проделал свою лучшую работу.Я просто не говорю своему боссу, что я делаю, и потихоньку заменяю плохой / устаревший код, когда у меня есть время.
Это фактически спасало мою задницу не один раз.
Если ваш начальник не понимает необходимости рефакторинга или очистки кода, то вам следует задаться вопросом, достаточно ли у него инженерных знаний, чтобы быть инженером-менеджером.
Редко можно найти начальника, который выделит вам время на рефакторинг...просто делайте это по ходу дела.
На мой взгляд, самый простой вариант рефакторинга - это исправление чрезмерно сложного кода.Измерьте цикломатическую сложность Маккейба рассматриваемого исходного кода (Source Monitor - отличный инструмент для решения такой проблемы).Исходный код с высокой цикломатической сложностью имеет сильную корреляцию дефектов и плохих исправлений.Проще говоря, это означает, что сложный код сложнее исправить и с большей вероятностью будет содержать плохие исправления.Для менеджера это означает, что качество продукта, скорее всего, будет хуже, исправлять ошибки будет сложнее, а график выполнения проекта в конечном итоге ухудшится.Однако, устраняя сложность, вы повышаете прозрачность кода, снижаете вероятность непонятных / сложных ошибок и упрощаете его обслуживание (напримериз-за этого программист по техническому обслуживанию может иметь больший объем технического обслуживания).
Кроме того, вы можете доказать (если это не устаревший продукт в цикле обслуживания), что снижение сложности упрощает расширение приложения при добавлении новых требований к проекту.
Руководитель должен доверять разработчику в принятии правильных технических решений (в том числе о том, когда проводить рефакторинг).
Установите это доверие, или замените босса, или замените разработчика.
Еще одна хорошая аналогия - поддержание чистоты на строительной площадке.Единственная загвоздка здесь в том, что программист не представляет строителя, а менеджер не представляет прораба.Если бы это было так, его принцип "делай все правильно с первого раза" все еще был бы применим, поскольку компетентный и добросовестный строитель несет ответственность за поддержание хорошего порядка на своем рабочем месте во время работы.
На самом деле сам код представляет рабочих, а процессом разработки занимается бригадир.Беспорядок создается различными отраслями, занимающимися своими делами друг вокруг друга (т. е.взаимодействующими различными функциями кода, где каждая функция хорошо выполняет свою работу, но швы между ними неорганизованны) и устраняется бригадиром, который твердой рукой следит за тем, где возникает беспорядок, и действует, чтобы его устранить (т.Е.программный процесс, требующий рефакторинга).
Что я только что сделал недавно, так это объяснил своему коллеге по бизнесу, что процесс повторной сборки помогает быстрее разрабатывать новые функции и снижает вероятность появления новых ошибок, потому что код имеет лучший порядок и структуру, и даже возможно добиться некоторых улучшений скорости, потому что вы можете проверять код проще, чем раньше.
Когда бизнесмены поймут это, если они будут умны, они будут поощрять вас к постоянному обновлению производственного процесса.
Вы можете объяснить это с помощью строительной метафоры.Если вы не проведете рефакторинг, в итоге у вас получится дрянное здание с плохим ядром, так что у вас будут проблемы с трубами, окнами, дверями.
Не надо....просто иди и найди новую работу в месте, которое больше соответствует тебе.
