Спасибо за статью.
То ли я чего-то не понял в П7, то ли совсем не согласен.
Вот типовой пример при работе с репозиторием:
// repo layer
public Document getDocument(String id) throws dbVendor.UnknownIdException {
return client.getDocument(id);
}
// service layer
public Client getClient(String id) throws myService.ClientNotExistsException {
try {
return convert(getDocument(id));
} catch (dbVendor.UnknownIdException ex) {
throw new myService.ClientNotExistsException(ex, id);
}
}
// API layer
public APIResponse getClientById(String id) {
try {
return getClient(id);
} catch (myService.ClientDoesNotExistsException ex) {
return APIResponse.notFound(id);
}
}
Если dbVendor.UnknownIdException не превратить в myService.ClientNotExistsException, то вы нарушите не только инкапсуляцию, но и ваш сервисный слой потеряет всякий смысл и АПИ слой будет напрямую зависеть от репозитария.
Важно помнить, что "интеграция" ( в общем как и всякий другой выбор) имеет под собой trade-off. Да, писать и поддерживать интеграции требует существенных затрат, но это позваляет описывать контракты для взаимодействия разных систем. Как следствие, с этими контрактами можно говорить о понижении связности, и как следствие возмоности независимой эволюции систем, ситгерированных таким способом.
Обычно, далеко не все системы обновляются или измениются регулярно. Меняются же те, где бизнес пытается выделиться на рынке. Как следствие, если "корневая" или "центральная" модель поменяется, прийдётся обновлять и те системы, которые трогать бы не хотелось.
Корректно спроектированные интеграции позволяют разным бизнес областям эволюционировать более независимо.
Не только поддержка хороша для Канбана.
Если совсем на пальцах, то отличия два — отсутвие спринтов и ограничение на количество одновременно выполняемой работы. Можно вольно перефразировать — первоочередная задача заканчивать работу, доводить её до конца.
Канбан прекрасно работает в R&D отделах на исследовательских задачах. Если задачи ставить в формате "у тебя две недели на эту задачу" без точного описания конечного результата (но с описанием MVP), то работает еще лучше, т.к. работа ДОДЕЛЫВАЕТСЯ и уходит в эксплуатацию.
Стартапы при должном менеджменте можно рассматривать тоже как R$D отделы, что показывает мой опыт. В результате вы пилите маленькие кусочки пару раз в неделю и релизитесь, получая отзыв от CEO/PM и меняя приоритеты 1-20 раз в неделю. Но самое главное, подчеркну — задачи ДОДЕЛЫВАЮТСЯ, пусть не до идеального состояния, но до рабочего, и уходят в эксплуатацию, а не висят неделями из-за смены приоритетов!
Я ничего лично против Вас не имею, но к финансистам отношусь настороженно: Вы хотите получить новый высокодоходный финансовый инструмент и Ваша задача его продать населению как "супер-доходный и без рисков". После доткомов, кикстертеров и МММов доверие к "новым экономикам", как минимум, утрачено.
Соглашусь с Вами, что лучше хоть как-то начать регулировать, а не говорить "лучше не пользуйтесь", но как по мне, лучше это добро прикрывать, тем более для нашего доверчивого населения.
Те же американцы на доткомах заработали и неплохо.
Разве рядовые граждане заработали? Или все же финансовые институты?
ICO это не "новая экономика" — это обычный передел рынка, на волне хайпа доверчивое население вложиться туда, а не в низкорисковый депозит/квартиру/машину, и прогорит. Что навредит и существющему укладу, т.к. системообразующие финансовые структуры потеряют оборот, а этот потерянный оборот уйдет из страны на потерянных ICO.
Развиваться и меняться надо, но не думаю, что ICO это тот самый интсрумент.
Я не юрист, не финансист, а обычнй программист, но даже для меня ICO выглядит очередным "пузырем". "Крах доткомов" уже забыли? Те же слова были — "прогресс", "новая экономика" и тп. Даже краудфайндинг пару лет назад — захайпили, получили пару "лазерных бритв" на kickstarter и "успокоилось".
Как по мне это довольно правильное решение "пока подождать, а дальше посмотрим". Там же не тупые люди в минфине сидят, а в наших реалиях запилить МММ на ICO думаю не сложно.
Года 4 назад перешли с SVN на GIT. Знающие ребята все твердили о важности консоли и о проблемах GUI. Через полгода перевел продукт на другую модель ветвления(сильно проще), и как-то надобность в консоли совсем отпала. За последние 3 года git-консоль использовал только в билд скриптах. Intellij IDEA за 4 года хорошо добавила в VCS функционале (правда до сих пор нет сквоша одной кнопкой), она же позволяет пользоваться шорткатами и в 90% действительно не трогать мыш при коммите, пуше, создании бранча и других "типичных" операциях. Но самое главное для меня это богоподный DIFF от IDE. Кто бы и что не говорил, но проверить 30+ файлов перед коммитом в GUI намного проще, чем в самой навороченной консоле.
Выше был пример "создал ветку fix-foo, а надо закоммитить fix-bug-123-dialog" — у меня все ветки создаются из Jira и потом в Bitbucket потом мержаться со сквошем через PR. Зачем создавать ветку руками, с именем, оторванным от предметной задачи?
Нормальный путь нормального человека без специализированного образования в управлении проектными командами. Отлично пишите, правильные выводы делаете. Не ведитесь на тролей и продолжайте развиваться!
Насчет PMBook: будьте предельно аккуратны с этими знаниями, т.к. они загоняют вас в рамки. В IT управлении действительно больше общего с "управлением" чем с "IT", но современные IT продукты создаются сильно по-другому. Тот же PMBook был написан для девелоперов(застройщиков) и хотя его адаптировали в IT очень грамотные люди, но построить здание и создать "современный" програмный продукт, на мой взгляд сильно разные вещи. Почему? У большинства "современного" it-бизнеса часто проблема с однозначной идентификацией бизнес цели. Каким бы вы не были богом менеджмента, с плавающей бизнес-целью предприятия вам не справится самому, темболее на уровне управления проектных команд. PMBook же довольно сильно опирается на стабильность этой самой первичной бизнес-цели. Сведеющие в этой теме, поправьте меня, пожалуйста, ибо читал его уже года 4 назад.
Настройте процессы работы в отделе. При этом максимально их задокументируйте.
Продумайте систему обучения сотрудников.
Настройте правильную систему делегирования различного рода заданий и лишь направляйте и контролируйте их выполнение.
Вступайте в диалог в любой непонятной ситуации. В споре рождается истина. Лишь так вы поймете людей и получите подтверждение, что они понимают вас.
Согласно моему опыту этот список это скорее ряд ошибок, а не полезных практик:
Настройте процессы работы в отделе. При этом максимально их задокументируйте.
Тут возможнвы два случая:
наиболее вероятно вы стали лидом в существующей коменде. Она ведь как-то работает? и работала. не нужно насаждать "процессы всегда и везде" т.к. получите запредельный уровень сопротивления. Работайте как консультант — присматривайтесь, вносите предложения на рассмотрение самой команде, если они отторгают, значит не понимают зачем это надо, что является вашей проблемой, а не команды. Если вы начинаете документировать процесс, то либо у вас большая текучка и это действительно имеет смысл, либо ваши процессы не очевидны и уложить их в голове 3-4 принципами и 2-3 практивкам невозможно, опять же — вы перегибаете палку с формализмом.
менее вероятно, что новичка поставили в новую команду к незнакомым ему людям. тут надо не настраивать процессы, а создать и сполить команду хоть как-то выполняя задачи. Периоды Forming и Storming никто не отменял.
Продумайте систему обучения сотрудников.
забавно, что пункт этот второй, а не последний. Помните, что половина ваших сотрудников "ходит протирать штаны до обеда", даже заявляя благие намерения. Если человек не хочет учиться — не надо, если человек хочет учиться — сам научится. Общие рекоммендации по "ты дорастешь до этого уровня и получишь прибавку" вам выдаст сама компания и вам не надо это создавать с ноля. Помните, что все люди разные, у всех разные жизеннные цели и разные цели в компании.
Настройте правильную систему делегирования различного рода заданий и лишь направляйте и контролируйте их выполнение.
вот он, тот пункт, над которым можно и нужно работать бесконечно. самый сложный и самый важный для вас как лида. Только делегируя вы начнете использовать ваше время во благо компании, а не попусту. Читайте про "7 уровней делигирования" и тп модели. "Правильная система делегирования" это вода, вы должны ставить куда более четкие цели, например: 40% критических задач, которыми раньше занимался только я теперь должны делать другие люди. Цель "Учитесь искать метрики и измерять ваши результаты" мне в своё время помогла куда больше, чем что либо еще. И самое главное "правильного делегирования" нет и не будет. Есть то, что работает лично у вас с вышей командой.
Вступайте в диалог в любой непонятной ситуации. В споре рождается истина. Лишь так вы поймете людей и получите подтверждение, что они понимают вас.
Кажется, что очень правильный совет, но дьявол в деталях. Именно с такой идеей я подходил к решению всех возможных не понятных ситуаций и только спустя пару лет осознал, что стал "митинг манагером", проводящий по 3-4 часа в день в митинг румах. Многие проблемы могут решиться и без вас, не реигруйте на все сразу — у вас нет столько времени. Дайте проблемам немного настояться, чтобы появилось четкое понимание их причин. Давайте возможность людям самим решать свои конфликты и подключайтесь только на 2-3 уровене эскалации. Проблема пришла сверху? Не надо звать в митинг рум ваших менеджеров/команду и искать решение. Подумайте, посторайтесь сами принять какое-то решение и поделитесь своим видением с менеджментом тем же емейлом, с подписью "я бы рекомендовал личную/skype встречу для уточнения деталей" на первое время. Помогайте вашему руководству, а не отнимайте у него время.
Не забывайте — вы Лид и вы берете на себя ответственность. Не дайте ответственности вас сожрать и не впадайте от страха в состояние контроля всего и вся — это раздражает людей и вы потратите много ненужного времени. Ваша задача состоит в том, чтобы ваши люди работали продуктивно, а не "максимально продуктивно". То же касается и вас.
В Kanban, в его космическом варианте, выполненная задача не ждёт выполнения остальных задач для её релиза, она сразу идёт релизится.
Никакого космоса, это вполне реально. На мой взгляд, все сводится к двум вещам: как сделать задачку поменьше и как выкатить её побыстрее. Первое достигается по большей части планированием — можно ведь
выкатить форму из 10 полей, а не из 20, без умной геолокации и подсказок при вводе. Тут скорее вопрос в том, готов ли ваш менеджмент продавать настолько быстро меняющийся продукт. Второе чисто техническая задача и решается она "инженерными подходами":
SRP и модульность (ака "микросервисы"): понижает связность кода, позволяя разделять ужас на более мелкие ужасы вашей реализации. В результате измнения в одном маленьком модуле технически не влияют на другие
TDD/BDD — позволяет создавать ТОЛЬКО то, что нужно, без излишеств, не тратя время по-напрасну
хороший уровень авто-тестов — не только про регрессию, имея хороший уровень модульности можно не напрягаясь гонять тесты параллельно среди модулей
быстрый CI — позволяет деплоить задачу по клику мышки (мы пока до деплоя по коммиту не дошли) и не думать о том как там все устроено и какой опять конфиг надо править
Ко всему этому можно прийти, тут ничего сложного. Как? Я в своё время это очень просто объяснял коллегам: теперь в нашем Definition of Done десятым пунктом стоит "prod deploy" и "prod test" — с таким подходом все стали искать возможности выкатываться максимально быстро, стали делить задачи на куски, уходить от зависимостей, лучше понимать значение "Lean философия". Сейчас каждый релизит свою задачу самостоятельно, когда посчитает нужным.
Тут главное, что Kanban далеко не всем нужен, и то, как работает команда исполнителей, должно быть продиктовано условиями сверху, со стороны бизнеса, а не снизу, со стороны самих исполнителей.
Вы не корректно используете терминологию.
Waterfall не методолгия, это не фреймворк и не best-practice. Это МОДЕЛЬ. https://en.wikipedia.org/wiki/Waterfall_model
Почитайте Ройса или вот маленькая цитата из той же вики:
Royce presented this model as an example of a flawed, non-working model;
Сравнивать "Waterfall" и всякие Agile/Rup/whatever нас научили продавцы этих фреймворков/методологий — консультаты, тренера и иже с ними.
Не вводите себя и других в заблуждение.
После 3-го прочтения, я кажется понял, что не так — возникла путаница в терминологии. Больщинство проблем, что вы описали, относятся к наивной реализации Singleton.getInstance(), которая действительно увеличивает связность и тп. Но это лишь одна из реализация синглтона, ниже вы указываете, что тот же IoC фреймворк создает тоже объект-Singleton, и логика инициализации вынесена из самого объекта. Озаглавливать это "синглтон нарушает SRP", как то не правильно. Наиваня реализация "нарушает" — согласен.
Помещая бизнес-логику в объект модели мы добавляем в него, помимо основной ответственности — хранения данных, дополнительные ответственности связанные с обработкой этих данных. Как правило при таком подходе в объекте модели скапливается большая часть операций, которые можно выполнить с этим объектом. Что является многократным нарушением SRP.
Я бы не тверждал это с такой уверенностью. Хотя на сегодня паттерн Repository (https://msdn.microsoft.com/en-us/library/ff649690.aspx) и является нормой по мнению больниства, существует и Active Record (https://en.wikipedia.org/wiki/Active_record_pattern), активно используемый, даже не смотря на критику по SRP. Тот же Repository страдает от того, что объекты не вляются объектами а лишь структурами, в результате чего нарушаются принципы самого ООП. Что лучше нарушать SRP или Объектный подход это вопрос. О преимуществах Active Record можете посмотреть холиварный доклад на JPoint 2016 https://www.youtube.com/watch?v=ckjAWXJWZEY и комментарий Алименкова, сравнивающий два подхода (https://youtu.be/ckjAWXJWZEY?t=1943) довольно наглядно.
Есть не только курсы. Практика учит гораздо быстрее.
Попробуйте придумать себе свой "стартап", только не фреймворк, а именно продукт, лучше маленький.
И пишите его. Пишите, деплойте, бэкапьте и за полгода уже и какое-никакое понимание "где задеплоить чтобы работало", какой-то опыт с "купить своё облако" (дада, именно купить и платить за него, иначе не тот опыт), разработка от и до своего продукта, неплохо поймете какой-то язык. Если перестроится на мышление "выкатить продукт", а не "написать качественный код", то каждая третья компания вам будет очень рада и вам там будет хорошо (большинство, к сожалению, берет джунов по принципу "надо чтобы ты это написал", а не "надо чтобы ты умел учиться и хотел выпустить продукт").
С такими навыками я бы стартера/джуна забрал к себе без разговоров, особенно, ктогда можно что-то запустить/открыть во время собеседования.
Писал 7 лет на 1С. 6 лет назад ушел на Java.
Полгода на переход и немного везения, что в меня поверили.
Для меня путь был очевиден: Java backend через базы и SQL. По дороге было пару лет менеджмента, в связи с отвутсвующими скилами по самоорганизации большинства разрабов), но до своей цели я добрался.
Хочу дать пару советов и мыслей, может помогут:
Не забывайте ваши сильные стороны:
способен проанализировать и написать бизнес-логику любой сложности
способен работать сам
способен взять задачу в виде "вон там 3 новые статьи налогово кодекса — делай"
Вы неплохо умеете проэктировать нормализованные базы и писать сложные аналитические запросы
всю свою карьеру писали прикладной код, отсюда должно быть и нормальное понимание базовых алгоритмов
С этим всем проблемы у современных разрабов и часто очень серьозные.
Конечно есть и ряд минусов, при переходе:
вы дно в ООП. 3-4 года Java каждый день и всеравно код выглядит донными отложениями. Чтение книг помогает с большой задержкой — мозг не туда повернут, нужно время и опыт.
мириады различных фрейморков, баз и тулов будут взрывать мозг, ибо не привычно — 1С то конечен (по крайней мере для меня 6 лет назад)
"через 3 года сеньор" для меня эта фраза является трешем. с моими 6-ю годами я себя разве что мидлом могу назвать, и то не во всех областях. В "этом" мире намного больше людей втречаются, которые знают настолько больше тебя, что ты сам даже осознать этого не способен.
Спасибо за статью.
То ли я чего-то не понял в П7, то ли совсем не согласен.
Вот типовой пример при работе с репозиторием:
Если dbVendor.UnknownIdException не превратить в myService.ClientNotExistsException, то вы нарушите не только инкапсуляцию, но и ваш сервисный слой потеряет всякий смысл и АПИ слой будет напрямую зависеть от репозитария.
Важно помнить, что "интеграция" ( в общем как и всякий другой выбор) имеет под собой trade-off. Да, писать и поддерживать интеграции требует существенных затрат, но это позваляет описывать контракты для взаимодействия разных систем. Как следствие, с этими контрактами можно говорить о понижении связности, и как следствие возмоности независимой эволюции систем, ситгерированных таким способом.
Обычно, далеко не все системы обновляются или измениются регулярно. Меняются же те, где бизнес пытается выделиться на рынке. Как следствие, если "корневая" или "центральная" модель поменяется, прийдётся обновлять и те системы, которые трогать бы не хотелось.
Корректно спроектированные интеграции позволяют разным бизнес областям эволюционировать более независимо.
Не только поддержка хороша для Канбана.
Если совсем на пальцах, то отличия два — отсутвие спринтов и ограничение на количество одновременно выполняемой работы. Можно вольно перефразировать — первоочередная задача заканчивать работу, доводить её до конца.
Канбан прекрасно работает в R&D отделах на исследовательских задачах. Если задачи ставить в формате "у тебя две недели на эту задачу" без точного описания конечного результата (но с описанием MVP), то работает еще лучше, т.к. работа ДОДЕЛЫВАЕТСЯ и уходит в эксплуатацию.
Стартапы при должном менеджменте можно рассматривать тоже как R$D отделы, что показывает мой опыт. В результате вы пилите маленькие кусочки пару раз в неделю и релизитесь, получая отзыв от CEO/PM и меняя приоритеты 1-20 раз в неделю. Но самое главное, подчеркну — задачи ДОДЕЛЫВАЮТСЯ, пусть не до идеального состояния, но до рабочего, и уходят в эксплуатацию, а не висят неделями из-за смены приоритетов!
Я ничего лично против Вас не имею, но к финансистам отношусь настороженно: Вы хотите получить новый высокодоходный финансовый инструмент и Ваша задача его продать населению как "супер-доходный и без рисков". После доткомов, кикстертеров и МММов доверие к "новым экономикам", как минимум, утрачено.
Соглашусь с Вами, что лучше хоть как-то начать регулировать, а не говорить "лучше не пользуйтесь", но как по мне, лучше это добро прикрывать, тем более для нашего доверчивого населения.
Разве рядовые граждане заработали? Или все же финансовые институты?
ICO это не "новая экономика" — это обычный передел рынка, на волне хайпа доверчивое население вложиться туда, а не в низкорисковый депозит/квартиру/машину, и прогорит. Что навредит и существющему укладу, т.к. системообразующие финансовые структуры потеряют оборот, а этот потерянный оборот уйдет из страны на потерянных ICO.
Развиваться и меняться надо, но не думаю, что ICO это тот самый интсрумент.
Я не юрист, не финансист, а обычнй программист, но даже для меня ICO выглядит очередным "пузырем". "Крах доткомов" уже забыли? Те же слова были — "прогресс", "новая экономика" и тп. Даже краудфайндинг пару лет назад — захайпили, получили пару "лазерных бритв" на kickstarter и "успокоилось".
Как по мне это довольно правильное решение "пока подождать, а дальше посмотрим". Там же не тупые люди в минфине сидят, а в наших реалиях запилить МММ на ICO думаю не сложно.
Года 4 назад перешли с SVN на GIT. Знающие ребята все твердили о важности консоли и о проблемах GUI. Через полгода перевел продукт на другую модель ветвления(сильно проще), и как-то надобность в консоли совсем отпала. За последние 3 года git-консоль использовал только в билд скриптах. Intellij IDEA за 4 года хорошо добавила в VCS функционале (правда до сих пор нет сквоша одной кнопкой), она же позволяет пользоваться шорткатами и в 90% действительно не трогать мыш при коммите, пуше, создании бранча и других "типичных" операциях. Но самое главное для меня это богоподный DIFF от IDE. Кто бы и что не говорил, но проверить 30+ файлов перед коммитом в GUI намного проще, чем в самой навороченной консоле.
Выше был пример "создал ветку fix-foo, а надо закоммитить fix-bug-123-dialog" — у меня все ветки создаются из Jira и потом в Bitbucket потом мержаться со сквошем через PR. Зачем создавать ветку руками, с именем, оторванным от предметной задачи?
В Intellij IDEA, например, интеграция с GIT много шире, чем просто комманды. Та же история доступна не только списокм с разными фильтрами, но интегрирована прямо в класс через "Annotations": https://plugins.jetbrains.com/plugin/8514-vcs-annotations-preloader
Нормальный путь нормального человека без специализированного образования в управлении проектными командами. Отлично пишите, правильные выводы делаете. Не ведитесь на тролей и продолжайте развиваться!
Насчет PMBook: будьте предельно аккуратны с этими знаниями, т.к. они загоняют вас в рамки. В IT управлении действительно больше общего с "управлением" чем с "IT", но современные IT продукты создаются сильно по-другому. Тот же PMBook был написан для девелоперов(застройщиков) и хотя его адаптировали в IT очень грамотные люди, но построить здание и создать "современный" програмный продукт, на мой взгляд сильно разные вещи. Почему? У большинства "современного" it-бизнеса часто проблема с однозначной идентификацией бизнес цели. Каким бы вы не были богом менеджмента, с плавающей бизнес-целью предприятия вам не справится самому, темболее на уровне управления проектных команд. PMBook же довольно сильно опирается на стабильность этой самой первичной бизнес-цели. Сведеющие в этой теме, поправьте меня, пожалуйста, ибо читал его уже года 4 назад.
Согласно моему опыту этот список это скорее ряд ошибок, а не полезных практик:
Тут возможнвы два случая:
забавно, что пункт этот второй, а не последний. Помните, что половина ваших сотрудников "ходит протирать штаны до обеда", даже заявляя благие намерения. Если человек не хочет учиться — не надо, если человек хочет учиться — сам научится. Общие рекоммендации по "ты дорастешь до этого уровня и получишь прибавку" вам выдаст сама компания и вам не надо это создавать с ноля. Помните, что все люди разные, у всех разные жизеннные цели и разные цели в компании.
вот он, тот пункт, над которым можно и нужно работать бесконечно. самый сложный и самый важный для вас как лида. Только делегируя вы начнете использовать ваше время во благо компании, а не попусту. Читайте про "7 уровней делигирования" и тп модели. "Правильная система делегирования" это вода, вы должны ставить куда более четкие цели, например: 40% критических задач, которыми раньше занимался только я теперь должны делать другие люди. Цель "Учитесь искать метрики и измерять ваши результаты" мне в своё время помогла куда больше, чем что либо еще. И самое главное "правильного делегирования" нет и не будет. Есть то, что работает лично у вас с вышей командой.
Кажется, что очень правильный совет, но дьявол в деталях. Именно с такой идеей я подходил к решению всех возможных не понятных ситуаций и только спустя пару лет осознал, что стал "митинг манагером", проводящий по 3-4 часа в день в митинг румах. Многие проблемы могут решиться и без вас, не реигруйте на все сразу — у вас нет столько времени. Дайте проблемам немного настояться, чтобы появилось четкое понимание их причин. Давайте возможность людям самим решать свои конфликты и подключайтесь только на 2-3 уровене эскалации. Проблема пришла сверху? Не надо звать в митинг рум ваших менеджеров/команду и искать решение. Подумайте, посторайтесь сами принять какое-то решение и поделитесь своим видением с менеджментом тем же емейлом, с подписью "я бы рекомендовал личную/skype встречу для уточнения деталей" на первое время. Помогайте вашему руководству, а не отнимайте у него время.
Не забывайте — вы Лид и вы берете на себя ответственность. Не дайте ответственности вас сожрать и не впадайте от страха в состояние контроля всего и вся — это раздражает людей и вы потратите много ненужного времени. Ваша задача состоит в том, чтобы ваши люди работали продуктивно, а не "максимально продуктивно". То же касается и вас.
Никакого космоса, это вполне реально. На мой взгляд, все сводится к двум вещам: как сделать задачку поменьше и как выкатить её побыстрее. Первое достигается по большей части планированием — можно ведь
выкатить форму из 10 полей, а не из 20, без умной геолокации и подсказок при вводе. Тут скорее вопрос в том, готов ли ваш менеджмент продавать настолько быстро меняющийся продукт. Второе чисто техническая задача и решается она "инженерными подходами":
Ко всему этому можно прийти, тут ничего сложного. Как? Я в своё время это очень просто объяснял коллегам: теперь в нашем Definition of Done десятым пунктом стоит "prod deploy" и "prod test" — с таким подходом все стали искать возможности выкатываться максимально быстро, стали делить задачи на куски, уходить от зависимостей, лучше понимать значение "Lean философия". Сейчас каждый релизит свою задачу самостоятельно, когда посчитает нужным.
Тут главное, что Kanban далеко не всем нужен, и то, как работает команда исполнителей, должно быть продиктовано условиями сверху, со стороны бизнеса, а не снизу, со стороны самих исполнителей.
Вы не корректно используете терминологию.
Waterfall не методолгия, это не фреймворк и не best-practice. Это МОДЕЛЬ. https://en.wikipedia.org/wiki/Waterfall_model
Почитайте Ройса или вот маленькая цитата из той же вики:
Сравнивать "Waterfall" и всякие Agile/Rup/whatever нас научили продавцы этих фреймворков/методологий — консультаты, тренера и иже с ними.
Не вводите себя и других в заблуждение.
После 3-го прочтения, я кажется понял, что не так — возникла путаница в терминологии. Больщинство проблем, что вы описали, относятся к наивной реализации Singleton.getInstance(), которая действительно увеличивает связность и тп. Но это лишь одна из реализация синглтона, ниже вы указываете, что тот же IoC фреймворк создает тоже объект-Singleton, и логика инициализации вынесена из самого объекта. Озаглавливать это "синглтон нарушает SRP", как то не правильно. Наиваня реализация "нарушает" — согласен.
Я бы не тверждал это с такой уверенностью. Хотя на сегодня паттерн Repository (https://msdn.microsoft.com/en-us/library/ff649690.aspx) и является нормой по мнению больниства, существует и Active Record (https://en.wikipedia.org/wiki/Active_record_pattern), активно используемый, даже не смотря на критику по SRP. Тот же Repository страдает от того, что объекты не вляются объектами а лишь структурами, в результате чего нарушаются принципы самого ООП. Что лучше нарушать SRP или Объектный подход это вопрос. О преимуществах Active Record можете посмотреть холиварный доклад на JPoint 2016 https://www.youtube.com/watch?v=ckjAWXJWZEY и комментарий Алименкова, сравнивающий два подхода (https://youtu.be/ckjAWXJWZEY?t=1943) довольно наглядно.
Есть не только курсы. Практика учит гораздо быстрее.
Попробуйте придумать себе свой "стартап", только не фреймворк, а именно продукт, лучше маленький.
И пишите его. Пишите, деплойте, бэкапьте и за полгода уже и какое-никакое понимание "где задеплоить чтобы работало", какой-то опыт с "купить своё облако" (дада, именно купить и платить за него, иначе не тот опыт), разработка от и до своего продукта, неплохо поймете какой-то язык. Если перестроится на мышление "выкатить продукт", а не "написать качественный код", то каждая третья компания вам будет очень рада и вам там будет хорошо (большинство, к сожалению, берет джунов по принципу "надо чтобы ты это написал", а не "надо чтобы ты умел учиться и хотел выпустить продукт").
С такими навыками я бы стартера/джуна забрал к себе без разговоров, особенно, ктогда можно что-то запустить/открыть во время собеседования.
Писал 7 лет на 1С. 6 лет назад ушел на Java.
Полгода на переход и немного везения, что в меня поверили.
Для меня путь был очевиден: Java backend через базы и SQL. По дороге было пару лет менеджмента, в связи с отвутсвующими скилами по самоорганизации большинства разрабов), но до своей цели я добрался.
Хочу дать пару советов и мыслей, может помогут:
Не забывайте ваши сильные стороны:
С этим всем проблемы у современных разрабов и часто очень серьозные.
Конечно есть и ряд минусов, при переходе: