Универсализация или прагматичность?

← →
olookin © (2004-10-17 19:32) [0]

Лучше потратить месяц на универсализацию работы программного продукта или день на выполнение конкретной функции для конкретной задачи конкретного пользователя?

← →
Cobalt © (2004-10-17 19:36) [1]

Если новые задачи пользователей - не реже каждой недели - лучше первое.

P.S. Лучше расширять, чем переписывать.

← →
wnew © (2004-10-17 19:39) [2]

olookin © (17.10.04 19:32)
Здесь ответ: http://delphimaster.net/view/1-1097254844/

← →
olookin © (2004-10-17 19:41) [3]

[2] wnew © (17.10.04 19:39)
Здесь ответ: http://delphimaster.net/view/1-1097254844/

Спасибо, это я уже сделал давно. Я несколько о другом. Жаль объяснить непросто - слишком конкретная задача...

← →
wnew © (2004-10-17 19:45) [4]

olookin © (17.10.04 19:41) [3]
Я же не об интерпретаторе, а о том, что говорит Юрий Зотов - "Теория".

← →
olookin © (2004-10-17 19:47) [5]

[4] wnew © (17.10.04 19:45)

Теория очень полезна, тем более если коллеги плодят свои форматы как кроликов.... Да....

← →
olookin © (2004-10-17 19:51) [6]

[1] Cobalt © (17.10.04 19:36)
Лучше расширять, чем переписывать.

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

← →
Nous Mellon © (2004-10-17 20:09) [7]

Вот занятная статься на эту и не только темы:

http://www.ashmanov.com/pap/ashrul.phtml

Правило 5. Программист испытывает страсть к обобщению.

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

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

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

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

← →
YurikGL © (2004-10-17 20:19) [8]

> Правило 5. Программист испытывает страсть к обобщению.

Что верно, то верно...

← →
Юрий Зотов © (2004-10-21 03:17) [9]

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

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

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

← →
iZEN © (2004-10-21 04:50) [10]

"Разовые" работы
отвращают сердце,
колечат разум
и убивают душу.

← →
iZEN © (2004-10-21 04:55) [11]

Удалено модератором

← →
iZEN © (2004-10-21 04:56) [12]

Прошу прощуения, что "пропустил" ненормативную лексику.

[11] iZEN © (21.10.04 04:55)

Автор статьи бредит ИМХО.
Все зависит от конкретного случая. Мнение автора можно перефразировать так:
зачем выносить метод в отдельный класс, если можно в 15 несвязанных иерархией классов добавить один и тот же метод. Зачем добавлять метод, если можно добавить класс, и у всех методов первым параметром будет класс, с которым нужно совершить данную операцию.
Или по строительному: зачем ставить телевизор, если можно построить новый этаж; зачем наследовать монитор от телевизора, если можно сделать его независимым и потом писать 2 одинаковые методички для их ремонта.

Стараюсь писать максимально универсально, насколько позволяет время и задача.

Сложный вопрос. Ответ на который лежит в одной из 2-х плоскостей:
- Ремесло - решается, в основном админ.методами
- Искусство - не решается в принципе.
В реале где-то посередине. В зависимости от задачи, времени и денег ;)

Ответ имхо лежит в плоскости
а на сколько задача будет востребована в
будущем и на сколько можно обойтись вместо
реализации возможностями API и компонентами третих
произодителей. Ну и время собсно

Универсализация или прагматичность? Найти похожие ветки