Склоняюсь к мысли, что повторное использование кода — вещь экономически трудно осуществимая.
Почему так считаю:
— компонент, который может использоваться повторно, проектируется более тщательно, а поэтому более дорогой;
— любой компонент решает конкретный класс задач при конкретных ограничениях. То есть повторное использование возможно только тогда, когда решаемая задача "хорошо подходит" для готового компонента. Часто специфика той или иной задачи не позволяет воспользоваться существующим решением. А поэтому невыгодно искать общие решения.
Возникает сомнение в пользе от кода как такового (то есть документация из него слабая). Кажется, что более разумно повторно использовать знания о способе решения задачи. Но тогда нужно переходить от открытого кода к открытой проектной документации (идея движения за открытую проектную документацию пренаделижит А.А. Шалыто — 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 (или какого-то другого). Тут проблемы взаимодействия внутри команды. Ведь как я могу повторно использовать код, о существовании которого не знаю, или не понимаю, что он делает?
Re[9]: Разве кодирование это самый трудоемкий этап?
Здравствуйте, Alexey Zasimov, Вы писали:
AZ>Разве программисты 100% времени код пишут? Без знания области, в которой их программа будет использоваться?
Без знания всех тонкостей. Что-то они конечно знают, но не вникают, потому что всё равно не принимают решений. А кто принимает, тот конечно вникает.
AZ>Наверняка акту кодирования предшествует какое-то изучение реального мира. Вот на этапе изучения разве не возникает потребность узнать: "как решили поставленную задачу соседи"?
Это делают бизнес-аналитики. Одноразовая работа.
AZ>Мне кажется, что основная сложность в программировании — это понять структуру предметной области.
Здравствуйте, adontz, Вы писали:
AZ>Разве программисты 100% времени код пишут? Без знания области, в которой их программа будет использоваться?
A>Без знания всех тонкостей. Что-то они конечно знают, но не вникают, потому что всё равно не принимают решений. А кто принимает, тот конечно вникает.
Простите, о каких решениях идет речь? Разве не разработчик принимает решение о применении конкретных алгоритмов для решения конкретной задачи?
AZ>>Наверняка акту кодирования предшествует какое-то изучение реального мира. Вот на этапе изучения разве не возникает потребность узнать: "как решили поставленную задачу соседи"?
A>Это делают бизнес-аналитики. Одноразовая работа.
То есть бизнес-аналитики разрабатывают структуры данных и алгоритмы?
Re[11]: Разве кодирование это самый трудоемкий этап?
Здравствуйте, Alexey Zasimov, Вы писали:
A>>Без знания всех тонкостей. Что-то они конечно знают, но не вникают, потому что всё равно не принимают решений. А кто принимает, тот конечно вникает. AZ>Простите, о каких решениях идет речь? Разве не разработчик принимает решение о применении конкретных алгоритмов для решения конкретной задачи?
Какие алгоритмы? В бизнес-приложении редко когда бывает надо что-то больше сортировки. А паттерны навязывает архитектор.
A>>Это делают бизнес-аналитики. Одноразовая работа. AZ>То есть бизнес-аналитики разрабатывают структуры данных и алгоритмы?
AZ>Тут проблемы взаимодействия внутри команды.
Независимо от качества взаимодействия внутри команды, если одно и то же вычисление делается несколькими способами — это дополнительная работа по их поддержанию в синхронном состоянии (чтобы на одном входном наборе выдавали одинаковый выходной) и дополнительные глюки (расхождение отчётов у гендиректора), потому что полная синхронность недостижима. AZ>Ведь как я могу повторно использовать код, о существовании которого не знаю, или не понимаю, что он делает? :)
Предполагать, могла ли такая задача уже решаться, предпринимать усилия по выяснению.
Публиковать знания о проекте там где их можно найти поиском (форум, wiki).
Конечно, в краткосрочном периоде и для одного кодера выгоднее написать не разбираясь, и получить репутацию производительного работника за быстрое прощёлкивание галочек в трекере, но в масштабах большого проекта за такую "экономию" придётся платить многократно.
Здравствуйте, Alexey Zasimov, Вы писали:
AZ>Возникает сомнение в пользе от кода как такового (то есть документация из него слабая). Кажется, что более разумно повторно использовать знания о способе решения задачи. Но тогда нужно переходить от открытого кода к открытой проектной документации (идея движения за открытую проектную документацию пренаделижит А.А. Шалыто — http://is.ifmo.ru/works/open_doc).
AZ>Как вы считаете, какие препятствия существуют для воплощения этой идеи в жизнь?
Такое "счастье" будет, когда бизнесу придётся прогнуться.
Смотрите. Писали раньше код с реально нужными комментариями в соответствующих местах. Языки развивались, возрастали масштабы и сложность программных систем. Бизнес столкнулся с тем, что без полноценной документации к коду — уже совсем тяжко. Все больше и больше из программистов эту документацию выбивали. А тем лень/нет времени ещё ковыряться и в каких-то всяких "word"-ах, часто ещё одно и тоже описывать, что и так есть внутри кода. Да и ещё UML-ы всякие рисовать, с весьма сомнительной полезностью для программистов.
Додумались облегчить жизнь — автогенерация документации на основе комментариев. Doxygen, JavaDoc и пр. — реально дали эффект в отрасли, теперь такая документация, фактически, стандарт.
Системы всё усложняются, кода накапливается — нужно управлять историей кода, его версиями и т.д. — взрыв в отрасли вокруг систем контроля версий. Эффект имеется, и жизнь для смертных тоже облегчили, как минимум они смогли как-то решать возникшие проблемы.
Развитие масштабов в IT не прекращается и всё больше и больше есть потребность в проектной документации, в голову всё меньше и меньше влазит процентов информации от общего масштаба информационной системы. Сейчас отрасль внедряет всякие трэк-системы, wiki, форумы и пр. рядом с контролем версий, и всё больше и больше это связывается с кодом. Но взрыва нет, потому что пока нет реального практичного решения. Например, некоторые предпочитают юзать Fossil, если позволяют условия, это проще, чем мучаться с git-ом + trac/redmine с костылями для него + ещё возможно и отдельная вики, ибо те встроенные не устраивают и т.д.
Иными словами, когда отрасль дойдёт до критичной точки — бизнес прогнётся, и что-то для смертных родят, чтобы они выдавали эту документацию, ибо без неё уже дальше никак.
В каком виде это будет — это отдельная "философия". Имхо, для чего-нибудь эдакого есть рациональные зёрна в таких языках, как хаскель. Я не о "функциональности", а о его принципах в синтаксисе — гармоничный и удобный (но не всё), подход к "публичности" — всё экспортируемое описывается в начале модуля со всей документацией, дальше — работа над реализацией без лишней шелухи. При этом язык/платформа должна позволять работать/создавать и без наличия документации. Напр., в том же хаскеле не всё чисто. Вот ввели в проект функцию (очень условный пример):
sub_str: String -> Int -> Int -> String
в принципе, понятно, о чём речь, но документации ещё нет, надо как-то понять последовательность параметров: где количество символов, а где номер позиции. Такая бы декларация была бы понятнее:
sub_str: source String, count Int, pos Int -> String
Т.е. часто важно реализовать часть функционала в проекте, потом постепенно документация прилепится.
И главное: пока для программистов лучше кода ничего нет — ни прямое AST-моделирование, ни графические языки, и даже "грамотное или литературное" программирование не прижилось.
Здесь в соседней теме вспомнили о ДРАКОН-схемах — очень полезны, иногда они лучше, чем мутная писанина. Подобные схемы, wiki, форумы и пр. + пляски вокруг кода (компиляции, сборки, контроль версии и т.д.) — когда это всё будет гармонично взаимодействовать, и главное: будь по-проще — и народ потянется. Сейчас вполне можно стать пионером в этом направлении.
Здравствуйте, Alexey Zasimov, Вы писали:
AZ>Склоняюсь к мысли, что повторное использование кода — вещь экономически трудно осуществимая. AZ>Почему так считаю:
AZ> — компонент, который может использоваться повторно, проектируется более тщательно, а поэтому более дорогой;
AZ> — любой компонент решает конкретный класс задач при конкретных ограничениях. То есть повторное использование возможно только тогда, когда решаемая задача "хорошо подходит" для готового компонента. Часто специфика той или иной задачи не позволяет воспользоваться существующим решением. А поэтому невыгодно искать общие решения.
Если рассматривать "компонент" как нечто монолитное вроде черного ящика, то толку от него мало.
Обычно хорошие компоненты представляют из себя набор классов\интерфейсов, публичные члены документированы, а код внутри одного метода достаточно простой чтобы в нем разобраться.
Кроме того зачастую имеется возможность подсовывать свои реализации интерфейсов для того чтобы расширить функционал компонентов.
AZ>Возникает сомнение в пользе от кода как такового (то есть документация из него слабая). Кажется, что более разумно повторно использовать знания о способе решения задачи. Но тогда нужно переходить от открытого кода к открытой проектной документации (идея движения за открытую проектную документацию пренаделижит А.А. Шалыто — http://is.ifmo.ru/works/open_doc).
AZ>Как вы считаете, какие препятствия существуют для воплощения этой идеи в жизнь?
А кто писать эту документацию будет? По сути она дублирует усилия: нужно поддерживать в актуальном состоянии код и еще и документацию. Скорее всего это никто не будет делать.
Если же документация будет в коде, то можно на уровне билд-системы настроить правила, которые потребуют документирования публичных членов и никуда уже не денешься.
Здравствуйте, Osaka, Вы писали:
AZ>>повторное использование кода — вещь экономически трудно осуществимая O>принцип DRY
придирчиво читал тот документ
ровно до первой концептуальной ошибки:
KISS (Keep it simple, stupid!) (Не усложняй, тупица) – Простота (и избежание сложности) всегда должно быть ключевой целью. Простой код требует меньше времени чтобы его написать, имеет меньше ошибок, и его легче изменить.
простой код невероятно сложно писать!
зато потом читать, отлаживать и править легко.
Всё сказанное выше — личное мнение, если не указано обратное.
Ф>простой код невероятно сложно писать!
Если его сложно писать, почему о нём следует говорить как о простом? Не путаются ли здесь понятрия "простой" и, например, "короткий"?
Здравствуйте, Osaka, Вы писали:
Ф>>простой код невероятно сложно писать! O>Если его сложно писать, почему о нём следует говорить как о простом? Не путаются ли здесь понятрия "простой" и, например, "короткий"?
нет не путаются: "абы как" написать просто, сделать хорошо — надо ещё постараться,
вот только читая написанное "абы как" будешь плеваться, а при попытках изменить — задумаешься о полном переписывании.
пример абы-как: копипаста (возможно с небольшими правками)
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Alexey Zasimov, Вы писали:
AZ>Склоняюсь к мысли, что повторное использование кода — вещь экономически трудно осуществимая.
Зависит от прочих условий. Но в общем это утверждение ложно.
AZ>Почему так считаю: AZ> — компонент, который может использоваться повторно, проектируется более тщательно, а поэтому более дорогой;
Он может проектироваться другими людьми. Например, быть коммерческим или быть разработанным другим отделом (более опытными в задаче людьми).
AZ> — любой компонент решает конкретный класс задач при конкретных ограничениях. То есть повторное использование возможно только тогда, когда решаемая задача "хорошо подходит" для готового компонента. Часто специфика той или иной задачи не позволяет воспользоваться существующим решением. А поэтому невыгодно искать общие решения.
Компонентный подход, кстати, не является единственным средстовом повторного использования. Скажем кодогенераторы — это тоже повторное использование. Зачастую более мощное использование (более гибкое).
Потом, понятно, что не все и не для любой задачи можно использовать повторно. Но то что можно испнользовать повторно, нужно использовать повторно. Это резко сокращает время на разработку.
Почти уверен, что ты программируешь на языках вроде С/С++. В них повторное использование плохо поддерживается и от того у программиста складывается ощущение, что повторное использование не комильфо.
AZ>Возникает сомнение в пользе от кода как такового (то есть документация из него слабая). Кажется, что более разумно повторно использовать знания о способе решения задачи. Но тогда нужно переходить от открытого кода к открытой проектной документации (идея движения за открытую проектную документацию пренаделижит А.А. Шалыто — http://is.ifmo.ru/works/open_doc).
Связь с кодом и документацией не уловил. Знания несомненно нужно спользовать повторно. И лучший вариант когда эти знания превращены в повторно используемый код. Тогда их можно использовать даже не обладая этими знаниями лично, а всего лишь зная их интерфейс.
AZ>Как вы считаете, какие препятствия существуют для воплощения этой идеи в жизнь?
Отсутствие знаний. Но посыл этой темы ложен. Одно другому не мешает.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Alexey Zasimov, Вы писали:
AZ>Склоняюсь к мысли, что повторное использование кода — вещь экономически трудно осуществимая. AZ>Почему так считаю:
AZ> — компонент, который может использоваться повторно, проектируется более тщательно, а поэтому более дорогой;
— хороший исходный код подразумевает модульность. Не ради повторного использования и не из за тщательного проектирования, а для управления сложностью. Поэтому никакой надобности "проектировать более тщательно" нет.
AZ> — любой компонент решает конкретный класс задач при конкретных ограничениях. То есть повторное использование возможно только тогда, когда решаемая задача "хорошо подходит" для готового компонента. Часто специфика той или иной задачи не позволяет воспользоваться существующим решением. А поэтому невыгодно искать общие решения.
По обоим моментам:
— ограничения которые закладваються в код как правило делаються с запасом и существенно меньше, чем стоит в постановке задачи. Потому что задачам свойственно меняться и в перспективе программу тоже потребуеться менять.
В результате, часть кода можно спокойно перетаскивать между разными проектами. И это чертовски удобно. И к слову сказать — использование stl или boost'а формально и являеться "повторным использованием кода" пусть и не своего))
AZ>Возникает сомнение в пользе от кода как такового (то есть документация из него слабая). Кажется, что более разумно повторно использовать знания о способе решения задачи. Но тогда нужно переходить от открытого кода к открытой проектной документации (идея движения за открытую проектную документацию пренаделижит А.А. Шалыто — http://is.ifmo.ru/works/open_doc).
Простой пример, почему лично я склоняюсь к использованию кода, а не документации: в сети пару лет назад мелькало иследование, сколько процентов программистов смогло написать коректный код работы с бинарным деревом, зная его алгоритм. Мало. Не знаю уж насколько то иследование репрезентативно, но люди крайне не внимательны. И это убивает ценность документации о способе и повышает ценность документации о решении (а это сам код или псевдокод). Поэтому я полагаю лучшим рещением использовать повторно хорошо зарекомендовавщий себя код, а не пытаться каждый раз его переписать с блекджеком...
AZ>Как вы считаете, какие препятствия существуют для воплощения этой идеи в жизнь?
Припятствие только одно — это одна из крайностей. Где то будет эффективно, а где то нет.
Но привычка вести записи не раз спасала при поддержке кода над которым давно не работал.
