За 9 лет разработки ПО  я периодически выступал в  роли ментора и сталкивался с проблемой, которую недавно озвучил начинающий программист после онлайн-курсов: 

«Не понимаю, как делить код на классы».

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

Я показал студенту несколько готовых шаблонов классов, чтобы он мог сразу применить, и хотел дать методичку по теории, но под рукой не оказалось ни заметок, ни статей, ни книг. Поиск в интернете и запросы к ИИ выдавали только материалы по ООП и принципам SOLID, которые мало касались нужной темы. Выходило так, что вся нужная для такой методички информация, лежит у меня в голове.  

Так и родилась идея написать эту статью.

Выпустить продолжение культовой игры - нереально сложная задача. А разработка Disciples III была ещё осложнена банкротством канадской студии-разработчика культовой второй части.

Релиз был неудачным... настолько неудачным, что российская студия-разработки забрала игру на глобальный ремастеринг практически сразу же после релиза оригинала. И спустя 3 года вышла Disciples III: Reincarnation.

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

И вот, спустя 13 лет вышел El Clasico мод, призванный сделать из игры ту самую Disciples, достойного последователя культовой второй части.

Как часто оценка по задаче совпадает с реальными трудозатратами?

Умение точно оценить объём работ спасает от переработок, напряжённой обстановки на проекте, поддерживает доверительные отношения в команде и показывает вас с хорошей стороны перед заказчиком.

Но интуитивные и ставшие традиционными способы оценки задач дают низкую точность. Пора взять на вооружение другой способ, дающий 90+% точность в оценке.

Так почему же Contract First оказался не так хорош на практике?

Это связано с тем, что в теории Contract First не учитывает необходимость постоянных доработок контракта и коммуникации между командами. Основная проблема кроется не в инструментах, а в процессах разработки API: если они выстроены плохо, коммуникация нарушается. Именно процессы — а не недостаток компетенций или инструментов — являются источником проблем.

К сожалению, баги - это неотъемлемая часть процесса разработки программного обеспечения. Но я обратил внимание, что одни команды допускают значительно меньше багов, чем другие.

Почему так происходит? - задался я вопросом.

Простой и декларативный способ выполнять SQL запросы в JUnit тестах.

Я сидел в незнакомой комнате. Передо мной было двое. Имена - единственное, что я знал о них. В комнате был ещё один человек. Он сидел по левую руку от меня. Когда он говорил, мне приходилось разворачиваться на стуле, чтобы увидеть его лицо. В это время двое незнакомцев оказывались за пределами моего взгляда. Они задавали много вопросов о моём опыте, о моих знаниях. Они давали мне одну задачу за другой, которые я должен был решить без какой-либо подготовки. Другими словами:

они оценивали меня.

Автоматизация процессов разработки и тестирования программного обеспечения (ПО) — лучший способ уйти от рутины и заняться действительно интересными задачами. Азарт от реализации новой функции может быть погребен под рутиной сборки, подготовкой и выпуска нового релиза. Как избежать этой неизбежной скучной задачи, но выпустить релиз ПО, не упустив при этом ни одной мелочи при его подготовке?

Выпуск релиза ПО — это не только сборка ПО в определённого формата пакет и отправка пакета на место его установки. Зачастую выпуск релиза включает в себя множество других задач, таких как: