Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Потрепаться";
Текущий архив: 2004.11.07;
Скачать: [xml.tar.bz2];

Вниз

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

 
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]

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


 
Sandman25 ©   (2004-10-21 09:31) [13]

[11] iZEN ©   (21.10.04 04:55)

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


 
Сергей Суровцев ©   (2004-10-21 10:15) [14]

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


 
Игорь Шевченко ©   (2004-10-21 10:31) [15]

iZEN ©   (21.10.04 04:56) [12]

Если не затруднит, то же самое, нормальным языком.


 
msguns ©   (2004-10-21 10:44) [16]

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


 
080D:07BBh ©   (2004-10-21 13:20) [17]

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



Страницы: 1 вся ветка

Форум: "Потрепаться";
Текущий архив: 2004.11.07;
Скачать: [xml.tar.bz2];

Наверх




Память: 0.49 MB
Время: 0.036 c
1-1098360544
Koala
2004-10-21 16:09
2004.11.07
Вызов формы из dll


1-1098353405
digger
2004-10-21 14:10
2004.11.07
Описание объектной модели Object Pascal


4-1096476106
xman
2004-09-29 20:41
2004.11.07
Какой процесс запущен?


14-1098426785
gn
2004-10-22 10:33
2004.11.07
Модификация автомата Калашникова:


14-1098182123
Lingo
2004-10-19 14:35
2004.11.07
MSDN Download





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский