Подход к задачам

• Разные задачи, проекты и команды требуют разных подходов. Например, сделать пейсмейкер без автоматических тестов было бы безответственным решением – кто-то может от этого пострадать. И вместе с тем, глупо изводиться по поводу автоматических тестов на геймджеме, куда вы отправились на выходных. Содержание понятия «хороший код» меняется в зависимости от контекста, и нужно адаптировать свой подход под конкретную ситуацию.
• Делайте марш-броски. Бывает, что я ставлю себе цель довести какую-то функциональность до готовности в кратчайшие сроки, пусть даже срезая углы где только можно, с кодом ужасного качества и TODO на каждом шагу. Когда у меня появится что-то рабочее, тогда и буду приводить всё в должный вид. Я пришел к выводу, что это хороший способ обозначить для себя проблемные зоны, а также неплохой путь к ускорению процесса разработки. На эту тему есть статья «Выбросьте первый набросок кода».
• Если я бьюсь головой об задачу и никак не могу сдвинуться с мертвой точки, значит, необходимо оторваться от нее на какое-то время.
• Прежде чем начать работу над сложной задачей, я задаю себе вопрос: «А что если вообще этого не делать?» Как правило, вопрос оказывается глупым и выполнять задачу все-таки приходится. Но примерно в пяти процентах случаев я осознаю, что определенную часть работы можно спокойно пропустить.

2024 год рисует жестокую кривую с объемом кандидатов в IT. Мы подровняли её и разобрались — кто, куда и зачем? Опубликовали пять вакансий на самые объемные специальности и анализируем полученные данные: как опытные специалисты выдавливают джунов, с чем сталкиваются новички и где у них есть шанс прорваться?

Привет! Мы работаем в Константе и занимаемся разработкой различных сервисов и систем, связанных с беттингом. Один из наших продуктов – платежный шлюз, он интегрируется с платежными системами и позволяет клиентам букмекера вносить и выводить деньги из личного кабинета. 

Это довольно молодой продукт – костяк команды формировался в течение последнего года. В какой-то момент мы подумали о том, что у нас есть ряд типовых интеграционных задач, на которых мы могли бы вырастить начинающих Golang-разработчиков. С одной стороны, стажировки – популярная сейчас история, и на рынке существует множество предложений, с которыми нам предстояло конкурировать за таланты; к тому же мы, как небольшая компания, не могли позволить себе выделить на этот проект большой бюджет и много человеческого ресурса. С другой стороны – нам очень хотелось попробовать.

Спойлер: в итоге стажировка была организована силами 2 HR и 3 человек из команды разработки. Помимо оплаты нашего времени и выплат стажерам, не было потрачено ни рубля дополнительно.

Всем известный закон Мёрфи гласит: «Если что-то плохое может случиться, то оно обязательно произойдет». Согласитесь, не самая позитивная установка, особенно когда это касается работы. И тут мне стало любопытно, а есть ли такие законы, которые мне, как ИТ-специалисту, максимально помогут избежать «чего-то плохого». К своему удивлению, я их нашел, и даже не один. Потому делюсь с вами сегодня своими сакральными знаниями в блоге ЛАНИТ. 

За два года с тех пор, как я опубликовал статью I want off Mr Golang's Wild Ride, она вновь и вновь всплывала на Reddit, Lobste.rs, на HackerNews и в других местах.

Всякий раз дискуссия выходит к одним и тем же ответам:

Как-то раз я сидел в баре с давним приятелем, с которым раньше мне довелось поработать на поза-поза-позапрошлой работе. Он из сомневающихся по поводу перехода на Go, ярый приверженец своего нынешнего языка. Хочу сказать, что он делает действительно классные вещи, пишет безупречный код, у него есть, чему поучиться. Но к Go у него отношение не слишком позитивное. Как он сказал: “Go — это *****код (плохой код)”. И в качестве одного из аргументов привел то, насколько, по его мнению, криво в Go реализована обработка ошибок. В чем-то он прав — в моем текущем не самом большом проекте на Go конструкция “if err != nil” встречается 1132 раза.

Этот мой приятель, не побоюсь этого слова — адепт DDD (domain driven design). Все, что не относится к DDD, — это, по его мнению, антипаттерн, ад и хаос. Когда я ему рассказал, что у меня есть довольно успешный опыт проектирования по DDD в Go-проектах, он округлил глаза. Да, ответил я, с определенной серией оговорок и компромиссов это работает, и неплохо.