По поводу армии, очень рекомендую вам почитать про то, какой была она при Суворове. Вячеслав Летуновский очень хорошо проанализировал «Науку побеждать». И там до зеленого все дошло вполне, при этом Суворов не проиграл ни одного сражения. Никому.
Также хочу отметить, что армия все же должна быть больше про синий, чем про красный. Красный — это банда, а не армия. Очень рекомендую почитать Дона Бека и Криса Кована «Спиральная динамика», если еще не читали (только с 3-го раздела! это важно :-)). Там как раз очень подробно показаны все уровни, армия и церковь — это синий (по крайней мере так должно быть). И синяя армия победит красную в долгую. Как только появляются технологии, может и до оранжевого вполне дойти. Эффективность и в войне важна.
Странно, что автор не дошел до желтого уровня. Все-таки, чтобы организация пошла эволюционировать по спирали, владелец должен стать желтым. Иначе он будет падать во все ловушки предыдущих уровней и застревать в них надолго.
Хочется разбавить разговор своим скромным мнением. Я программист со стажем 20+, а последние 6 лет еще и компанию свою развиваю как собственник и директор. Так вот хочется из мира бизнеса аналогию привести.
Если собственник свои ключевые компетенции полностью делегировал сотрудникам и при этом не знает, как они это делают, — он попадает в полную зависимость от них. Выстроить процессы так, чтобы все были маленькими винтиками и делали свою маленькую работу можно. Вроде бы здорово все, все работает, можно не переживать. Но увольнение или болезнь ключевого сотрудника — беда.
А выход какой? Выход в том, что собственник должен как минимум уметь выполнять сам все ключевые функции. Поруководить цехом, продать клиенту услугу и так далее. В бизнесе все это известно уже лет 100, так почему в программировании должно быть иначе?
На мой взгляд умение искать аналогии в окружающем мире и использовать их на пользу проекту/продукту/компании и есть один из главных признаков высокой квалификации. А вовсе не умение найти в гугле функцию на 3 строки. Поэтому я никогда не доверяла экосистеме Руби и Node.js. Просто второе бомбануло раньше в силу более бурного роста.
Также все вышесказанное заставляет меня глубоко сомневаться в успехе ИТ-компаний, во главе которых не стоят программисты с опытом. Непрограммист смотрит на программистов как на чудаковатых волшебников и совершенно теряется, если кто-то из них не может или не хочет что-то делать, а он сам — собственник — не может стряхнуть пыль и расчехлить, чтобы временно заменить бойца. Не то, чтобы надо было постоянно бегать и тушить пожары, это как раз плохо. Но надо иметь возможность. Не терять хватку помогает обучение новых сотрудников и студентов — и в процесс не лезешь, и квалификацию не теряешь.
Всем, кому интересна тема жизненного цикла организаций, рекомендую почитать Ицхака Адизеса Управление жизненным циклом корпорации. Там очень подробно описаны все этапы, причины смерти компаний на разных стадиях, признаки старения организаций.
То, что описывает автор статьи, переход от этапа Расцвета во время которого было IPO, выход в Турцию — еще с Сегаловичем — и много чего еще к этапу Стабильности — когда прописаны все процессы, развитие идет по планам и так далее. Чтобы не скатиться со Стабильности к Аристократизму надо не задирать нос, а всегда искать точки роста. Потому что после этапа Стабильности идет уже старение компании.
Есть примеры, когда компании находятся на этапе Стабильности столетиями. Я сейчас точно не вспомню, но это как правило европейские компании, которые стартовали веке в 18-м. Так можно. Но это не так просто.
Если верить автору, то Аристократизм и Бюрократия не за горами. Как на самом деле — хз, поживем — увидим :-) Но это точно еще далеко не дряхлость.
Мы как могли трубили о нем в группах ИТ-субботников, IT-лофта, репостили все, кто мог. Подпишитесь на группы и будет вам счастье, у нас и не только это мероприятие проходило :-)
Игрокам заранее было выслано все, что необходимо. Кроме того, это не был турнир по покеру! Автор статьи немного сместил акценты с того, ради чего на самом деле все это затевалось.
Смысл мероприятия не в создании лучшего покерного бота! А в понимании на практике Continuous delivery, покрытия тестами и многих других практик командной разработки. Очень жаль, что статья вообще не упоминает об этом. Именно эти вещи по итогу больше всего запомнились участникам. Многие говорили, что по-другому взглянули на командную работу, оценили, насколько могут помочь тесты и т.д.
На HappyDev будет много мастер-классов по Postgres от российских разработчиков оного. И для тех, кто использует, и для DBA, и для потенциальных разработчиков самой СУБД.
Никто не говорит, что надо прикручивать все подряд. Но если начать как следует копать, то выяснится, что единственный математически обоснованный способ писать расширяемый код на современных вычислительных системах — это модель акторов. И это, конечно, не описывается словом «прикрутить» в обычном понимании этого слова. Оно возникло только из сочетания с рельсами. Потому что там либо выкинуть все рельсы, либо «прикрутить».
У вас просто есть два пути. Первый — пробовать все самому, решая все усложняющиеся задачи и придя в итоге к той же модели, но через год или больше. Второй — попробовать узнать побольше, разобраться в теории и существенно сократить этот путь, повысив качество решений, которые вы сможете создавать. Выбор, безусловно, за вами :-)
Вы сейчас открыли для себя новый чудный мир акторов, паттернов потоковой обработки и так далее :-) Сразу скажу, что эта история полностью альтернативна Rails, и вам будет очень сложно увязать одно с другим.
Это объясняет миграцию разработчиков с Rails на Erlang, Clojure, Scala и так далее. Однако сами по себе языки не панацея, интересна сама модель акторов, на которой построен принцип работы Erlang-приложений и фреймворк Akka.
Если интересно, можем пообщаться на эту тему, вам совершенно верно упомянули Роба Мартина и паттерны. DHH, к сожалению, все это отмел как «устаревшее» и в результате разработчики плачут кровавыми слезами, однако, щедро оплачиваемыми. Но эта лафа скоро может закончиться, потому что модель акторов сейчас становится модной, а это значит, что рельсы могут сдать свои позиции.
Отлично написано! Как директор компании, ограниченной 25-30 человеками в данный момент, через которого проходят все заказы, подписываюсь под каждым словом :-)
Все пользователи бесплатных продуктов Google — продукты, например. А потребители у Google те, кто делает контекстную рекламу. Для каждого из нас, персонально :-)
Спасибо за слова про сайт, но он в жесткой разработке, это далеко не окончательный вариант. Там и картинок под ретину нет, например :-)
1. В-общем, мы изначально не ставили себе целью сделать SOA. Наша цель была сделать максимально независимыми Use cases. Сейчас каждый Use case реализуется методом какого-то *Service и поэтому их можно менять независимо. По сути — это сервисы с точки зрения DDD, но не SOA, конечно. Прошу прощение, за то, что ввела в заблуждение.
2) Нет, разделения персистентности у нас пока нет и не будет. Поскольку все текущие модели сейчас относятся к одному Bounded context (это опять DDD), то их и не нужно разделять. А вот если появится mailer или еще какой-то технический сервис, то вполне можно будет для него использовать другое хранилище.
Если посмотреть на пакеты и остальное под углом DDD, не пытаясь разделить Employer и Recruiter на сервисы с точки зрения SOA (а мы и не планируем этого), то описанных вами проблем просто нет.
3) Это разные роли. Они являются агрегатами сущностей (опять DDD) и поэтому методы собраны именно так. Здесь разделение только логическое, а не физическое.
Мы как раз сейчас экспериментируем с архитектурой, сделали Spring-приложение, в котором пошли как раз от сервисов. БД у нас хоть и одна, но поскольку сервисы независимы, ничто не мешает сделать так как вы говорите — свою персистентность для каждого сервиса.
Мы не используем Hibernate, взяли реализацию DataMapper — MyBatis. Таким образом, наши модели — чистые POJO, без жестко заданных связей через какой-нибудь JPA.
Вопрос: что бы вы посоветовали в данном случае сделать, чтобы изолировать сервисы друг от друга по данным? Если нужно, текущее состояние кода можно посмотреть здесь: github.com/7bits/jade-fff (проект учебный, но по мотивам реального).
Также хочу отметить, что армия все же должна быть больше про синий, чем про красный. Красный — это банда, а не армия. Очень рекомендую почитать Дона Бека и Криса Кована «Спиральная динамика», если еще не читали (только с 3-го раздела! это важно :-)). Там как раз очень подробно показаны все уровни, армия и церковь — это синий (по крайней мере так должно быть). И синяя армия победит красную в долгую. Как только появляются технологии, может и до оранжевого вполне дойти. Эффективность и в войне важна.
Странно, что автор не дошел до желтого уровня. Все-таки, чтобы организация пошла эволюционировать по спирали, владелец должен стать желтым. Иначе он будет падать во все ловушки предыдущих уровней и застревать в них надолго.
Если собственник свои ключевые компетенции полностью делегировал сотрудникам и при этом не знает, как они это делают, — он попадает в полную зависимость от них. Выстроить процессы так, чтобы все были маленькими винтиками и делали свою маленькую работу можно. Вроде бы здорово все, все работает, можно не переживать. Но увольнение или болезнь ключевого сотрудника — беда.
А выход какой? Выход в том, что собственник должен как минимум уметь выполнять сам все ключевые функции. Поруководить цехом, продать клиенту услугу и так далее. В бизнесе все это известно уже лет 100, так почему в программировании должно быть иначе?
На мой взгляд умение искать аналогии в окружающем мире и использовать их на пользу проекту/продукту/компании и есть один из главных признаков высокой квалификации. А вовсе не умение найти в гугле функцию на 3 строки. Поэтому я никогда не доверяла экосистеме Руби и Node.js. Просто второе бомбануло раньше в силу более бурного роста.
Также все вышесказанное заставляет меня глубоко сомневаться в успехе ИТ-компаний, во главе которых не стоят программисты с опытом. Непрограммист смотрит на программистов как на чудаковатых волшебников и совершенно теряется, если кто-то из них не может или не хочет что-то делать, а он сам — собственник — не может стряхнуть пыль и расчехлить, чтобы временно заменить бойца. Не то, чтобы надо было постоянно бегать и тушить пожары, это как раз плохо. Но надо иметь возможность. Не терять хватку помогает обучение новых сотрудников и студентов — и в процесс не лезешь, и квалификацию не теряешь.
То, что описывает автор статьи, переход от этапа Расцвета во время которого было IPO, выход в Турцию — еще с Сегаловичем — и много чего еще к этапу Стабильности — когда прописаны все процессы, развитие идет по планам и так далее. Чтобы не скатиться со Стабильности к Аристократизму надо не задирать нос, а всегда искать точки роста. Потому что после этапа Стабильности идет уже старение компании.
Есть примеры, когда компании находятся на этапе Стабильности столетиями. Я сейчас точно не вспомню, но это как правило европейские компании, которые стартовали веке в 18-м. Так можно. Но это не так просто.
Если верить автору, то Аристократизм и Бюрократия не за горами. Как на самом деле — хз, поживем — увидим :-) Но это точно еще далеко не дряхлость.
Смысл мероприятия не в создании лучшего покерного бота! А в понимании на практике Continuous delivery, покрытия тестами и многих других практик командной разработки. Очень жаль, что статья вообще не упоминает об этом. Именно эти вещи по итогу больше всего запомнились участникам. Многие говорили, что по-другому взглянули на командную работу, оценили, насколько могут помочь тесты и т.д.
У вас просто есть два пути. Первый — пробовать все самому, решая все усложняющиеся задачи и придя в итоге к той же модели, но через год или больше. Второй — попробовать узнать побольше, разобраться в теории и существенно сократить этот путь, повысив качество решений, которые вы сможете создавать. Выбор, безусловно, за вами :-)
Ну и модель акторов вы туда никак не прикрутите при всем желании.
Это объясняет миграцию разработчиков с Rails на Erlang, Clojure, Scala и так далее. Однако сами по себе языки не панацея, интересна сама модель акторов, на которой построен принцип работы Erlang-приложений и фреймворк Akka.
Если интересно, можем пообщаться на эту тему, вам совершенно верно упомянули Роба Мартина и паттерны. DHH, к сожалению, все это отмел как «устаревшее» и в результате разработчики плачут кровавыми слезами, однако, щедро оплачиваемыми. Но эта лафа скоро может закончиться, потому что модель акторов сейчас становится модной, а это значит, что рельсы могут сдать свои позиции.
Еще есть такой отличный рецепт прийти на хорошую ИТ-встречу — провести ее :-)
1. В-общем, мы изначально не ставили себе целью сделать SOA. Наша цель была сделать максимально независимыми Use cases. Сейчас каждый Use case реализуется методом какого-то *Service и поэтому их можно менять независимо. По сути — это сервисы с точки зрения DDD, но не SOA, конечно. Прошу прощение, за то, что ввела в заблуждение.
2) Нет, разделения персистентности у нас пока нет и не будет. Поскольку все текущие модели сейчас относятся к одному Bounded context (это опять DDD), то их и не нужно разделять. А вот если появится mailer или еще какой-то технический сервис, то вполне можно будет для него использовать другое хранилище.
Если посмотреть на пакеты и остальное под углом DDD, не пытаясь разделить Employer и Recruiter на сервисы с точки зрения SOA (а мы и не планируем этого), то описанных вами проблем просто нет.
3) Это разные роли. Они являются агрегатами сущностей (опять DDD) и поэтому методы собраны именно так. Здесь разделение только логическое, а не физическое.
Про servvlet-api и maven посмотрю, спасибо!
Мы не используем Hibernate, взяли реализацию DataMapper — MyBatis. Таким образом, наши модели — чистые POJO, без жестко заданных связей через какой-нибудь JPA.
Вопрос: что бы вы посоветовали в данном случае сделать, чтобы изолировать сервисы друг от друга по данным? Если нужно, текущее состояние кода можно посмотреть здесь: github.com/7bits/jade-fff (проект учебный, но по мотивам реального).