Как Вы убеждаете своего менеджера, что для Вашего проекта нужен огромный рефакторинг? [закрытый]

A tricky one, i have recently worked in such a company... they were always pushing for new things, again they knew it was bad, but no matter how hard I pushed it - i even got external consultants in to verify my findings - they seen it as a waste of time.

Eventually they seen the light... it only took multiple server crashes and at one point almost a full 8 days of no website to convince them.

Even at that they insisted it 'must' be the hosting service.

The key is to try and quantify how long their site will last before it crunches, and get some external verification to back you up - 'they' always trust outsiders who know nothing about your app! Also, try - if you can - to give a plan that involves gradual replacement at worst, and a plan for how long it would take to do that way. Also a plan for if 1 or 2 bodies were working on a complete rewrite hwo long it might take - but be realistic too or it will bit you in the bum! If you go that route (which is what we done) you can still have some work on the existing site as long as you incorporate it into the new.

I've been in similar situation. There are basically only two options:

• You get some relaxed time and you may be granted time to refactor something
• Due to the bad code further development of some component comes to a stall. You can't proceed to add anything because every little change causes everything else to stop functioning. In this emergency case you will get a "go" with refactoring.

I have just answered in some other question, my horror story:

https://stackoverflow.com/questions/1333077/dirty-coding-tricks-to-deliver-project-on-time/1333095#1333095

I have worked on a project where dirty tricks were the main driving principle of the development. Needlees to say, after some time these tricks have started to conflict with each other. In one analytics component, we had to implement the other very dirty trick - to hide away those calculated values which due to the conflicting tricks were not calculated properly. Afterward, the second level tricks started to conflict and we had to create tricks to deal with those. Ever since, even the mentioning of this component makes me feel horror that I may have to work on it again.

It's exactly the second situation where refactoring is the only way out.

In general, many managers without a technical background (actually, those who come from bad programmers as well) neither care nor understand the value of quality code and good architecture. You can't make them listen until something interrupts their plans, like a blow of "non-implementable" features, increasing and reoccurring bugs, customer requests that cannot be satisfied and so on. Only then understanding of the code problems may come for the first time. Usually, it's too late by then.

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

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

Здесь всем не хватает точки:

Рефакторинг - это часть жизненного цикла разработки программного обеспечения.

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

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

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

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

If there is a need to refactor then the code will speak for itself. Minor refactoring can continue in during development. If you cant convince the manager then probably you should rethink if its necessary at all.

However if it is absolutely necessary then constructing metrics of development activities and the benefits should convince the manager.

I think one of options would be to highlight to the manager how re-factoring the code base now will save time (i.e. money) in the long-run. If the project is expecting to be running long term then making the changes now will clearly save you and other developers time in the future.

Best to use an example of a feature you've worked on estimating how long it would have taken if you had the cleaner code to work from in the first place. Good luck!

I am in same position right now, but with an agreement with the manager that, when the new feature should be implemented in some existing module to re-factor the module too (if it needs re-factoring), we are struggling now with the code created 4-5 years ago and definitely I find out that the re-factoring someone else s code is not trivial nor amusing to do, but very very helpful for the future re-use.

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

// ==UserScript==
// @name           My Script
// @namespace      http://www.google.com
// @description    My test script
// @include        http://www.google.se/*
// @include        http://www.dn.se/*
// @require        http://myserver/jquery-1.3.2.js
// ==/UserScript==

GM_log("Hello");

Это работает просто для меня, мое предположение, jQuery up на API Google не хватает некоторых функций. Потому что этот код выше, работает просто хорошо. Также обратите внимание на / * в конце каждого URL, пожалуйста, включите это.

Попробуйте другую jQuery и изменить URL-адреса, и он должен правильно в мире.

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

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

Убедитесь, что ваш менеджер зависит от других факторов, в том числе (но не ограниченных) их готовность быть убежденным, и ваша способность убедить.

В любом случае, что такое массивный рефакторинг в ROR? Даже если «основная архитектура просто неправомерна», - обычно она может быть немного выпрямлена за один раз. Убедитесь, что вы сломаете его в филиалы кусочков / пользы, чтобы вы ничего не нарушаете, пока вы заняты фиксацией.

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