Вопросы вида "Когда будет сделано?"

← →
Игорь Шевченко © (2009-07-09 19:48) [40]

@!!ex © (09.07.09 19:25) [38]

повторное использование кода - это очень большой миф

← →
Anatoly Podgoretsky © (2009-07-09 19:53) [41]

> @!!ex (09.07.2009 19:25:38) [38]

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

← →
Claus (2009-07-09 20:00) [42]

Откровенно говоря, никак не ожидал такого нелепого вопроса от "голубого" Palladin ©.
Несколько раз в ветке упоминалось ТЗ, но ни разу понятие "Календарный план", который может (или обязан) меняться в соответствии с изменеием ТЗ.

Собственно, это и есть формальный ответ на вопрос поста.
:)

← →
test © (2009-07-09 20:11) [43]

Claus (09.07.09 20:00) [42]

Чтобы план соответствовал реальности, а не светлой мечте нужно:

1 Написать аналитику проекта
2 Написать ТРП
3 Написать ТЗ
4 Согласовать все это

Как то я такое сказал, пожелел очень меня спросили: -"Ты что в СССР работаешь? Счас мы напишем потом доведем до ума, главное счас быстро первую версию выкатить!"

"Путь камикадзе", "Смертельный марш" книга как раз про оценку времени на проект.

← →
Игорь Шевченко © (2009-07-09 20:13) [44]

test © (09.07.09 20:11) [43]

Ты это Кенту Беку посоветуй - вместе посмеемся над ответом

← →
Сергей М. © (2009-07-09 20:13) [45]

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

))

← →
@!!ex © (2009-07-09 20:21) [46]

> [40] Игорь Шевченко © (09.07.09 19:48)

У меня некоторые модули тянуться в течении 5 лет в десятке проектах, причем на разных языках.
Сейчас некоторые модули выделяю в DLL, чтобы проще с ними работать было.
Если для вас повторное использование кода - миф, это либо очень плохой код, который проще переписать, либо ваши задача ооочень разные, что в них нет пересекющихся моментов.

Простой пример:
В течении примерно полугода разрабатывался редактор мира. Это расстановка объектов, настройка ландшафта, освещения, поведения объектов и кучу куча всякого другого хлама.

Когда месяц назад возникла задача написать похожй редакторе для другого проекта, он был написан примерно за неделю.
Причем написан с НУЛЯ! Тоесть новый проект, новая архитектура, и модули и решения из первой разработки.
Reuse решает. :)

← →
oldman © (2009-07-09 20:22) [47]

> Сергей М. © (09.07.09 20:13) [45]
> Вот нахрен, спрашивается, маляру нужна такая стенка

Кушать-то хочется...

← →
test © (2009-07-09 20:26) [48]

Игорь Шевченко © (09.07.09 20:13) [44]
Или Ашманову, или Ашманову и Беку сразу чтобы стерео ржач был!

Только "Путь камикадзе" это книга для разработчика, как ему выжить, а не как выжать из себя все.

← →
oldman © (2009-07-09 20:29) [49]

> Игорь Шевченко © (09.07.09 19:48) [40]
> повторное использование кода - это очень большой миф

+1000000000000000000000000000000

← →
Игорь Шевченко © (2009-07-09 20:37) [50]

@!!ex © (09.07.09 20:21) [46]

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

А сколько времени VCL пользуется - так и вовсе 14 лет. MFC и того больше.
Но другое дело, что run-time library языка С используется практически с момента ее написания, run-time library Фортрана гарантировано дольше, а это было еще до момента разговоров о повторном использовании кода и даже до ООП, один из камней которого было объявлено то самое повторное использование.

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

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

Паттерны - те используются. Но код - крайне редко. Я имею в виду код для обработки бизнес-логики, а не накиданные на форму кнопки.

Вот так получалось за 27 лет занятий программированием - повторно используется только что-то очень примитивное. Но набор примитивов - он узок и реальные задачи с его помощью не решить, применяется, как клей, не более того. Можно сравнить с электроникой - есть универсальные микросхемы, с помощью их комбинаций можно решить практически любую задачу, но почему-то в промышленной электронике (из разных соображений, в первую очередь по потребляемой мощности и надежности), предпочитают использовать заказные БИС, то есть, те самые куски кода, которые надо писать, вместо того, чтобы сопрягать между собой наборы примитивов.

← →
Игорь Шевченко © (2009-07-09 20:39) [51]

test © (09.07.09 20:26) [48]

Читал несколько лет назад Йордана - больше всего меня поразила последняя страница, на которой цена была напечатана. На мой взгляд, несоразмерная набору откровений вида: "Лучше быть здоровым и богатым, чем бедным и больным".

← →
@!!ex © (2009-07-09 20:43) [52]

> [50] Игорь Шевченко © (09.07.09 20:37)

Это может говоритт только об ошибках в проектировании.
Лично у меня повторно используються(без изменений) куски кода до 1000 строк.
Очевидно если код делает какую то работу, и его можно отвязать от конкретики проекта - этот код можно использовать где угодно.

← →
Игорь Шевченко © (2009-07-09 20:49) [53]

@!!ex © (09.07.09 20:43) [52]

> Это может говоритт только об ошибках в проектировании.

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

Если это называется повторным использованием, то я против такого. Код должен быть простым и ясным, и любой алгоритм должен разрешаться минимальным количеством максимально понятных и очевидных операторов :)

← →
@!!ex © (2009-07-09 20:55) [54]

> [53] Игорь Шевченко © (09.07.09 20:49)

Значит я единственный кому повезло работать с технологиями, база которых не меняется с 1991 года...

← →
DVM © (2009-07-09 20:57) [55]

> и любой алгоритм должен разрешаться минимальным количеством
> максимально понятных и очевидных операторов :)

Жаль этого не знают авторы Indy я каждый раз как на нее смотрю ужасаюсь. Вроде бы такую простую вещь как сокеты превратили в такого монстра с тысячей классов, что просто жуть. И ведь исключительно из благих намерений.

← →
Palladin © (2009-07-09 20:58) [56]

> @!!ex © (09.07.09 20:55) [54]

:) угу, у маляра она тоже не меняется

← →
Palladin © (2009-07-09 21:03) [57]

> oldman © (09.07.09 20:29) [49]

это астрономическая циферь и в природе ее несуществует )

← →
Claus (2009-07-09 21:06) [58]

> @!!ex © (09.07.09 20:21) [46]
> Игорь Шевченко © (09.07.09 20:37) [50]
> Игорь Шевченко © (09.07.09 20:39) [51]
> @!!ex © (09.07.09 20:43) [52]
> Игорь Шевченко © (09.07.09 20:49) [53]
> @!!ex © (09.07.09 20:55) [54]

не вижу связи с постом:)

← →
@!!ex © (2009-07-09 21:10) [59]

> [56] Palladin © (09.07.09 20:58)

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

← →
Anatoly Podgoretsky © (2009-07-09 21:14) [60]

> DVM (09.07.2009 20:57:55) [55]

Цели у них были более чем нормальные, но к сожалению количество перерасло в качество.

← →
Игорь Шевченко © (2009-07-09 21:18) [61]

Есть только один путь к реальному повторному использованию кода - это путь OpenSource, когда код для повторного использования модифицируется при неучтенных частных случаях на момент изначального написания. Причем, модифицируется опытными программистами. Так работал Unix, сейчас Линукс и ряд больших OpenSource-проектов.

Все остальное - это чаще всего квадратные колеса, изобретенные армией программистов закрытого кода.

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

← →
@!!ex © (2009-07-09 21:25) [62]

> [61] Игорь Шевченко © (09.07.09 21:18)
> Либо используется в рамках одной организации, постоянно
> дописывающей один и и тот же продукт,

Это куда же его повторно использовать в рамках одного проекта?
Копи Паста чтоль? Ну нафиг такое счастье...

> [61] Игорь Шевченко © (09.07.09 21:18)
> одну и ту же предметную область

Ну это овчевидно. Вероятно мой код загрузки текстур не пригодится разработчикам Ворда...

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

← →
DVM © (2009-07-09 21:27) [63]

> Пожалуй единственное что нельзя повторно использовать -
> это формочки с кнопочками и их логикой.

Иногда и их можно.

← →
@!!ex © (2009-07-09 21:31) [64]

> [63] DVM © (09.07.09 21:27)

Иногда. Обычно диалоги. Но всетаки это редкость.

← →
Игорь Шевченко © (2009-07-09 21:46) [65]

> Это куда же его повторно использовать в рамках одного проекта?
>
> Копи Паста чтоль?

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

← →
@!!ex © (2009-07-09 21:48) [66]

> [65] Игорь Шевченко © (09.07.09 21:46)

Ну и что мешает использовать этот модуль в другой разработке, в которой нужен функционал этого модуля?

← →
Rouse_ © (2009-07-09 22:02) [67]

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

Ну все зависит от архитектуры, я например люблю строить проект из мааааааленьких абсолютно абстрагированных от задачи "кирпичиков" (модулей конечно получается много) и за последние пять лет работы порядка 40/45 процентов этих "кирпичиков" нашли применение в совершенно других проектах, не существовавших на момент первоначальной реализации (оговорюсь - проектов внутренних, хотя некоторые из этих юнитов, особо универсализированные, я, с разрешения руководства, иногда выкладываю к себе на сайт).
Что нам стоит дом построить? ;)

← →
Игорь Шевченко © (2009-07-09 22:06) [68]

@!!ex © (09.07.09 21:48) [66]

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

На примере того же Windows NT - первая (точнее, третья) версия сделана с использованием чистой теории раздельных подсистем, которые общаются посредством сообщений, каждая их не зависит от другой, может быть заменена, может быть повторно использована. Попробовали и решили - а ну его нафиг, сольем все в один огромный модуль, будет монстр (win32k.sys), но работать будет быстро. И действительно, работает быстро, но пустил побеги в те места, которые к нему раньше не относились, были обособленными и, опять же, потенциально могли повторно использоваться.

← →
El (2009-07-09 22:10) [69]

> Palladin © (09.07.09 17:12) Самый любимый вопрос от пользователей и начальства. Отвечаю "не знаю, когда сделаю". У нас всегда сроки невыполнимые ставят и на дню еще несколько программ прибавят, которые не оплачиваются никак, просто "надо". Начальство потом про программы находу забудет и опять пристает, почему программа не сделана еще. Хороший совет - ведите ежедневный отчет для себя о проделанной работе и показывайте начальству, когда пристает :))))

Rouse_ © (09.07.09 22:02) [67]

Я как бы тоже выкладываю, об чем писал уже в этой ветке. Я напомню - изначально шла речь о том, что повторное использование кода связано со скоростью разработки, то есть, к тематике дискуссия о повторном использовании имеет самое непосредственное отношение.
Разумеется, не имеет смысла каждый раз программировать интерфейс на WinAPI при наличии палитры компонентов, как стандартных, так и сторонних и собственных. Но это все (ни один из наборов компонентов) обычно не решает задач бизнеса, а скорость разработки - это все-таки решение тех самых задач. То есть, я не встречал наборов компонентов для прикладных областей, например, для расчетов смет по строительству ;)

> [70] Игорь Шевченко © (09.07.09 22:12)

Это лишь значит что в вашей области повторное использование сводиться к использования компонентов и базовых типов.
Но это не делает reuse мифом.

@!!ex © (09.07.09 22:49) [71]

Если бы только в нашей. Системный код - да, используется повторно, прикладной - крайне редко, обычно нет смысла писать прикладную программу с использованием предыдущих прикладных модулей, проще сделать движок, ядро, как угодно, и расширять его возможности под изменяющийся прикладной мир. Желательно предусмотреть внутренний язык любого рода, чтобы подстройкой под изменения занимался конечный пользователь, а не разработчик :) Такой подход, правда, свои ограничения накладывает.

> То есть, я не встречал наборов компонентов для прикладных
> областей, например, для расчетов смет по строительству ;)

Ну Игорь - ейбогу, перебарщиваешь :)
Понятное дело что для специфики и нужны программисты, но даже тут имею возможность тебя разочаровать, базовый внутренний набор компонент для сметной математики у нас не трогается, т.к. это те-же кирпичи аккумулиривонные под ту или иную методику регионального рассчета внешним движком :) Вот движок то конечно переписывается (нарасщивается).
А с аргументом "я не встречал наборов компонентов для прикладных областей" - все зависит от то-же прикладной области :) ГИС например ;)

> Palladin © (09.07.09 17:26) [6]
> Потому что маляр не встретит посередине стены глючную некрасящуюся
> поверхность. Тогда как в профессии программиста встречается
> много независящих от него обстоятельств и препятствий которые
> нужно преодолеть, и самое страшное он (программист) не может
> с уверностью сказать встретит он их или нет.
улыбнулся), как Вы далеки от малярных работ)).. А то что во время дождя гипсовые шпатлёвки сохнут в 1,5 раза дольше, доставка и расчёт материала, "пустотки" в плитах, вечно пьяные мастера и подрядчики, жадность самого заказчика, и ещё куча "мелочей", вроде ,случайно пробитых перфоратором пластиковых труб, неверно порезанный и посчитанный материал и т.п..
из баек, вспомнилось), как-то осталось у нас несколько металлических профилей, один товарищь сразу предложил выход, разрежем посередине (пополам), заказчику скажем - обрезки.:))
> Игорь Шевченко © (09.07.09 22:12) [70]
> То есть, я не встречал наборов компонентов для прикладных
> областей, например, для расчетов смет по строительству ;)
этим и занимаемся..).

Rouse_ © (09.07.09 23:37) [73]

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

А что, математика не меняется ?

> А с аргументом "я не встречал наборов компонентов для прикладных
> областей" - все зависит от то-же прикладной области :) ГИС
> например ;)

и что ГИС ?

> "Когда будет готово?"
>"Когда закончишь?"

Как раз сейчас аналогичными вопросами мучают... Эх, надо быстрее доделывать :)

Отвечаю "в процессе"

> А что, математика не меняется ?

Пи все еще 3.14 и только местами в штатах начинает равняться четырем. Правда наши кулькуляторы не предназначены на запад :)

> и что ГИС ?

Да вот собственно и все :) Есть пакет компонент для ГИС - это же самая, что ни на есть, прикладуха? :)

Тут совершенно напрасно катили бочку на маляра:
http://uk.wikipedia.org/wiki/%D0%9C%D0%B0%D0%BB%D1%8F%D1%80

Помните, Хому Брута из "Вия" называли маляром: "Знатный маляр был".
А ведь он в числе прочих иконописи учился.

> MsGuns © (09.07.09 23:52) [79]

не факт, что в то время слово "маляр" имело современный смысл. Если мне не изменяет память, то у каких-то славян "малевать" = "рисовать", то бишь как художник, а не валиком по стене.

Вопросы вида "Когда будет сделано?" Найти похожие ветки