На больших проектах часто начинают выделять "особо хороший код" в отдельную библиотеку, гордо именуюемую common.
Делают так многие, и все считают что это правильно. С одной стороны это хорошо, в одном месте правишь — хорошо всем. С другой стороны, когда начинается новый проект, слегка похожий на предидущий, в него начинают тулить комоны. А потом выясняется что проект совсем не похож на предидущий и комоны надо переписать так чтобы они удовлетворяли новым требованиям и начинается...
Короче, я так понимаю что я поднимаю риторический вопрос про добро и зло. Полюбому уже должно быть где-то умными дядьками это все описано. Ткните плиз а то никак не нагуглю.
02.02.09 21:34: Перенесено модератором из 'Управление проектами' — Хитрик Денис
Hexxx пишет:
> На больших проектах часто начинают выделять "особо хороший код" в > отдельную библиотеку, гордо именуюемую common.
ну или юзают соответствующий фреймворк
если же речь о часто используемых кусках типовой бизнес-логики — нужен
отдельный майнтейнер, который соберет из этого максимально оторванный от
конкретного проекта фреймворк с минимумом зависимостей.
> Делают так многие, и все считают что это правильно. С одной стороны это > хорошо, в одном месте правишь — хорошо всем. С другой стороны, когда
ага, знаем... в одном поправил — в 10 упало
> начинается новый проект, слегка похожий на предидущий, в него начинают > тулить комоны. А потом выясняется что проект совсем не похож на > предидущий и комоны надо переписать так чтобы они удовлетворяли новым > требованиям и начинается...
требования надо выяснять до разработки, а не после
ну и если уже выяснилось что какая-то библиотека/фреймворк не подходит —
надо ее ЗАМЕНИТЬ на нечто принципиально другое, а не править, порождая
1001 версию, каждая из которых непонятно чем отличается от остальных, а
патчить потом в случае чего придется все 1001...
Здравствуйте, Hexxx, Вы писали:
H>Ты не отвечаешь на мой ответ!(c)
H>Я тоже мог бы запостить примеры из личного опыта, но меня интересуют книжки, статьи, исследования.
А не будет такого Не модно щас писать свои фреймворки — ибо нецелевое расходование средств заказчика.
P.S. У нас тоже живёт своё сборище костылей — в трёх сборочках — *.Components (костыли к BCL v2), *.Components.Advanced (костыли к FW 3 и выше) и *.Core — ядро клиента без гуя — ибо достаточно универсально чтобы ползать из проекта в проект. Почему-то никто ничего не ломает. Всем жить хоцца наверное.
P.P.S. Такой сборник рецептов — очень полезное дело. Особенно когда выходят новые разъяснения от гуру кодинг-стайла, типа обещания поменять дефолтное поведение у string.StartsWith и т.п. А ты такой весь щасливый, потому что давно пользуешься хелперами, в которых все параметры заданы явно...
Hexxx пишет:
> Я тоже мог бы запостить примеры из личного опыта, но меня интересуют > книжки, статьи, исследования.
в книжках много пишут про code reuse, дескать это штука полезная и
рекомендуемая, в чем я с ними полностью согласен. Только вот "адаптация
коммонов под новый проект" уже может реюзом и не являться, со всеми
вытекающими.
Здравствуйте, Hexxx, Вы писали:
H>На больших проектах часто начинают выделять "особо хороший код" в отдельную библиотеку, гордо именуюемую common. H>Делают так многие, и все считают что это правильно. С одной стороны это хорошо, в одном месте правишь — хорошо всем. С другой стороны, когда начинается новый проект, слегка похожий на предидущий, в него начинают тулить комоны. А потом выясняется что проект совсем не похож на предидущий и комоны надо переписать так чтобы они удовлетворяли новым требованиям и начинается...
H>Короче, я так понимаю что я поднимаю риторический вопрос про добро и зло. Полюбому уже должно быть где-то умными дядьками это все описано. Ткните плиз а то никак не нагуглю.
Здравствуйте, noetic, Вы писали:
H>>Короче, я так понимаю что я поднимаю риторический вопрос про добро и зло. Полюбому уже должно быть где-то умными дядьками это все описано. Ткните плиз а то никак не нагуглю.
N>Может помочь тема Software Factories. Есть даже книжка на русском.
Ну, вряд ли найдется книжка с заголовком "Pro and Cons of Commons". А тут как бы задача шире выглядит: делаем бизнес так, чтобы не писать все с нуля, а собирать из готовых компонентов, сгруппировав весь разрабатываемый софт по "линейкам". А reusable components разместив в commons
Здравствуйте, Роман Дубров, Вы писали:
РД>ну или юзают соответствующий фреймворк РД>если же речь о часто используемых кусках типовой бизнес-логики — нужен РД>отдельный майнтейнер, который соберет из этого максимально оторванный от РД>конкретного проекта фреймворк с минимумом зависимостей.
РД>ага, знаем... в одном поправил — в 10 упало
РД>требования надо выяснять до разработки, а не после РД>ну и если уже выяснилось что какая-то библиотека/фреймворк не подходит — РД>надо ее ЗАМЕНИТЬ на нечто принципиально другое, а не править, порождая РД>1001 версию, каждая из которых непонятно чем отличается от остальных, а РД>патчить потом в случае чего придется все 1001...
Роман вы в своей пламенной речи, заменили "особо хороший код" на бизнес-логику, и после этой замены свели все к абсурду.
А речь у топикстартера как раз велась не о бизнес-логике, а об общем универсальном функционале для всех проектов.
Так что ваши параллели аля: «поменялись требования, все переписываем» суда не вписываются.
Из своего опыта скажу, в одном из проектов, где я сейчас работаю, такой Common вообще в отдельный репозиторий выделен.
В это репозитории помимо Common classes аля Period, ArrayUtils etc, лежат несколько общих фреймворков (Report, Workflow etc)
И могу вам точно сказать, то заиспользовать данный Common в другом проекте будет самое настоящее удавольствие.
Здравствуйте, noetic, Вы писали:
H>>Короче, я так понимаю что я поднимаю риторический вопрос про добро и зло. Полюбому уже должно быть где-то умными дядьками это все описано. Ткните плиз а то никак не нагуглю.
N>Может помочь тема Software Factories. Есть даже книжка на русском.
Не поможет. Software Factories начинают приносить отдачу при очень-очень больших проектах, во всех других случаях это выброс денег на ветер.
Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, noetic, Вы писали:
H>>>Короче, я так понимаю что я поднимаю риторический вопрос про добро и зло. Полюбому уже должно быть где-то умными дядьками это все описано. Ткните плиз а то никак не нагуглю.
N>>Может помочь тема Software Factories. Есть даже книжка на русском.
T>Не поможет. Software Factories начинают приносить отдачу при очень-очень больших проектах, во всех других случаях это выброс денег на ветер.
Игорь привел ссылку на принцип, а не конкретную реализацию. А принцип отличаеться от реализации, тем что не существенно откуда придут артефакты. Например их можно купить. Или заоутсорсить другому отделу. Или написать самому, тока на том уровне на котором это тебе надо. Например у нас на проекте 100ни однотипных билиотечек лазящих в бд и предоставляющих веб-сервис интерфейс. Мы инвестировали в геренрилку проекта(12 часов) и сэкономили сотни часов. Вот вам и Software Factory, оправданная в малепусеньком проекте.
Здравствуйте, C...R...a...S...H, Вы писали:
CRA>Из своего опыта скажу, в одном из проектов, где я сейчас работаю, такой Common вообще в отдельный репозиторий выделен. CRA>В это репозитории помимо Common classes аля Period, ArrayUtils etc, лежат несколько общих фреймворков (Report, Workflow etc) CRA>И могу вам точно сказать, то заиспользовать данный Common в другом проекте будет самое настоящее удавольствие.
+1, просто эти коммоны должны писаться с учетом дизайна фреймворков... И тогда их не надо будет переписывать.
Для утилитного хлама мы использовали несколько подходов.
1) Утилитные классы мы просто линковали в студии. Тоесть на уровне всех проектов есть набор файлов с утилитарными класами. Каждый проект подрубает тока то что ему надо. Проблемы с изменениями мы вылавливали при помощи интеграционных билдов всего и вся.
2) Утилитные билиотеки с InternalsVisitbleTo...
Здравствуйте, Hexxx, Вы писали:
H>На больших проектах часто начинают выделять "особо хороший код" в отдельную библиотеку, гордо именуюемую common. H>Делают так многие, и все считают что это правильно. С одной стороны это хорошо, в одном месте правишь — хорошо всем. С другой стороны, когда начинается новый проект, слегка похожий на предидущий, в него начинают тулить комоны. А потом выясняется что проект совсем не похож на предидущий и комоны надо переписать так чтобы они удовлетворяли новым требованиям и начинается...
H>Короче, я так понимаю что я поднимаю риторический вопрос про добро и зло. Полюбому уже должно быть где-то умными дядьками это все описано. Ткните плиз а то никак не нагуглю.
Коллеги, может я чего не понимаю, но в чем вообще проблема? Если при разработке одного проекта появился функционал для повторного использования, да еще и достаточно отвязанный от контекста данного проекта, сам Бог велел использовать его в похожих проектах. При этом, чтобы избежать проблем с одновременным использованием одной и той же библиотеки в разных проектах, когда надо немножко поменять ее под каждый проект, просто делать для каждого проекта отдельную ветку развития данной библиотеки. Если в одном из проектов выловили ошибку или оптимизировали работу, просто копировать соответствующие удачные решения всем заинтересованным лицам (проектам). А если новые проекты стартуются часто, постепенно обновлять базовую ветку этой библиотеки.
Понятное дело, что если вынести в такой коммон сырой, плохо спроектированный или неполный функционал, слишком много уйдет времени на параллельное исправление нескольких веток. Но во-первых, это может все равно оказаться быстрее, чем писать все по-новой, а во-вторых, нужно стремиться к тому, чтобы общие и часто используемые решения были как можно лучшего качества.
