На рубеже веков жизнь показала, что невозможно за счет тщательного планирования и проектирования системы проекта обеспечить разработку и успешное внедрение системы в предполагаемые сроки.

Как ответ на это родились Agile-методы, которые организовывают разработку принципиально иным образом: короткими итерациями, с регулярным получением обратной связи от заказчика и пользователей, для чего необходимо им представлять работоспособную версию продукта, которую они смогут оценить.

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

https://habr.com/ru/post/709912/?utm_source=habrahabr&utm_medium=rss&utm_campaign=709912

По мере того, как автоматизированные системы не просто заменяли бумажные документы, отражающие текущую деятельность, а брали на себя задачу их обработки, включая задачи по планированию и управлению, возрастала потребность в описании их внутреннего устройства, алгоритмов в виде, понятном для заказчиков и пользователей систем. Описание в виде черного ящика предполагало, что внутри творится магия, придуманная разработчиками. Но эта магия оказывалась вовсе не такой, на которую рассчитывал бизнес.

Решение — подход DDD, Domain Driven Design, было предложено Эриком Эвансом в 2003. Но прежде, чем о нем говорить, необходимо немного углубиться в историю развития разработки софта как такового.

https://habr.com/ru/post/705958/?utm_source=habrahabr&utm_medium=rss&utm_campaign=705958

Многие методологии требуют сначала описать требования к системе как черному ящику и лишь затем переходить к проектированию и построению моделей. Способам такого описания посвящена инженерия требований. Однако, это присуще и Agile-методам, ведь User Story тоже описывает систему как черный ящик. Целью такого подхода была гарантия, что разработанная система будет пригодна для использования, внедрение пройдет гладко. Проблема в том, что так — не работает. А значит, нет смысла чересчур углубляться в требования, а стоит быстро переходить к моделям системы, которые можно строить по-разному.

https://habr.com/ru/post/703758/?utm_source=habrahabr&utm_medium=rss&utm_campaign=703758

В EF Core много полезных фич по работе с базами данных, но что, если этих возможностей не хватает? Я был удивлен, когда узнал, что фреймворк из коробки не умеет создавать вьюшки и отслеживать изменения их исходного кода. А что, если нам нужны не только вьюшки, но еще и синонимы, гранты и DB link? При этом мы хотим видеть их как на производственной БД, так и в интеграционных тестах! В посте будет инфа про загадочный внутренний мир фреймворка: про ключевые интерфейсы, отвечающие за генерацию и применение миграций, про то, как можно подменить эти интерфейсы, и, самое главное, почему тут не поможет контейнер, создаваемый в Startup. Также поговорим про основные объекты EF Core: что такое модель и зачем нужен снепшот? Из чего состоит миграция и зачем нужно транслировать операции в SQL?

Пост будет интересен как тем разрабам, которые столкнулись с задачами создания и обновления вьюх, синонимов и других SQL-объектов (они узнают про наш пакет, позволяющий закрыть эти вопросы), так и тем, кто хочет написать свое расширение (они узнают про подмену сервисов). Если Вы хотите, чтобы мир EF Core стал для вас менее загадочным, но ничуть не менее интересным, добро пожаловать под кат.

https://habr.com/ru/post/699138/?utm_source=habrahabr&utm_medium=rss&utm_campaign=699138

Меня зовут Роман, я ведущий специалист по обеспечению качества ПО. Сегодня я поделюсь своим опытом наставничества. Этот рассказ не инструкция по применению, и здесь вы не получите конкретный алгоритм. Но это success-story для вдохновения, мой личный опыт и мысли, которые могут быть полезными, если вам представится возможность стать наставником.

https://habr.com/ru/post/692540/?utm_source=habrahabr&utm_medium=rss&utm_campaign=692540

Что чувствует ваш новый коллега в свой первый рабочий день? Он может испытывать целый букет эмоций, но одно можем сказать наверняка: у него много вопросов! Кого и как зовут, чем занимаются разные отделы, каковы принципы работы в компании. Как всё устроено?

Постепенно он сможет с этим разобраться, и такой процесс называют адаптацией. Она нужна каждому, кто оказался в новой команде, каким бы крутым специалистом он ни был.

https://habr.com/ru/post/688156/?utm_source=habrahabr&utm_medium=rss&utm_campaign=688156

Меня зовут Игорь, мне 34 года. Я разработчик и будущий летчик. Работаю в компании CUSTIS и при этом студент-первокурсник Якутского авиационного технического училища. Мой процесс поступления растянулся на три года, но я не потерял мотивацию, не сдался и всё же сумел доказать самому себе, что возможно всё — было бы желание!

В своей статье расскажу, как пришел в ИТ-сферу, как здесь развивался, почему внезапно принял решение снова пойти учиться, но совсем по другому профилю. А еще: как бесплатно получить профессию летчика, как выбрать, куда именно поступать и как подготовиться к экзаменам, а главное — как успевать совмещать всё это с разработкой программ?

https://habr.com/ru/post/679902/?utm_source=habrahabr&utm_medium=rss&utm_campaign=679902

Этот материал для тех, кто хочет эффективно погружаться в проекты большого масштаба и следить за состоянием их здоровья. В статье расскажу, как максимально быстро разобраться в стандарте OMG Essence и начать применять его в работе.

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

https://habr.com/ru/post/678436/?utm_source=habrahabr&utm_medium=rss&utm_campaign=678436

Этот материал для тех, кто хочет эффективно погружаться в проекты большого масштаба и следить за состоянием их здоровья. В статье расскажу, как максимально быстро разобраться в стандарте OMG Essence и начать применять его в работе.

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

https://habr.com/ru/post/677944/?utm_source=habrahabr&utm_medium=rss&utm_campaign=677944

Старт любого нашего проекта начинается с подготовки инфраструктуры. Времени на это порой уходит довольно много. Как минимум необходимо нарезать виртуалки или донастроить Kubernetes, настроить CI, базы данных, логирование, мониторинг и прочие компоненты. В лучшем случае в этих заботах проходит несколько дней, а ни строчки кода еще не написано. Знакомая ситуация?

https://habr.com/ru/post/662005/?utm_source=habrahabr&utm_medium=rss&utm_campaign=662005