Проблемы с code reuse испытывают средние и большие программерские компании. Это 50 или больше программистов, не все друг друга знают в лицо и не все знают кто над каким кодом работает. Вы пишите проприетарный софт, как-то его документируете, однако раз за разом наступаете на одну и ту же проблему. Различные группы программистов постоянно пишут один и тот же код, дублируя тем самым работу друг друга. Ситуация может осложняться еще и тем, что у компании может быть несколько географически удаленных друг от друга девелоперских офисов. Как решать эту проблему? Я видела три подхода, все плохие.
1. А никак. Живем с дублированием кода. Иногда страдаем по этому поводу.
2. Периодически устраиваем встречи, делаем красивые презентации, кидаем обширные письма в общую рассылку. Желающие могут взять код соседнего отдела и начать с ним работать. Однако народ на встречи зачастую не приходит, рассылку читает наискосок. Кто-то начинает форкать чужой код и вот у нас уже куча вариантов одного и того же, но с разным набором багов.
Итог: Code reuse местами присутствует.
3. Жесткая модульная система. Подробное документирование. За каждым модулем закреплен ответственный. Возможно, есть отдельные люди, которые следят за тем, чтобы дублирования кода не было.
Казалось бы, вот оно! Однако в итоге получаем падение морали и резкое снижение производительности труда. Потому что у нас все команды становятся завязаны друг на друга и никто старается ничего не менять, чтобы не стать тем самым виноватым, который всё сломал.
Наименее плохим, пожалуй, является второй вариант, но хочется большего. Может вы знаете другие прекрасные способы решения этой проблемы? Или книжки какие правильные? Подскажите!
четверг, ноября 05, 2009
Code reuse
Подписаться на:
Комментарии к сообщению (Atom)
Atom feed
46 коммент.:
у нас смесь пунктов 2 и 3, точнее пока 2, но постепенно для базовых вещей вводится жесткое re-use кода - есть отдельный тим, который его сопровождает и т.п.
Поддерживать вики и внутренний поисковик для кода? Но это я так теоретизирую.
2insanegigolo:
Поддерживать вики и внутренний поисковик для кода? Но это я так теоретизирую.
Надо знать что искать. Зачастую вообще не знаешь чем там люди занимаются в далеком офисе на другом континенте.
Дублирование кода иногда необходимость, но это так частный случай.
На мой взгляд что самой главной причиной дублирования кода выступает отсутствие знаний, что можно что-то повторно заюзать. Спасает от этого как правило ревью теми, кто знает, т.е. п.3. В моем случае так происходило и обучение. И вторйо заюзать артефакт сложнее, чем написать заново.
Я не понимаю почему мораль падает и завязоннасти друг на друга в п.3.
Что наименьшее зло высокая связнасть или дублирование не понятно. Наверное, хорошо где-то по середине.
Утвердить стандартные библиотеки, ими пользоваться. Создавать свои для реюзанья целенаправленно, методом организованного хаоса. В остальном — писать, как хочется. Я думаю, что нужно у гугла спросить, как они это делают. Как-то подозрительно много полезных библиотек у них получилось.
bealex, увы, проект живет. Что-то добавляется, что-то удаляется. Один раз так сделать не получиться. Придется постоянно пересматривать библиотеки.
Еще мысль:
Дублирование не избежно возникнет. Поможет регулярный процес по рефакторингу, лишьбы клиент это понимал и оплатил эту работу.
2Sergey:
Я не понимаю почему мораль падает и завязоннасти друг на друга в п.3.
Модуль развивает одна команда. Пользуются они и три других. Кому-то нужны новые фичи, кому-то нужно, чтобы были починены баги. В итоге все друг с другом грызутся.
2bealex:
Утвердить стандартные библиотеки, ими пользоваться. Создавать свои для реюзанья целенаправленно, методом организованного хаоса.
Вот как только появляются утверждения и все такое прочее, процесс сильно замедляется. Эти модули они же как появляются... Программеры думают "О, удобная штука у нас получилась. Давайте обновим по ней документацию и дадим попользоваться еще кому-нибудь". Я не говорю про какие-то огромные модули, которые имеют стратегическое значение для компании. Я говорю, про большое количество сравнительно небольших приятных фич, которые хорошо бы заюзать нескольким командам. Невозможно их все утверждать.
Может стоит подсмотреть, как живет Open Source?
Позволить любому изменить твой код.
За овнером сохраняются обязанности по модерации и ревью. Тут надо додумать систему закрепления и передачи овнерства. Типа: овнер - это "максимальный" контрибутор за последние полгода.
Ввести плюшки за ликвидацию дублированного кода.
Тут нужно действовать аккуратно. Плюшки должны быть достаточно вкусными, чтобы быть стимулом к поиску и популяризации своего кода, но при этом чтобы не была выгодна фальсификация.
У нас для реюзабельного кода был выделен отдельный проект, commons. Народ закидывал туда разные куски кода которые можно чситать реюзабельными.
Если контора большая, то можно назначить ответственного за качество добавляемого туда кода.
Если код реюзабельный, но специфичный для какой-то части проэктов, то можно сделать отдельный commons, специально для них. Но тогда пусть сами договариваются как его менеджить.
Алена,
> Кому-то нужны новые фичи, кому-то
> нужно, чтобы были починены баги.
По-мойму это обыденный рабочий процесс. В таком и работаю. Опять, невижу причин грызтся. Скандалистов на ковер и вливание. Фичи и баги в порядке важности и приоритетности. А это устанавливает тот, кто платит.
В автономном режиме, повторно используемый код оформляю согласно концептам позаимствованным из STL. На межкомандном уровне, полагаю, библиотека с точной и лаконичной документацией, а также набором тестов вполне приемлема к рассмотрению. В специальной поддержке нет необходимости, все может измениться, поэтому лучше выпускать версии, согласно своим (коммандым) целям, таким образом каждая комманда будет концентрироваться на качестве выполняемой работы.
...никто старается ничего не менять, чтобы не стать тем самым виноватым, который всё сломал...
Верно подмечено. Что-то похожее сейчас наблюдается в нашей команде. Отчасти из-за того, что изначально код программы писали люди, которые уже не работают с нами.
Лучшим вариантом считаю второй. Только обязательно должен быть тот, за которым будет последнее решающее слово, иначе дискуссии превращаются в бесконечный спор, а у кода появляются форки.
-------
Форки чаще всего происходят либо из-за низкокачественного шаред-кода, который уже нельзя исправить потому что на него много завязано, либо из-за сильно навороченного шаред-монстра, с которым не так просто разобраться.
Самый правильный это 3. Но для его живучести все должны работать в одном, модульном и хорошо оттестированном поле. Куча библиотек с четко прописанными версиями и точечными зависимостями. Если билдовая это позволяет, тогда нет проблем. Не хочешь что-то сломать - не используй новую версию, сиди на старой. Это работает только при условии что есть тесты. Т.е. если мне захотелось переехать на новую версию компонента, я делаю маленький штрих в билдскрипте и запускаю тесты. Выпускаю новую версию компонента. Все кому нужно будут подцеплять мой новый релиз и делать тесты и релизить свои обновленные версии и так далее.
Но жизнь заставляет нас делать совсем по другому. Пока я еще не видел ни инструментов ни техник, которые бы помогали делать вышеописанное эфективно....
Третий + система тестов могут спасти, пока компоненты сравнительно компактные.
2й вариант, если к нему добавить элементы из третьего, вероятно будет интересным.
Ещё вариант. Для каждого нового проекта (функционала) становится обязательным пройти "осмотр" у "коммитета экспертов", который состоит из тех же разработчиков (или архитекторов) из разных команд - тогда скорее всего кто нибудь да скажет - "а мы уже такую штуку делали, вот смотрите!".
Если есть менеджер проекта,если он раздает задания каждому,и довольно конкретно,то code reuse будет еще на уровне менеджера,проблема когда каждый проект на разном языке тогда одно и то же пишется на разных языках,и code reuse уже не помогает
Если чужой код плохо инкапсулирует свое состояние, или вдруг нам понадобился один мелкий кусочек из середины чужого проекта, то все - никакие орг. методы не спасут.
Мы хотим заюзать банан, а с ним вытаскивается горилла, которая его держит, и все громадные джунгли, в которых она живет.
И как только показывается краешек джунглей, сразу же возникает желание взять и сделать все самому, с нуля и проще.
Вот так, как правило, и убивается code reuse.
Для полноценного реюзабельного кода нужна команда офигенных профессионалов, система юнит-тестов (актуальных!) и так далее. Мало кто из крупных команд такое потянет. А вот в мелких — запросто.
Мне тоже приходит в голову только сравнение с опен-сорс. Там это всё уже годами работает и довольно успешно.
Например, такой идеализированный вариант: иметь внутри корпоративный сервер для публикации библиотек и компонентов, по принципу sf.net, googlecode и т.п. Ввести систему рейтингов для компонентов: чем больше разного народа (добровольно) используют один и тот же компонент -- тем рейтинг его будет выше. За высокий рейтинг как-то награждать, переходящим вымпелом например. Использовать распределенную систему контроля версий, чтобы форки компонентов возвести в норму: кому-то надо срочно починить баг или добавить новую фичу -- делает это в своей ветке, публикует рядом с основным транком, делает запрос на включение в транк. А уж главный мейнтейнер компонента будет сам периодически разбираться с предлагаемыми нововведениями. Соответственно весь процесс должен быть максимально открытым: каждому компоненту сразу выдавать форум/списко рассылки, разрешать всем делать ревью нового кода, иметь открытую базу багов по каждому компоненту.
В итоге для компании придётся осознать тот факт, что поддержка всего этого хозяйства нужно выделять ресурсы, а мейнтейнерам популярных компонентов выделять специальное время сколько-ко там часов в неделю для поддержки и развития компонента: для ревью кода, починки багов, обновления документации, периодических релизов новых версий в виде полноценных tarball и релизных веток.
Например, я много лет работаю с bzr и launchpad.net. Там многие эти моменты решены очень удачно. Не хватает только wiki и системы рейтингов для проектов.
ИМХО:
Чтобы сделать новую функциональность или улучшить старую:
* ищем в документации (если есть способы - по комментариям к коду), не сделано ли это уже
* если уже есть переиспользуемый компонент, используем
* если нет - пишем свой
* если есть, но плохо переиспользуется, уведомляем тимлидера найденного компонента о старте работ по написанию переиспользуемого компонента и обмениваемся консультациями, выделяем людей, проводим рефакторинг существующего кода или пишем с чистого листа. Существующий код, если возможно, переводим на использование нового компонента.
Вики и поисковик тут очень пригодятся. Алена может не знать как называется нужный компонент, но нужная ей функциональность вполне может найтись по описанию, если она уже реализована и документирована.
Внесу свою лепту. Недавно я перешел из конторы с 20-ю программистами, в контору с 500-ю программистами, которые физически работают над одним б-о-о-о-льшим проектом.
И я сновоа убедился в одной простой мысли: чтобы был code reuse - программистам надо давать время на "посмотреть по сторонам", а не прессовать сроками. А чтобы некоторая свобода не переросла в пи***больсвто - надо брать на работу правильных людей. Резонный вопрос - что такое "правильный сотрудник". Правильный сотрудник - это фанат. Фанат свое некоторое дополнительное свободное время так или иначе потратит, чтобы подогнать хвосты по работе, а попутно может и попробовать что-то новое, или, например, покопаться в корпоративной wiki в поисках re-usable code (он никогда этого не будет делать, если он гоним сроками, а работать более 40-45 часов неделю, и тем более требовать этого - абсолютная утопия, ибо семья и личная жизнь должны иметь свое время). Поэтому методы тестирования для приема на работу, когда людей дрючат по узко специфическим знаниям по С++, алгоритмам и все - это верный путь принять на работу баклана, который никогда и в сторону от того, что делает, не посмотрит. Гораздо важнее узнать - есть ли у него блог/сайт/личный проект или что лучше - проекты, какие блоги/книги он читает, какие у него хобби, сколько и как он тратит время на хобби и т.д. Личный блог, особенно если он ведется приличное время, скажет о человеке лучше любого CV. Конечно, профессиональное тестировани никто не отменял и надо планку держать, но разносторонность человека - это ключ к его умению смотреть по сторонам и не бояться этого делать, даже когда это в каком-то частном случае немного замедлит основную работу. По совокупности -- все эти "микро" задержки окупятся качеством и наличием новых идей.
Вобщем моя позиция такова -- code re-use - это всего лишь одна из проблем, которые в основном являются социальными, нежели техническими. А чтобы их решить головы сотрудником должны быть "правильными". Бери на работу правильных людей, которых не надо дрючить и строить по мелочам. И code re-use придет сам собой.
Из интервью с Дональдом Кнутом:
I also must confess to a strong bias against the fashion for reusable code. To me, "re-editable code" is much, much better than an untouchable black box or toolkit. I could go on and on about this. If you’re totally convinced that reusable code is wonderful, I probably won’t be able to sway you anyway, but you’ll never convince me that reusable code isn’t mostly a menace.
http://www.informit.com/articles/article.aspx?p=1193856&rll=1
Хорошая тема :)
У нас микс 2 и 3. Раньше было много 3 - были команды, которые разрабатывали компоненты и поддерживали их.
Как ты и написала - это вызывает проблемы с моралью, а также батлнэки - когда 1 человек поддерживает очень большую или глючную базовую компоненту - он просто не справляется и всех тормозит.
Так что начали использовать больше 2, когда каждый может залезить куда угодно и сделать что угодно.
Соответственно сразу полезли проблемы с качеством и реюзом - проще свое написать, чем искать и разбираться в чужом.
Процесс идет дальше и в след. году опять частично вернемся к 3, но примерно в том стиле, про который Александр в предпредыдущем комменте написал - базовые компоненты будут фрики-фанаты поддерживать и разрабатывать :)
Посмотрим, что из этого получится.
1. Анализаторы дубликатов
2. Instant code reviews
2Александр:
Поэтому методы тестирования для приема на работу, когда людей дрючат по узко специфическим знаниям по С++, алгоритмам и все - это верный путь принять на работу баклана, который никогда и в сторону от того, что делает, не посмотрит.
Золотые слова. Однако в сторону от этого никто не думает и весь найм происходит именно таким способом. Интересно почему....
2bishop:
Процесс идет дальше и в след. году опять частично вернемся к 3, но примерно в том стиле, про который Александр в предпредыдущем комменте написал - базовые компоненты будут фрики-фанаты поддерживать и разрабатывать :)
Посмотрим, что из этого получится.
Расскажи тогда :-)
2dan:
1. Анализаторы дубликатов
Это хорошо, чтобы copy-paste ловить, не более того.
Чего-то я себя ущербным почувствовал, аж отвечать стыдно ;) Все такие правильные 2, 3; 3,2...
Твой подход #2 сработает если инициатива идёт снизу (давайте я щас расскажу) а не сверху (вашему вниманию предлагается презентация).
В IT конторах нашей страны управляющие традиционно получают несколько больше чем разработчики, поэтому куча людей хочет пролезть в манагеры, поэтому корпоративный bullshit воспринимается не столько как корпоративный bullshit но как карьеризм.
У нас конторка маленькая и преобладает 2 метод. По-поводу 3 метода, подтверждаю, на практике он неприменим в конторах в которых любят искать виноватых и давят по срокам. Заказчику ведь важно чтобы все работало, а не красота кода. И вышестоящий менеджмент не всегда понимает, что потратив время на функционально-бесполезное можно потом сэкономить кучу времени.
> В IT конторах нашей страны
Во всех? Или может даже в большинстве? Не слишком ли смелое заявление? :-)
> управляющие традиционно получают несколько больше чем разработчики
Управляющие чем? При управление людьми это наверное так, потому что там больше ответственности. Но если говорить о менеджерах на том же уровне, что и разработчики, то они управляют по большей части не людьми, а процессами. И вот здесь никакой явной связи между зарплатой менеджера проекта и программиста на этом проекте нет.
Гораздо больше на это влияют такие слабоопределённые вещи, как "погода на рынке труда".
Алекандр:
>Гораздо важнее узнать - есть ли
>у него блог/сайт/личный проект
>или что лучше - проекты,
Бывшие студенты автоматически за бортом? Кстати, в числе прочих, имею двух сотрудников: у одного есть личный проект, у другого - нет. Первый по сторонам никогда не смотрит, второй отлично реюзает код. Так что, никакой связи.
Вот ядро Linux - два или три "главных" через которых проходит весь код. Т.е. код не попадает в репозитарий без их обзора. И соответствующий репозитарий, который позволяет в данной системе сохранить первоначальное авторство кода. И плюс lkml где можно обсуждать код.
Сомневаюсь, что здесь есть какие-то универсальные рецепты. Во-первых, довольно редко сразу можно понять, что код можно будет использовать повторно (мало кто пишет алгоритмы сортировок или форматирование времени/даты снова и снова). Во-вторых, нужно свободное общение между разработчиками, чтобы один мог похвастаться тем, что сделал, а второй -- намотал это себе на ус. В-третьих, нужен свободный и простой доступ к чужому коду, а сам код должен быть очень качественными и задокументированным (уже проблема). В-четвертых, в компании должна быть инфраструктура для выделения повторно-используемого кода (ветка репозитория, bug-tracking, wiki) + руководство этим процессом + какие-то сотрудники, в обязанность которых входит сопровождение этого кода.
Имхо, все это довольно утопично. Но помочь могут некоторые организационные мероприятия и изменение культуры в коллективе разработчиков:
- нужно информирование о том, чем занимаются другие разработчики/команды (но очень лаконичное и ненавязчивое, иначе это будет игнорироваться);
- нужно приучить разработчиков спрашивать у колег "есть ли у кого готовый код для ..." до написания собственного кода;
- нужно вести каталог готовых reusable-компонентов (в виде wiki или doxygen-документации);
- нужно предоставлять разработчикам ресурсы для оформления, исправления и сопровождения reusable-кода.
И тут получается интересная штука -- в маленькой команде все это достигается легко. В большой команде все это превращается в бюрократию. В средних командах -- как повезет.
Ввести в штатное расписание должность "Эксперт по кодовой базе".
2 Александр
Нанимать людей исключительно болеющих людей за дело ответственных и серьезных это конечно подход, но с увеличением численности коллектива, обязательно просочиться одна паршивая овца которая испортит все стадо.
Ну и бить регулярно по рукам несознательным личностям.
> Соответственно сразу полезли
> проблемы с качеством и реюзом -
> проще свое написать,
> чем искать и разбираться в чужом.
Ну ну. Надо не только написать свое, но оттестировать, предусмотреть юзкейсы. Если написаны внятные юнит-тесты и устраивает функционал- то я взял бы чужой код. Если присутствуют все классы эквивалентности для аргументов, дубликат (другой способ обработки того же) расчета и контроль генерации ошибок- то не важно для чего- это в 2-3-4 раза больше работы на ровном месте!
Для примера- зададимся вопросом- откуда стартовал проект? Взяли CommandLine. Раньше достаточно было найти пробел- если есть пробел-то после пробела- это уже аргументы. Недавно запускал программу написанную для Win98. Она, естественно, не запускается, если папка не называется C:\aaa. Потом в командной строке стали появляться кавычки. Потом оказалось, что есть софт, который запускает exe-шник так: делает активную папку и стартует программа.exe. Т.е. если путь не полный- нужно складывать с активной папкой. Потом оказалось, что полный путь - это не только диск:\, но и \\сервер\шара. А временами и \\?\... Еще через полгода пожаловались, что неактивна дефолтная папка в диалоге выбора каталога. Оказалось, что то ли фар- то ли что делают активной папку и запускают ./программа.exe А ShBrowseForFolder или как его, строку "\.\" не переваривает. А завтра другой софт запустит то же самое как ..\..\папка\программа.exe. ... а при выборе каталога или файла активный путь меняется- т.е. нужно запоминать активный путь на момент старта программы- потом будет поздно. Вот так. 5 лет назад я начал писать эту функцию- этим летом закончил. И то не факт, что это окончательная точка.
Так что "свое написать"- это либо убить время на дублирование чужого качества, либо вредительство :-).
А поскольку "проще свое писать"- это обычное настроение для студента, то новый код- это почти гарантированные дыры при работе с ресурсами-памятью, buffer overruns и т.д., игнор кодов возврата/исключений и т.д. причем просто потому, что не сидел ты пару дней- не разбирался почему что-то падает. Наверняка, лишнее в плюсах исползование new/delete/CreateFile/CloseHandle и прочего.
Собственно еще один аспект- а может, напишите преобразование Фурье или сингулярное разложение?
Пока команда сидит в одной комнате - наилучшиий из известных мне методов code reuse заключается в вопле: "а у нас есть готовая функция для XXX?" (и отвечает тот, кто лучше разбирается в XXX).
В больших командах будет хуже...
Меня всегда удивляло, что разных продуктах Adobe идентичный функции зачастую так по разному реализованы. Не просто лучше-хуже, а с применением разных идеологий. Теперь я понимаю, почему.
dtjurev: Почему у студентов не может быть блогов и проектов? как раз у них они и должны быть. И у всех правил есть приятные и не очень исключения.
Alexander Falei: А вот чтобы такого не было, планка при приеме на работу не должна опускаться при увеличении размера компании. Для многих не секрет, что известная компания на букву Г предпочитает отсеить десяток отличных кандидатов чтобы случайно не пропустить одного баклана. Жестко, но как мы все видим - это приносит им плоды ;-).
2Александр:
Для многих не секрет, что известная компания на букву Г предпочитает отсеить десяток отличных кандидатов чтобы случайно не пропустить одного баклана. Жестко, но как мы все видим - это приносит им плоды ;-).
Такой подход может работать в Гугле и в других компаниях с очень хорошей репутацией. Если вы нанимаете людей в безвестный стартап, нельзя действовать также. Потому что нет бесконечного пула желающих у вас работать.
Согласен, но именно при стартапе очень важно стартовать с правильными людьми. Благо при на старте их не надо иметь много.
на LinkedIn набрел на дискуссию Writing software that's built to last и там очень понравился комментарий Herve Bronnimann о дизайне С++ кода в Bloomberg. Мне бы самому захотелось to reuse такой код.
на LinkedIn набрел на дискуссию Writing software that's built to last и там очень понравился комментарий Herve Bronnimann о дизайне С++ кода в Bloomberg. Мне бы самому захотелось to reuse такой код.
А можно, если не сложно, скопировать? (для тех, кто там не зарегистрирован)
не знаю как насчет кидать все сюда в комментарий, но в тумблр я его себе утащил, так что если в linkedin кто не зарегистрирован, то можно прочесть здесь
Так как работаю в Блубмерге, могу однозначно подтвердить сказанное про организацию кода. Прикладываются титанические усилия для убирания каких-либо циклических зависимостей.
При таком объеме кода и количества программистов возникает другая проблема: допустим мне нужная какая-то бизнес функциональность (я не говорю про базовые низкоуровненые вещи -- тут просто есть coding standard). Мне порой ничего не остается, как просто искать банально контекстным поиском по вики и по самой кодовой базе в надежде найти знакомые слова. При большой кодовой базе, конечно, документирование, написание примеров, презентаций и т.д. всегда отстает от самого кода. Поэтому очень часто любое изыскание начинается с вопроса в командном чате -- "кто-нибудь знает лично людей, отвечающих за функционалам ХХХ? надо бы перетереть один вопрос..." и т.д.
Чтобы облегчить ситуацию очень серьезно практикуется так называемый code ownership. Это значит, что с большой вероятностью все вопросы по коду, которые писал ты на любом проекте в Блумберге, придется отвечать тебе (включая багфиксы), даже есть ты над этим уже не работаешь. Это стимулирует людей выдать больше документации и сделать все ясно и понятно, чтобы уменьшить поток вопросов.
Разделение проекта на 2 логические части. Одна четко документируется, и реюзается, походу проекта - развивается, но опять-же, с жестким документированием и уведомлением всех. Для этого выделяется отдельная команда, которая только этим и занимается. Во второй допускается дублирование кода, но с условием что активно используется первая часть - этого намного меньше.
А мне вот кажется, чисто теоретически, что для повторного использования кода нужно: 1) Догадаться, что то, что ты делаешь, возможно, уже кто-то мог написать. 2) Найти этот код. 3) Договориться с его авторами о 3а) правах 3б) внесении изменений.
С первым - это вопрос опыта и кругозора. ( Помню, когда-то впервые открыл для себя boost, почувствовал себя великим велосипедостроителем. )
Второе - вопрос чисто технический, а потому решаемый.
3а - вопрос юриста.
3б - вот тут надо подумать. Предположим, что Петров выпил пива и сочинил себе библиотеку для сортировки картинок JPEG по содержимому. А Сидорову нужна такая же, но для PNG, вдобавок, ему работать с JPEG религия не позволяет. Но это ещё цветочки. Иванову и всему его отделу тоже понадобилась эта библиотека, с поддержкой обоих форматов + ещё какая-нибудь фишка, которую невозможно вынести в отдеьный модуль, а надо вписать в код обоих форматов. Вопрос: кому её вписывать, кому потом это всё поддерживать, и как быть тем, кому функция от Иванова не нужна?
Поэтому, мне кажется, что повторное использование кода в не связанных тесно (одним офисом) группах возможно только в пределах некой стандартной библиотеки, с чётко определёнными фуекциями. Всё, что выше этих функций, каждый определяет себе сам.
Можно, конечно, ещё составлять код очень выской модульности, вынося каждый чих в отдельный класс, но на многих языках за это придётся заплатить производительностью, и иногда - крупно.
Отправить комментарий