1. Один большой солюшн на всех, все загружают один и тот же код и правят свою часть. Периодически приходится мерджить, т.к. рано или поздно двое затронут один и тот же файл.
2. Некая система контрактов (договоренностей) и их реализация. Каждый реализует сугубо свой модуль, который взаимодействует с другими про некому протоколу и никак не использует код из других модулей. Каждый правит только код своего модуля, к другим даже не имеет доступа.
>>>Каждый правит только код своего модуля, к другим даже не имеет доступа. N>>и если кто-то уволится, то..?
S>Тогда распределяют модули уходящего между другими.
если кто-то любит неприятные сюрпризы, то может и годится. Но в чем смысл команды, если каждый будет жить сам по себе, и при случае ему достанется никому неизвестное легаси?
Здравствуйте, notacat, Вы писали:
>>>>Каждый правит только код своего модуля, к другим даже не имеет доступа. N>>>и если кто-то уволится, то..?
S>>Тогда распределяют модули уходящего между другими. N>если кто-то любит неприятные сюрпризы, то может и годится. Но в чем смысл команды, если каждый будет жить сам по себе, и при случае ему достанется никому неизвестное легаси?
А ещё товарищ получит N имплементаций одной и той же функциональности разными способами, разными авторами и в разных модулях.
Здравствуйте, Shmj, Вы писали:
S>1. Один большой солюшн на всех, все загружают один и тот же код и правят свою часть. Периодически приходится мерджить, т.к. рано или поздно двое затронут один и тот же файл.
Однозначно этот вариант. Если код хоть сколько-нибудь адекватно разделён и задачи распределяются не от балды, то мердж это скорей исключение, чем правило. А нетривиальный мердж — тем более. А если реально будет конфликт, то обычно про это известно и ничего не мешает поговорить с человеком заранее, например чтобы сделать и согласовать изменения в отдельной ветке, на которую потом обоим перебазировать свои ветки.
В общем проблема мерджа скорей надумана. А возможность быстро посмотреть по всему коду всего проекта — бесценна.
S>2. Некая система контрактов (договоренностей) и их реализация. Каждый реализует сугубо свой модуль, который взаимодействует с другими про некому протоколу и никак не использует код из других модулей. Каждый правит только код своего модуля, к другим даже не имеет доступа.
Про то, чтобы вообще не иметь доступ к исходникам — даже думать не хочу, это ужасно. Readonly доступ будет провоцировать к плохому коду, т.к. может быть проще, например, сделать workaround у себя, чем договариваться с автором о том, чтобы поправить у него баг.
Вообще не вижу плюсов второго варианта. Разве что работают люди, к которым нет доверия. Чисто гипотетический вариант — нанял нескольких фрилансеров и раскидал между ними задачи. Но, мне кажется, такой стиль работы не взлетит. По моему опыту проще фрилансеру дать все нужные доступы и надеяться на его адекватность, по крайней мере обычно так поступают.
S>1. Один большой солюшн на всех, все загружают один и тот же код и правят свою часть. Периодически приходится мерджить, т.к. рано или поздно двое затронут один и тот же файл.
S>2. Некая система контрактов (договоренностей) и их реализация. Каждый реализует сугубо свой модуль, который взаимодействует с другими про некому протоколу и никак не использует код из других модулей. Каждый правит только код своего модуля, к другим даже не имеет доступа.
Здравствуйте, Shmj, Вы писали:
S>2. Некая система контрактов (договоренностей) и их реализация. Каждый реализует сугубо свой модуль, который взаимодействует с другими про некому протоколу и никак не использует код из других модулей. Каждый правит только код своего модуля, к другим даже не имеет доступа.
Есть живой пример того что вы имеете виду? Иногда приходится использовать бинарные dll. в этом нет ничего плохого, если это сторонняя библиотека.
но когда у вас общая кодовая база в большинстве ЯП удобнее 1-е( т.к. в основном ЯП монолитные несмотря на физическое разделение на компоненты).
Контракт соблюдает компилятор созданный умными людьми и его нельзя нарушить.
Здравствуйте, varenikAA, Вы писали:
AA>Здравствуйте, Shmj, Вы писали:
S>>2. Некая система контрактов (договоренностей) и их реализация. Каждый реализует сугубо свой модуль, который взаимодействует с другими про некому протоколу и никак не использует код из других модулей. Каждый правит только код своего модуля, к другим даже не имеет доступа.
AA>Есть живой пример того что вы имеете виду?
Здравствуйте, Sharov, Вы писали:
S>Микросервисная архитектуру не оно?
да, только преимуществ ноль на мой взгляд.
героически преодолевать самими созданными трудности?
прикручивать свагер, графкьэль, загружать в докер. зачем?
Здравствуйте, varenikAA, Вы писали:
S>>Для контроля и облегчения работы с распределенной системой, которая нужна, чтобы держать нагрузку. AA>часто ли вы сталкиваетесь с такой нагрузкой, что требуется особые инженерные решения?
К сожалению нет, надеюсь пока нет, но вообще учитывая 5g и iot, бигдата скоро будет общим местом.
Дело даже не в нагрузке, сколько в переходе к SAAS модели, когда все эти инструменты внезапно пригождаются.
Здравствуйте, YuriV, Вы писали:
>>>>>Каждый правит только код своего модуля, к другим даже не имеет доступа. N>>>>и если кто-то уволится, то..?
S>>>Тогда распределяют модули уходящего между другими. N>>если кто-то любит неприятные сюрпризы, то может и годится. Но в чем смысл команды, если каждый будет жить сам по себе, и при случае ему достанется никому неизвестное легаси? YV>А ещё товарищ получит N имплементаций одной и той же функциональности разными способами, разными авторами и в разных модулях.
А например?
Если это базовая функциональность, она реализована в FCL/boost/wherever...
Если это узкоспециальная функциональность, как так получается, что её пришлось реализовывать в 2 разных модулях 2 разных авторов?
YV>>А ещё товарищ получит N имплементаций одной и той же функциональности разными способами, разными авторами и в разных модулях. S>Если это узкоспециальная функциональность, как так получается, что её пришлось реализовывать в 2 разных модулях 2 разных авторов?
См. условия задачи
Каждый правит только код своего модуля, к другим даже не имеет доступа.
Здравствуйте, Muxa, Вы писали:
YV>>>А ещё товарищ получит N имплементаций одной и той же функциональности разными способами, разными авторами и в разных модулях. S>>Если это узкоспециальная функциональность, как так получается, что её пришлось реализовывать в 2 разных модулях 2 разных авторов? M>См. условия задачи M>
Каждый правит только код своего модуля, к другим даже не имеет доступа.
YV>N имплементаций одной и той же функциональности разными способами, разными авторами и в разных модулях.
И если надо в каком-то из модулей ее поправить, можно делать это смелее, потому что меньше опасности сломать что-нибудь неизвестно где
Организации проектируют системы, которые копируют структуру коммуникаций в этой организации
В данном случае нужно просто ответить на вопрос: какова структура коммуникаций команды? Если всё более менее однородно, с монолитом будет удобно. Если очень неоднородно, контракты — наше всё.
