Склоняюсь к мысли, что повторное использование кода — вещь экономически трудно осуществимая.
Почему так считаю:
— компонент, который может использоваться повторно, проектируется более тщательно, а поэтому более дорогой;
— любой компонент решает конкретный класс задач при конкретных ограничениях. То есть повторное использование возможно только тогда, когда решаемая задача "хорошо подходит" для готового компонента. Часто специфика той или иной задачи не позволяет воспользоваться существующим решением. А поэтому невыгодно искать общие решения.
Возникает сомнение в пользе от кода как такового (то есть документация из него слабая). Кажется, что более разумно повторно использовать знания о способе решения задачи. Но тогда нужно переходить от открытого кода к открытой проектной документации (идея движения за открытую проектную документацию пренаделижит А.А. Шалыто — http://is.ifmo.ru/works/open_doc).
Как вы считаете, какие препятствия существуют для воплощения этой идеи в жизнь?
Здравствуйте, Alexey Zasimov, Вы писали:
AZ>Склоняюсь к мысли, что повторное использование кода — вещь экономически трудно осуществимая. AZ>Почему так считаю:
AZ> — компонент, который может использоваться повторно, проектируется более тщательно, а поэтому более дорогой;
AZ> — любой компонент решает конкретный класс задач при конкретных ограничениях. То есть повторное использование возможно только тогда, когда решаемая задача "хорошо подходит" для готового компонента. Часто специфика той или иной задачи не позволяет воспользоваться существующим решением. А поэтому невыгодно искать общие решения.
AZ>Возникает сомнение в пользе от кода как такового (то есть документация из него слабая). Кажется, что более разумно повторно использовать знания о способе решения задачи. Но тогда нужно переходить от открытого кода к открытой проектной документации (идея движения за открытую проектную документацию пренаделижит А.А. Шалыто — http://is.ifmo.ru/works/open_doc).
AZ>Как вы считаете, какие препятствия существуют для воплощения этой идеи в жизнь?
И тем не менее кто-то ГОДАМИ поддерживает одни и те же продукты (1С, Виндовс, и т.д.), вместо того, чтобы поступить так, как уже давно поступают с китайскими пылесосами и другими товарами во всем мире: поюзал годик-другой и выкинул.
Для нас [Thompson, Rob Pike, Robert Griesemer] это было просто исследование. Мы собрались вместе и решили, что ненавидим C++ [смех].
ИМХО неверна изначальная предпосылка, что компонент необходимо с самого начала создать подходящим сразу для нескольких приложений. В реальности так не бывает. Просто когда пишешь приложение Б 1.0 после А 1.0, то обнаруживаешь что часть А 1.0 можно использовать в Б 1.0. Когда пишешь А 2.0 используешь наработки для Б 1.0. Так компонент растёт от версии к версии, становится универсальнее.
Здравствуйте, adontz, Вы писали:
A>ИМХО неверна изначальная предпосылка, что компонент необходимо с самого начала создать подходящим сразу для нескольких приложений.
Я совершенно согласен, что с самого начала задумываться о создании компонента "на все случаи жизни" бессмысленно. Так как часто предметная область на этом этапе не изучена.
A>В реальности так не бывает. Просто когда пишешь приложение Б 1.0 после А 1.0, то обнаруживаешь что часть А 1.0 можно использовать в Б 1.0. Когда пишешь А 2.0 используешь наработки для Б 1.0. Так компонент растёт от версии к версии, становится универсальнее.
Я как раз и имею в виду такую ситуацию, когда какое-то решение может быть применено в разных областях. Но даже и в этом случае документация, с человеческим описанием этого решения, вряд ли кем-то создается. Максимум, это решение будет завернуто в какую-нибудь shared-библиотеку.
Я считаю, что это неправильно. Часто полезнее _описание_ решения, а не решение в виде кода.
Здравствуйте, Sorc17, Вы писали:
S>И тем не менее кто-то ГОДАМИ поддерживает одни и те же продукты (1С, Виндовс, и т.д.), вместо того, чтобы поступить так, как уже давно поступают с китайскими пылесосами и другими товарами во всем мире: поюзал годик-другой и выкинул.
Здравствуйте, adontz, Вы писали:
A>Детальное описание по стоимости как решение, а использовать нельзя.
Бывают случаи, когда и решение использовать нельзя, так как оно не совсем вписывается в текущую задачу. Но модифицировать это решение не получается, так как на руках только код. Приходится переписывать все заново, разбираясь в проблеме с нуля.
A>Разве кодирование — это самый трудоемкий этап создания программы?
Здравствуйте, Don Reba, Вы писали:
DR>Я записываю ход мыслей по разработке в текстовом файле. Из этих записей затем при надобности можно создать документацию для любого компонента.
Здравствуйте, Osaka, Вы писали:
AZ>>повторное использование кода — вещь экономически трудно осуществимая O>принцип DRY
А как принцип DRY помогает использовать код повторно?
Здравствуйте, Don Reba, Вы писали:
DR>Здравствуйте, Alexey Zasimov, Вы писали:
AZ>>А такая надобность когда-то возникала?
DR>Не возникала. Но привычка вести записи не раз спасала при поддержке кода над которым давно не работал.
Да, когда работаешь с собственным кодом — этого достаточно. Но когда сталкиваешься с новой задачей, очень хочется узнать, а какже её решали другие? Но кроме груды кода ничего найти не удается. А код — как я думаю — плохой помощник.
Re[5]: Разве кодирование это самый трудоемкий этап?
Здравствуйте, Alexey Zasimov, Вы писали:
A>> Идея и архитектура важны, но зачем заново платить за отладку? AZ>Разве кодирование это самый трудоемкий этап создания программы?
Реализация и отладка — самое дорогое (по деньгам). Паттерны и алгоритмы давно известны.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Alexey Zasimov, Вы писали:
A>>> Идея и архитектура важны, но зачем заново платить за отладку? AZ>>Разве кодирование это самый трудоемкий этап создания программы?
A>Реализация и отладка — самое дорогое (по деньгам).
А это собственное мнение, или есть какие-то оценки?
A>Паттерны и алгоритмы давно известны.
Паттерны и алгоритмы известны, а вот как их сочетать, чтобы достичь требуемого качества при разумных затратах — это, кажется, вопрос открытый.
Re[7]: Разве кодирование это самый трудоемкий этап?
Здравствуйте, Alexey Zasimov, Вы писали:
A>>Реализация и отладка — самое дорогое (по деньгам). AZ>А это собственное мнение, или есть какие-то оценки?
Средняя команда: один архитектор/тимлид, 5-6 программистов. Архитектор получает 4К, программисты 2К. Итого 4К в месяц на идеи и 10-12К на реализацию. Плюс тестеры, дизайнеры. Плюс гораздо меньшее участие архитектора при развитии продукта.
AZ>А как принцип DRY помогает использовать код повторно?
Объясняет зачем оно надо.
Хотя, возможно, этого не понять, не сорвав пару раз сроки из-за того что студентам было лень выяснять как повторно использовать код, и они написали вычисление скидки на счёт (алгоритм единый) в 10 местах 10 неповторимыми способами, которые при изменениях все надо менять/отлаживать/тестить синхронно все 10, и каждый из которых по-своему неповторимо глючит на каких-то непредсказуемых вариантах входных данных.
Re[8]: Разве кодирование это самый трудоемкий этап?
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Alexey Zasimov, Вы писали:
A>>>Реализация и отладка — самое дорогое (по деньгам). AZ>>А это собственное мнение, или есть какие-то оценки?
A>Средняя команда: один архитектор/тимлид, 5-6 программистов. Архитектор получает 4К, программисты 2К. Итого 4К в месяц на идеи и 10-12К на реализацию. Плюс тестеры, дизайнеры. Плюс гораздо меньшее участие архитектора при развитии продукта.
Разве программисты 100% времени код пишут? Без знания области, в которой их программа будет использоваться? Наверняка акту кодирования предшествует какое-то изучение реального мира. Вот на этапе изучения разве не возникает потребность узнать: "как решили поставленную задачу соседи"?
Мне кажется, что основная сложность в программировании — это понять структуру предметной области.
Здравствуйте, Osaka, Вы писали:
AZ>>А как принцип DRY помогает использовать код повторно? O>Объясняет зачем оно надо. O>Хотя, возможно, этого не понять, не сорвав пару раз сроки из-за того что студентам было лень выяснять как повторно использовать код, и они написали вычисление скидки на счёт (алгоритм единый) в 10 местах 10 неповторимыми способами, которые при изменениях все надо менять/отлаживать/тестить синхронно все 10, и каждый из которых по-своему неповторимо глючит на каких-то непредсказуемых вариантах входных данных.
Не хотелось бы касаться систем, которые пишут студенты Но коль пришлось…
Мне кажется здесь задача не решается применением метода DRY (или какого-то другого). Тут проблемы взаимодействия внутри команды. Ведь как я могу повторно использовать код, о существовании которого не знаю, или не понимаю, что он делает?
Но привычка вести записи не раз спасала при поддержке кода над которым давно не работал.
