Описывается скорее DI как Dependency Inversion, чем как Dependency Injection для которого как правило нужен фреймворк. Dependency Inversion это легко реализуемый паттерн для любого языка, поддерживающего интерфейсы и его роль - разделить слои архитектуры, сами слои определяются базовыми требованиями - если в ТЗ есть про сохранение данных, значит по-любому у вас будет Persistency Layer, если у вас веб-приложение - значит будет клиентская часть и так далее. В общем-то три классических слоя всем привычны и никаких сложных конструкций не требуют. Не вижу, как трехслойная архитектура обязательно тянет за собой инъекцию зависимостей и моки сервисов для юнит-тестов, если честно.
В статье преобладает формальная управленческая херня, которая может и описывает какие-то аспекты проф. роста, но совершенно не специфична даже для технических специалистов и тем более - разработчиков ПО, которых обычно имеют в виду, произнося "мидл" или "сеньор". Есть ощущение, что автор никогда не был разработчиком и даже не так уж много общался с разработчиками. А ведь у нас свое профессиональное сообщество, внутри которого только и имеют смысл слова "мидл" и "сеньор".
Я бы сказал, что мидл владеет хорошими инструментами решения задач в своей области, а сеньор знает на своем опыте разные сценарии применения этих инструментов. Мидл набирает этот самый опыт того, как инструменты проявляют себя в реальной разработке. Сеньор же учится подбирать новые инструменты по мере развития проекта и команды и набирает опыт путей этого самого развития проекта/продукта/команды, чтобы когда-нибудь стать способным отвечать за проект как целое - скажем, за техническую часть как техлид или архитектор или за коммуникационную/командную как PM.
По заголовку ожидал, что тут будет про современные синтезаторы на основе Raspberry Pi и всякое такое. А тут про Спектрум. Интересно было бы сравнить вычислительную мощность Спектрума или Амиги с мощностью первых профессиональных цифровых синтезаторов/сэмплеров/секвенсоров и прочих драм-машин, которые появлялись примерно в то же время.
Вы с вашим "ооо вейт" тоже закончили за упокой, почему "ооо вейт" можно, а людей юзерами называть нельзя? Да и почему нельзя сказать обычным русским языком: "автор показал поверхностное знакомство с темой, смешав в кучу много разных дискуссий, таких, как..."? Статья фиговая, согласен, но и ваш комментарий не лучше, не думаете же вы всерьез, что "администрация Хабра" прочтет ваш комментарий? А тогда зачем к ней обращаться, как и обсуждать, чем предмет философии отличается от предмета филологии?
Одна из самых офигенных статей на хабре за все время, даже не верится, что тут такое бывает. Автору точно нужно продолжать копать, такая рефлексия о нашей индустрии нам нужна.
Комбинаторный взрыв сложности кода с документацией конечно никак не связан, лечится это, как тут уже отмечали, с помощью Clean Architecture по большому счету, или подобными подходами, когда вы запрещаете не связанным друг с другом модулям иметь потенциальное влияние друг на друга. На более низком уровне Clean Code и в целом аджайл-подходы (TDD, самодокументирующийся код и вот это все) призваны бороться именно с этой проблемой. И это более действенный вариант с точки зрения именно роста сложности кода и снижения velocity и time-to-market, чем тщательное документирование - скажу как представитель проекта, где с внутренней технической документацией все довольно неплохо. Документация важна, но с комбинаторным взрывом сложности она как таковая и не борется.
Опишем реалистичный сценарий, как появляются проекты на двух программистов и тестировщика. В каком-нибудь развитом банке (или развитой цифровой компании типа мобильного оператора, большого интернет-провайдера или чего-то подобного) появляется идея нового сервиса для клиентов, находят пару скучающих разрабов с уже существующих проектов, берут тестировщика по совместительству с существующим проектом, начинают пилить, дают им так же из существующих проектов по совместительству лида и PM. У этих людей уже есть облако, с которым они уже работали на прошлых проектах, и если они решат выкладывать на какой-нибудь хостинг на VPS свое творение, на них посмотрят как на сумасшедших и объяснят, что это не дело.Поскольку проект предполагается предлагать многотысячной аудитории существующих клиентов, то требования к тестированию, автотестированию высокие, код ревью обязательно, тестировщик на полставки ожидает, что как и на других проектах он будет нажимать кнопочку в CI и ему будет выкатываться свежий инстанс с приложением, или даже без кнопочки, просто будет брать ветку из тикета и для нее уже есть инстанс. И по-другому работать как-то и не предполагается.Так понятнее?
Скорее зависит от специфики продукта и организации разработки. Если это облачный сервис с релизами раз в две недели, например, то в реализации девопс-подхода очень много смысла, даже если вся команда - это два разработчика и один тестировщик. Ну и понятно, что если вы хотите trunk based, то у вас девопс-подход естественным образом вырастет сам собой с большой вероятностью. А часто ядро команды приходит с trunk based проекта и им попросту удобнее так работать, так что они девопсом занимаются с самого начала, не сильно задумываясь, что это девопс.
Редкий случай, когда кто-то на хабре вменяемо написал на эту тему, действительно у нас девопсами называют сисопсов и админов, девопс - это вообще не должность и не специальность, а подход, который обычно в небольших командах разработчиками реализуется в первую очередь, а не админами.
Я бы даже сказал - просится цифровой кроссовер с DSP на ADAU и потом пополосное усиление, тогда можно за часов 200 настройки нарулить максимально возможный звук для этих динамиков и корпуса. И будет кстати очень круто звучать, бас от 30 Гц и т.п.
Вот только это не DevOps, а SysOps, по большому счету - системное администрирование применительно к распределенным системам. DevOps может реализовываться на таком стеке или частично/полностью на другом, но DevOps - это вообще про другое.
Это трудовое право с его довольно большой поддержкой работников по сравнению с мировой практикой сохраняется все годы путинского правления и с ним ничего не случилось даже за последние полтора года. Нынешняя власть видит потенциальную угрозу скорее в бизнесе, чем в возможных инициативах со стороны наемных работников. Настоящие профсоюзы будут давить, но трудовое право оставят как есть.
Вашу мысль правильней изображать не в виде пирамиды, а в виде вложенных одна в другую петель обратной связи, каждая из которых может "вернуть" код на доработку. Написали строчку - увидели что строчка слишком длинная - исправили, увидели что компилятор ругается - исправили, тест не прошел - исправили, зарелизили, всем понравилось - всем захотелось миллион новых фич - исправили и т.д.
Так вот, если вы надеетесь, что ваша программа станет успешной, то нужно быть готовым, что к вам придут просить миллион новых фич, и с большой вероятностью "проблема Возняка с лимитом 2к на размер" из комментов здесь будет наименьшей проблемой из тех, что у вас будут, вам ради новых фич с радостью докинут и 2к места, и 222к если надо будет.
«Отличный код из маленьких модулей и автономных функций и виджетов» — это как раз про Angular. В гораздо большей степени, чем про jQuery. Вот когда вы делаете приложение, в котором маленькие модули и автономные виджеты приходится друг с другом увязывать, сервисы Angular как раз оказываются весьма уместны. А так можно простой виджет для сайта зафигачить на Angular гораздо проще и изящней, чем с jQuery. Без всяких сервисов.
Да я не могу сказать, что прям фанат, хотя считаю Толстого действительно сильным писателем, со вполне заслуженной мировой славой. Вопрос вот в чем: в школе понятно, вам что-то навязали к прочтению, к чему у вас интереса нет, ну и естественный протест на несвободу появляется. Но вот вы во взрослом возрасте прочли и вам не понравилось. Нормальная реакция? Да. Почему? Не ваше, не согласны, не поняли, плохое настроение было — а какая разница? Для вас разница есть может — вы это проанализируете и это как-то направит ваш поиск тех книг, которые вам понравятся с большей вероятностью. Но действительно ли вам нужны подтверждения вашего нормального человеческого неприятия какого-то произведения? Вот Логинов приложил к творчеству Толстого некоторые стандарты, которые он считает правильными. Обязан Толстой или какой-либо другой писатель подчиняться каким-либо стандартам? Если он сам их себе ставит — может и обязан, перед самим собой. То есть эссе Логинова если и интересно, то в том смысле, что он раскрыл те стандарты, которые ставит, видимо, перед самим собой. А иначе — все равно, что обвинять Цоя, что он не Дима Билан, а Диму Билана — что он не Цой.
Мне одному кажется, что «техника априори верна всегда и везде, поскольку за ней стоит Яндекс» — это очень странное предположение и что естественно предполагать как раз обратное?
Ага, возникает вопрос, чел просто прочел Domain Driven Design или все-таки сам додумался. Потому как методология прям как дословно из книжки Эванса. Например фраза «обобщения без глубокого понимания предметной области».
Все дело в том что эти соображения мало имеют значения для тех, кому нравится Толстой. Я массу удовольствия получил от чтения его книг, и к очень большому сожалению большинство современных писателей этого удовольствия не приносят даже близко. То есть у Толстого есть своя целевая аудитория, свой круг благодарных читателей, полтора века спустя. И вроде и у Логинова есть свой круг. И вроде все замечательно. Но Логинов потратил энное количество времени на то, чтобы написать эссе о плохом писателе Толстом. От которого те, кто любит Толстого, вряд ли перестали его любить, а те, кто его не любит, обрели некоторое ощущение своей правоты, что они не такие придурки сами по себе, а с ними еще известный современный писатель-фантаст Логинов.
Описывается скорее DI как Dependency Inversion, чем как Dependency Injection для которого как правило нужен фреймворк. Dependency Inversion это легко реализуемый паттерн для любого языка, поддерживающего интерфейсы и его роль - разделить слои архитектуры, сами слои определяются базовыми требованиями - если в ТЗ есть про сохранение данных, значит по-любому у вас будет Persistency Layer, если у вас веб-приложение - значит будет клиентская часть и так далее. В общем-то три классических слоя всем привычны и никаких сложных конструкций не требуют. Не вижу, как трехслойная архитектура обязательно тянет за собой инъекцию зависимостей и моки сервисов для юнит-тестов, если честно.
В статье преобладает формальная управленческая херня, которая может и описывает какие-то аспекты проф. роста, но совершенно не специфична даже для технических специалистов и тем более - разработчиков ПО, которых обычно имеют в виду, произнося "мидл" или "сеньор". Есть ощущение, что автор никогда не был разработчиком и даже не так уж много общался с разработчиками. А ведь у нас свое профессиональное сообщество, внутри которого только и имеют смысл слова "мидл" и "сеньор".
Я бы сказал, что мидл владеет хорошими инструментами решения задач в своей области, а сеньор знает на своем опыте разные сценарии применения этих инструментов. Мидл набирает этот самый опыт того, как инструменты проявляют себя в реальной разработке. Сеньор же учится подбирать новые инструменты по мере развития проекта и команды и набирает опыт путей этого самого развития проекта/продукта/команды, чтобы когда-нибудь стать способным отвечать за проект как целое - скажем, за техническую часть как техлид или архитектор или за коммуникационную/командную как PM.
По заголовку ожидал, что тут будет про современные синтезаторы на основе Raspberry Pi и всякое такое. А тут про Спектрум. Интересно было бы сравнить вычислительную мощность Спектрума или Амиги с мощностью первых профессиональных цифровых синтезаторов/сэмплеров/секвенсоров и прочих драм-машин, которые появлялись примерно в то же время.
Вы с вашим "ооо вейт" тоже закончили за упокой, почему "ооо вейт" можно, а людей юзерами называть нельзя? Да и почему нельзя сказать обычным русским языком: "автор показал поверхностное знакомство с темой, смешав в кучу много разных дискуссий, таких, как..."? Статья фиговая, согласен, но и ваш комментарий не лучше, не думаете же вы всерьез, что "администрация Хабра" прочтет ваш комментарий? А тогда зачем к ней обращаться, как и обсуждать, чем предмет философии отличается от предмета филологии?
Одна из самых офигенных статей на хабре за все время, даже не верится, что тут такое бывает. Автору точно нужно продолжать копать, такая рефлексия о нашей индустрии нам нужна.
Комбинаторный взрыв сложности кода с документацией конечно никак не связан, лечится это, как тут уже отмечали, с помощью Clean Architecture по большому счету, или подобными подходами, когда вы запрещаете не связанным друг с другом модулям иметь потенциальное влияние друг на друга. На более низком уровне Clean Code и в целом аджайл-подходы (TDD, самодокументирующийся код и вот это все) призваны бороться именно с этой проблемой. И это более действенный вариант с точки зрения именно роста сложности кода и снижения velocity и time-to-market, чем тщательное документирование - скажу как представитель проекта, где с внутренней технической документацией все довольно неплохо. Документация важна, но с комбинаторным взрывом сложности она как таковая и не борется.
Опишем реалистичный сценарий, как появляются проекты на двух программистов и тестировщика. В каком-нибудь развитом банке (или развитой цифровой компании типа мобильного оператора, большого интернет-провайдера или чего-то подобного) появляется идея нового сервиса для клиентов, находят пару скучающих разрабов с уже существующих проектов, берут тестировщика по совместительству с существующим проектом, начинают пилить, дают им так же из существующих проектов по совместительству лида и PM. У этих людей уже есть облако, с которым они уже работали на прошлых проектах, и если они решат выкладывать на какой-нибудь хостинг на VPS свое творение, на них посмотрят как на сумасшедших и объяснят, что это не дело.Поскольку проект предполагается предлагать многотысячной аудитории существующих клиентов, то требования к тестированию, автотестированию высокие, код ревью обязательно, тестировщик на полставки ожидает, что как и на других проектах он будет нажимать кнопочку в CI и ему будет выкатываться свежий инстанс с приложением, или даже без кнопочки, просто будет брать ветку из тикета и для нее уже есть инстанс. И по-другому работать как-то и не предполагается.Так понятнее?
Скорее зависит от специфики продукта и организации разработки. Если это облачный сервис с релизами раз в две недели, например, то в реализации девопс-подхода очень много смысла, даже если вся команда - это два разработчика и один тестировщик.
Ну и понятно, что если вы хотите trunk based, то у вас девопс-подход естественным образом вырастет сам собой с большой вероятностью. А часто ядро команды приходит с trunk based проекта и им попросту удобнее так работать, так что они девопсом занимаются с самого начала, не сильно задумываясь, что это девопс.
Редкий случай, когда кто-то на хабре вменяемо написал на эту тему, действительно у нас девопсами называют сисопсов и админов, девопс - это вообще не должность и не специальность, а подход, который обычно в небольших командах разработчиками реализуется в первую очередь, а не админами.
Я бы даже сказал - просится цифровой кроссовер с DSP на ADAU и потом пополосное усиление, тогда можно за часов 200 настройки нарулить максимально возможный звук для этих динамиков и корпуса. И будет кстати очень круто звучать, бас от 30 Гц и т.п.
Какие там "неграфические возможности" вы нашли? CUDA? Tensor cores? RT cores? Контроллер питания? xD
Вот только это не DevOps, а SysOps, по большому счету - системное администрирование применительно к распределенным системам. DevOps может реализовываться на таком стеке или частично/полностью на другом, но DevOps - это вообще про другое.
Это трудовое право с его довольно большой поддержкой работников по сравнению с мировой практикой сохраняется все годы путинского правления и с ним ничего не случилось даже за последние полтора года. Нынешняя власть видит потенциальную угрозу скорее в бизнесе, чем в возможных инициативах со стороны наемных работников. Настоящие профсоюзы будут давить, но трудовое право оставят как есть.
Вашу мысль правильней изображать не в виде пирамиды, а в виде вложенных одна в другую петель обратной связи, каждая из которых может "вернуть" код на доработку. Написали строчку - увидели что строчка слишком длинная - исправили, увидели что компилятор ругается - исправили, тест не прошел - исправили, зарелизили, всем понравилось - всем захотелось миллион новых фич - исправили и т.д.
Так вот, если вы надеетесь, что ваша программа станет успешной, то нужно быть готовым, что к вам придут просить миллион новых фич, и с большой вероятностью "проблема Возняка с лимитом 2к на размер" из комментов здесь будет наименьшей проблемой из тех, что у вас будут, вам ради новых фич с радостью докинут и 2к места, и 222к если надо будет.