Хочу, чтобы красиво!

[dotzero]

У каждого свое понимание красоты, поэтому одни и тотже код можно переписывать бесконечно.

[Garrett]

Даже на асме? =)

[Aquahawk]

Даже на асме.

[anonimizer_me]

Как раз на асме его можно написать очень большим числом способов :)

[ckald]

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

Значит, чему-то учимся

[Wott]

Как-то односторонне получается у Вас. Я может быть повторю некоторые банальности для ПМа среднего-крупного проекта, но все же:

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

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

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

Порадовало про тесты. Их что типа нет совсем?

[nekoval]

Как-то односторонне получается у Вас.

Правильно. На самом деле я тоже люблю новые фичи и т.п.

Если все время тормозить инициативу, то падает мотивация, производительность и в конце концов люди либо «успокаиваются» либо уходят.

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

Порадовало про тесты. Их что типа нет совсем?

«Зависит от». Например, в legacy-системе, с которой я сейчас работаю, тесты покрывают от силы 5-7%. Опять же полностью покрытая тестами система это «идеальный мир».

[Atv]

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

[nekoval]

Для больших контор это вариант.

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

Времена, надо сказать, тогда были дикие — например, команда даже не пользовалась VCS, причем на попытки его таки внедрить отвечали «а зачем нам это»

[druzhkov]

Atv, хороший подход.
Дополню из своего фрилансерского опыта:
когда работаешь фрилансером, подобный подход (написание ТЗ и списка предложений) быстро остужает «фонтанирующих» идеями заказчиков. Есть такие, которые могут долго и красочно расписывать все прелести нововведений, и при попытке обсудить или оспорить их предложения быстро переводят разговор в другое русло, а потом незаметно опять возвращают в расписывание прелестей их идей. В-общем, замкнутый круг. Приходится останавливать разговор и требовать документально оформленный wishlist.

[TyVik]

Atv, спасибо, хорошая идея.
Я в большинстве ситуаций задаю себе вопрос — «А что мне, собственно, не нравится?». И пытаюсь ответить по существу. Если архитектура верная, то зачем всё переписывать? К тому же, прежде чем начинать, надо понять _как_ это сделать, что само по себе порой не шибко простая задача.

[amlet]

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

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

Ищите золотую середину :)

[nekoval]

Вопрос какой код и на что он влияет. В период кризиса все определяется простой математической формулой :)
Если ЦЕНА_РЕФАКТОРИНГА < ЦЕНА_ВНЕСЕНИЯ_ЗАПЛАТОК_В_БУДУЩЕМ, то рефакторинг оправдан. Однако главная трудность — как оценить оба этих компонента. Одни склонны преуменьшать первую, другие — недооценивать вторую.

[amlet]

В период кризиса все определяется простой математической формулой :)
Если ЦЕНА_РЕФАКТОРИНГА < ЦЕНА_ВНЕСЕНИЯ_ЗАПЛАТОК_В_БУДУЩЕМ, то рефакторинг оправдан.

Скажу даже больше — эта формула работает и без кризиса, но всё можно ещё добавить, что также стоит подумать над слечаем:

ЦЕНА_РЕФАКТОРИНГА_сейчас < ЦЕНА_РЕФАКТОРИНГА_в_будущем

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

А теперь несколько пространный ответ на ваш вопрос:

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

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

[nekoval]

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

[amlet]

Ну естественно к любой ситуации нужно подходить с учётом требований и особенностей этой конкретной ситуации, исходя из реалий сегодня и в перспективе :)