Не надо по-хорошему, и так работает

[petr]

А можно пример с унитазом немного по другому повернуть?

Например мы делали решения для какого-то клиента. Оно получилось не очень красивым (или очень некрасивым), зато работает. Это аналогия с приведенным в примере унитазом.

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

[glibs]

Цитата:

Сообщение от petr

...И как... мы должны поступить?...

Вопрос философский. Я пока пришел к такому мнению. Оптимизировать затраты клиента (в этом и вижу свою задачу как консультанта). Но при этом закладываться на развитие системы. Получается всяко разно. Универсальные механизмы не делаю по возможности. Дорого, если их доводить до ума. В архитектуре и коде стараюсь придерживаться ВР. Не брезгую таким подходом — сделать что-то в виде прототипа с малой частью функциональности, временное, чтобы понять как нужно на самом деле, куда двигаться. Т.е. возможно даже в некоторых случаях сделать нечто, что потом гарантированной выкинется и напишется снова, чтобы получить некий опыт или поэкпериментировать. Последний подход нередко экономит много денег заказчику. Часто многие безумные хотелки отпадают или забываются, а если идея вообще абсурдна, то заказчик приходит к пониманию этого малой кровью. А если их сразу проектировать в дизайне, то отбрыкаться от них на этом этапе тяжело. Но чтобы так делать нужно хорошо уметь воображать себе во что может вылиться финальное решение и знать систему, чтобы не пойти изначально не тем путем.

[gl00mie]

Цитата:

Сообщение от petr

И как мы ... должны поступить?

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

Цитата:

Сообщение от glibs

Оптимизировать затраты клиента (в этом и вижу свою задачу как консультанта).
[...]
Но чтобы так делать нужно хорошо уметь воображать себе во что может вылиться финальное решение и знать систему, чтобы не пойти изначально не тем путем.

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