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

## Парадигма и инструменты языка

Я несколько раз встречал мнение, что го не ООП-язык. И поэтому прежде всего договоримся о том, что такое ООП.

ООП как парадигма — это идея оформить код таким образом, чтобы он отражал в себе образы, которыми мы мыслим. Если я пишу программу для живописи, то я буду объяснять её функционал словами: холст, кисть, цвет, закрашивать... Если эти же слова возникают в моём коде, то я использую ООП. Читая такой код, легко восстановить в голове смысл, который закладывался в программу. Так как в нашем мышлении присутствуют абстракции, для которых свойственны полиморфизм и сокрытие подробностей, то мы переносим их и в код.

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

2035 год. Мир больше не нуждается в тех, кто хочет просто войти в IT.

Всё началось с автоматизации простых задач. Сначала — тесты. Потом — верстка. Потом — интеграции, бэкенд, фронт, дизайн, продакт-решения. GPT-10 умел собирать целые MVP по описанию идеи в голосовом сообщении. Midjourney Designer Suite проектировал UI лучше, чем весь Dribbble вместе взятый. Запускать стартап стало делом десяти минут и кредитной карты.

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

У меня это бывает часто. Вообще на проверку всех моих гипотез нужно минимум человека 3-4. И вот, они появились! Правда это 3-4 нейросети, ну ок, пойдет)

Сегодня каждому предоставляется такая возможность...

Гибкость (agility) — это, без сомнения, полезная вещь, и Манифест Agile не выглядит необоснованным. В сравнении с устаревшей практикой, известной как «Waterfall», Agile безусловно имеет свои преимущества. Тем не менее, многие аспекты Agile на практике оказываются весьма вредными, и я не считаю, что дихотомия «Agile/Waterfall» вообще является полезной концепцией.

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

Минцифры кричит о нехватке миллиона IT-специалистов, министр труда и социальной защиты заявляет о «всего» ста тысячах. Параллельно рынок труда захлестнула волна сокращений. А тут ещё и слухи об AGI — суперумном ИИ, который захватит все рабочие места. Парадокс? Нет, скорее болезненная трансформация от иллюзий к реальности. 

На связи CEO Surf Владимир Макеев. Я в разработке с 2011 года, почти с самых истоков развития мобильных приложений в РФ. Сегодня поделюсь своим взглядом на то, как накопленный кризис управленческих иллюзий повлиял на IT-сферу и почему за последний год уволили так много специалистов. И как на ситуацию влияет развитие ИИ, который может заменить разработчиков.

Привет, Хабр! Я Никита Иванов, техлид команды «Видео» в KION. В ИТ я уже девять лет, а последние пять работаю с Go. Сегодня расскажу, какую задачу считаю идеальной для собеседования на позицию Go-разработчика. Этот текст — переработка моего доклада с митапа МТС True Tech Go, видеоверсию можно посмотреть тут.

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

Если вы уже в команде, будь вы Middle или Senior разработчик — значит, ваши технические навыки уже на уровне. Они проверены и подтверждены на этапе найма или в процессе работы. Люди без подтвержденных хардов просто не попадают в продуктовые команды. 

Технические навыки — база, но в действительности ваш успех не в меньшей степени зависит от прокаченных софтов.

В этой статье разберём как развить софты и почему — это не просто дополнение к вашим хардам, но и важный инструмент в построении карьеры.

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

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

Прокаченные soft skills помогают успешно проходить собеседования, выстраивать эффективные процессы, подниматься по карьерной лестнице. В этой статье рассказываем, на какие мягкие навыки обратить особое внимание IT-специалистам, что делать, чтобы их развить и как отсутствие софтов может стать преградой на пути к карьерному росту.

Что такое личная эффективность технического директора? Где проходит грань между «хорошо для бизнеса» и «хорошо для себя»? Как при этом не утонуть в бесконечных задачах и успевать развивать людей?

На круглом столе «Личная эффективность СТО» в рамках конференции CTO Conf X 2025 топовые технические лидеры обсудили, что помогает оставаться в строю, а что тянет вниз.

В обсуждении участвовали:
– Владимир Шульга (Cloud.Ru)
– Артём Елизаров (CTO розничной сети МТС)
– Иван Поддубный (CTO Вебпрактик)
– Александр Серпичев (Axenix)

Разговор получился живым, откровенным и очень практичным. Давайте разберём ключевые тезисы.

Разберемся с сигналами от ОС, поработаем с таймаутами и контекстом в нашем HTTP сервере и шаг за шагом сделаем Graceful Shutdown в Go приложении.

Представь, Бро. У тебя в команде есть один человек, который держит в голове все тонкости проекта. Архитектура - его. Сборки - его. Логика в бекенде, деплой, связи между модулями - тоже он. Всё работает идеально, пока он рядом. Но стоит ему уйти в отпуск, заболеть или, как говорится, попасть под автобус - и всё, команда в ауте, сроки летят, клиенты в шоке.

Это и есть тот самый bus-фактор. В этой статье разберём, почему это не круто, как он возникает, почему так распространён, и главное - как его снизить. Поделюсь личными кейсами, проверенными практиками и нетривиальными приёмами, которые реально работают. Без воды, честно и с примерами из боевого менеджмента.

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

Эта статья посвящена тому, как распределять задачи между конвейерами очередей, чтобы минимизировать общее время обработки, а также неожиданной связи между этим методом планирования и методом Томаса Джефферсона.

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

- bool LoadAnimation(str::string filename);
- void DrawLines(std::vector path);
- Matrix RotateObject(Matrix m, Angle angle);
- int DrawSprite(Sprite sprite);

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

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

Все самые важные и интересные финансовые новости в России и мире за неделю: Дуров готов сливать ваши данные органам, 26 льготных ипотек на человека, бескупонная облигация Сбера для гуманитариев, законы о пропаганде чайлдфри и оскорблении чиновников, взлет китайских акций, а также захват онлайн-покеррумов нёрдами из Омска.

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

Статья навеяна вот этой статьей на Хабре: https://habr.com/ru/articles/846700/ (почему не надо оставлять честную обратную связь).

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

Руководителя винить здесь бесполезно: руководитель - не штатный психолог компании, он не папка (или не мамка) сотрудникам, который должен учить их жизни, лечить и помогать. Нет. Все, что надо руководителю – это выполнить цели компании, и чтобы команда не разбежалась после этого. Это все. Руководитель не отвечает за моральное и психологическое состояние сотрудников. Это ответственность самих сотрудников**

Но как правильно отвечать на давление? Как правильно и, как сейчас модно говорить, экологично отвечать, когда вы чувствуете, что вас используют, не предлагая ничего стоящего взамен?

Вот про это и предлагаю поговорить ниже.

Гильдии разработчиков становятся обычным явлением в IT-компаниях.  Это своего рода неформальные клубы по интересам, которые помогают улучшать процессы, обмениваться опытом и развивать участников. Потенциал таких сообществ весьма высок, — они могут запустить изменения на уровне всей компании. Но что делать, если активность в гильдии снизилась и стало непонятно, зачем она вообще нужна?

Меня зовут Саша Киверин, я лид Python-гильдии в Циан. Сейчас в нашем сообществе более 60 разработчиков. За последние 2 года мы совместными усилиями сделали целый ряд крутых проектов. Перевели монолит с версии Python 2.7 на 3.12, создали библиотеку для внешних вызовов и внедрили автоматический чеклист здоровья микросервиса. Дотащить все это до прода нам помогли 5 простых советов, которыми я и поделюсь в этой статье. Надеюсь, они помогут оживить и вашу гильдию.