Почти весь код туториалов, который мне попадался в открытом доступе, с точки зрения кодирования, написан на уровне junior-программиста, что вполне закономерно, ведь все Data Science и ML-инженеры, которых я знаю, в большей степени математики, а не программисты. И сложность их кода не только в языковых конструкциях и отсутствии хороших практик кодирования, но и в том, что он больше похож на математические выкладки и довольно тяжело читаем для людей, имеющих за плечами только институтский и школьный курс математики. И вся это сложность умножается на непростую теоретическую базу, поэтому если ты не знаком с теорией, то догадаться по коду, для чего нужны выполняемые действия, порой бывает просто решительно невозможно.

Я заинтересовался ML и AI в 2019 году, и с тех пор количество статей и примеров кода в Интернете выросло многократно, но одно, к сожалению, так и осталось неизменно — стиль кодирования примеров и их математичность.

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

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

Так родилась идея поделиться накопившимися за 10-летний стаж наблюдениями и плодами размышлений:

- Как стиль написания кода отражает образ мышления разработчика.

- Как разработчики воспринимают код программы.

- Почему один язык программирования, что называется, «заходит», а другой - нет.

Специалисты, поработавшие много лет в IT, иногда чем-то напоминают людей преклонного возраста, которые встретившись, начинают рассказывать о наболевшем.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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