This leads us to the odd conclusion that strict control is something that matters a lot on relatively useless projects and much less on useful projects.
И вторая цитата:
For the past 40 years, for example, we’ve tortured ourselves over our inability to finish a software project on time and on budget. But as I hinted earlier, this never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business.
Как я это понимаю, ДеМарко больше за возможность переписать код (преобразовать), чем за его повторное использование (уложиться в бюджет).
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re: ДеМарко о компонентном программировании. Ну, почти.
Здравствуйте, thesz, Вы писали:
T>И вторая цитата:
For the past 40 years, for example, we’ve tortured ourselves over our inability to finish a software project on time and on budget. But as I hinted earlier, this never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business.
T>Как я это понимаю, ДеМарко больше за возможность переписать код (преобразовать), чем за его повторное использование (уложиться в бюджет).
Как я понял он хочет сказать: "Лучше не подковывать хромую кобылу, которая не в состоянии угнаться за изменениями в мире". Это и так очевидно, но никак не противоречит идиомам КОП.
Есть области, где КОП не применим (или не желателен), и также имеются области, где без него просто не обойтись (но здесь еще многое зависит от условий – бюджет/время).
Re[2]: ДеМарко о компонентном программировании. Ну, почти.
Здравствуйте, 4058, Вы писали:
4>Здравствуйте, thesz, Вы писали:
T>>И вторая цитата:
For the past 40 years, for example, we’ve tortured ourselves over our inability to finish a software project on time and on budget. But as I hinted earlier, this never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business.
T>>Как я это понимаю, ДеМарко больше за возможность переписать код (преобразовать), чем за его повторное использование (уложиться в бюджет). 4>Как я понял он хочет сказать: "Лучше не подковывать хромую кобылу, которая не в состоянии угнаться за изменениями в мире". Это и так очевидно, но никак не противоречит идиомам КОП.
ИДИОМА [от греческого idios — "собственный", "свойственный"] — лингвистический термин, обозначающий выражение (оборот речи), употребляющееся как некоторое целое, не подлежащее дальнейшему разложению и обычно не допускающее внутри себя перестановки своих частей.
Считаем + как Логическое И. Убери binary reuse, уже не КОП, и тп.
4>Есть области, где КОП не применим (или не желателен), и также имеются области, где без него просто не обойтись (но здесь еще многое зависит от условий – бюджет/время).
Это предложение я не совсем понял. Моё текущее понимание таково: есть области, где КОП не применим, а есть области, где без него не обойтись (да и в этих областях в зависимости от бюджета и времени может сложиться так, что он окажется всё равно неприменим).
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[3]: ДеМарко о компонентном программировании. Ну, почти.
Здравствуйте, thesz, Вы писали:
T>Здравствуйте, 4058, Вы писали:
4>>Здравствуйте, thesz, Вы писали:
T>>>И вторая цитата:
For the past 40 years, for example, we’ve tortured ourselves over our inability to finish a software project on time and on budget. But as I hinted earlier, this never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business.
T>>>Как я это понимаю, ДеМарко больше за возможность переписать код (преобразовать), чем за его повторное использование (уложиться в бюджет). 4>>Как я понял он хочет сказать: "Лучше не подковывать хромую кобылу, которая не в состоянии угнаться за изменениями в мире". Это и так очевидно, но никак не противоречит идиомам КОП.
T>
ИДИОМА [от греческого idios — "собственный", "свойственный"] — лингвистический термин, обозначающий выражение (оборот речи), употребляющееся как некоторое целое, не подлежащее дальнейшему разложению и обычно не допускающее внутри себя перестановки своих частей.
Чтот у тебя, Сергей, логика подхрамывает по-моему: 4058 говорил о идиомах КОП, ну и из-за того, что ты из списка идиом одну вычеркнешь, другие идиомами быть не перестают. Или есть некая иная трактовка?
Re: ДеМарко о компонентном программировании. Ну, почти.
Сами по себе они ими быть не перестают. Однако, во-первых, сами по себе они являются идиомами не только КОП и, во-вторых, описываемое урезанной суммой явление перестаёт быть КОП.
К>Или есть некая иная трактовка?
У меня вот такая.
С её высоты КОП представляется весьма узко применимым средством.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Re[2]: ДеМарко о компонентном программировании. Ну, почти.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, thesz, Вы писали:
T>>Software Engineering: An Idea Whose Time Has Come and Gone?
E>На мой взгляд, ДеМарко там вообще не говорит ни о повторном использовании кода, ни о компонентном программировании. Статья совсем о другом.
Если следовать букве, совершенно верно, ни повторно используемого кода, ни компонент.
Но высказанные идеи могут быть применены к повторно используемому коду и к компонентному программированию.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
E>>На мой взгляд, ДеМарко там вообще не говорит ни о повторном использовании кода, ни о компонентном программировании. Статья совсем о другом.
T>Если следовать букве, совершенно верно, ни повторно используемого кода, ни компонент.
T>Но высказанные идеи могут быть применены к повторно используемому коду и к компонентному программированию.
Как мне показалось, ДеМарко высказывает в своей статье всего две вещи:
1. Проповедуемая ранее идея о том, что программный проект должен контролироваться посредством метрик (т.е. "вы не можете проконтролировать то, что не можете измерить"), на его сегодняшний взгляд себя не оправдала.
2. А посему не нужно сосредотачиваться на жестком контроле и ставить во главу угла строки и бюджеты, поскольку очень важны проекты типа B (непредсказуемые, но способные принести очень высокую прибыль), а такой контроль плохо для них подходит.
Все это идеи из области управления проектами. Как их перенести в технологическую плоскость (т.е. повторное использование и КОП) я себе не представляю.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
