Низкая связанность, архитектура и организация команд

[lxsmkv]

Обидно две вещи. Первая, что такие статьи, где люди задаются вопросом, наблюдают, анализируют, синтезируют знания из нескольких источников и делают собственные выводы об окружающем мире — большая редкость ( а таких оригинальных русскоязычных статей я вообще не встречал). И вторая, что спрос на такие статьи среди масс не так велик. Многие лучше еще раз почитают про чистый код, или еще что-то жеваное-пережеваное по сто раз, но то что имеет более практический уклон, чем какие-то фундаментальные вещи разбирать. А фундаментальные знания очень важны, чтобы принимать правильные решения. Мне например из всех лекций в университете нравилась о «возможностях и ограничениях компьютерных систем». Когда понимаешь природу системы и ее границы — по-другому рассматриваешь задачу.

[ebt]

Если кратко, в чём состоят «возможности и ограничения компьютерных систем»?

[saaivs]

Если кратко, то без соблюдения некоторых принципов «компьютерные системы» перестают нормально масштабироваться и с ростом общей сложности любое изменение приводит к увеличению регрессии вплоть до непомерно высокой цены как просто за поддержку в работоспособном состоянии так и дальнейшее развитие продукта.

[goga_kk]

Прочитал надпись на картинке и дальше читать расхотелось.
НародУ — КислородУ??? — Вы серьезно)))
По чем нынче Интернет на деревне?

[Vasyutka]

А статья тем временем отличная :)

[vl65]

Я думаю, что большое количество коммуникаций в команде все же следствие. Первопричина такого положения в выборе технологий и решений для реализации на основании первичного понимания решаемой задачи. Естественно стараются выбрать технологии и решения, которые позволяют наиболее "быстро" и с "меньшими" затратами удовлетворить потребности заказчика.

Первичное понимание задачи часто бывает не полным и поверхностным. Выбранные технологии и решения на основе этого первичного понимания в дальнейшем могут не удовлетворять новому осознанию потребностей заказчика (при погружении в предметную область). Довольно часто начинаю придумывать различные "обходные решения". С течением времени таких "обходных решений" становиться все больше и больше, что объективно подталкивает к все большим коммуникациям внутри команды. Коммуникаций становиться все больше, реализации программного кода все меньше. Делать модификацию и наращивать функциональность становиться все сложнее. Добавление дополнительных ресурсов практически не изменяет ситуацию.

Чтобы этого избежать, нужно задавать себе хотя бы один вопрос. Какие полезные свойства добавит та или иная технология или решение в ваш проект? Именно добавит свойства в ваш проект, а не какими "полезными" свойствами они обладают. От части "полезных" свойств выбранной технологии или решения Вы можете сознательно отказаться и, более того, еще потратить усилия и ресурсы для этого отказа (применить "обходное решение").

Оцените каждое "полезное" свойство выбираемой технологии или задачи. Например, нужен ли в вашей задаче какой то кеш? Большинство скажет, да — нужен. Кеш ускоряет работу программы. Хорошо. А в ОС есть кеш? Есть. В СУБД есть кеш? Есть. И зачем Вам еще один кеш? Нет, нам надо. У нас предполагается высокая загрузка. Хорошо. Все ли ваши запросы потребуют кеширования? Нет. Можете ли сейчас предсказать какие запросы потребуют кеширования? В большинстве случаев, нет. А кешем надо как то управлять? Надо. А существуют ли другие решения ускоряющие обработку часто повторяющихся запросов? Существуют. Так зачем Вам еще один кеш?

Или еще одно "полезное" свойство — автоматическая перезагрузка вашего кода при его изменениях. В эксплуатации это свойство нужно? На мой взгляд, нет. Ваша система может "молотить" годами, если бы не потребность обслуживания железа и ОС. Ну и зачем тащить это "полезное" свойство в систему?

Или увидели, вот это свойство такого то решения будет востребовано в вашей системе. Хорошо. А другие свойства полезны? Нет. Так стоит ли тащить это решение в вашу систему? Может быть лучше повторить это решение в собственной реализации? Получите желаемое свойства вашей системе "заточенное" под ваши требования.

Так что думаете, оценивайте свой выбор и потребности решаемой задачи. И, возможно, сможете избежать проблемы описанной в статье.