Kurgan-Telecom Ru | Информационные технологии

Недавно наткнулся на статью о том, почему хорошие разработчики пишут плохой код в больших компаниях. Автор объяснял это высокой текучкой, тем, что большинство изменений вносят новички, а ветераны перегружены и не успевают передавать экспертизу. Меня эта статья зацепила, потому что я видел и другую картину в своей практике. Решил поделиться опытом: как в сравнительно небольшой ИТ-компании можно писать хороший код, когда собственник ратует за его качество.

Однажды фраза из к/ф "Человек с бульвара Капуцинов" навела меня на размышления о моем пути в ИТ-профессии. В отличие от Билли, мне повезло: я не просто встретил хороших людей, а прочитал умные книги, которые эти люди написали. Когда я вспоминаю годы, когда только становился программистом, отчётливо вижу те издания, которые заложили мой будущий фундамент. Это были не просто инструкции, а встречи с людьми, которые изменили мой взгляд на программирование и управление. Удивительно, насколько сильно несколько толковых книг могут повлиять на судьбу человека!

Refactoring Мартина Фаулера научил меня профессиональному отношению к коду и привычке доводить детали до совершенства. Не писать идеально с первого раза невозможно. Но постоянно улучшать, рефакторить, делать код чище и понятнее. Это не про перфекционизм, а про уважение к тем, кто будет читать этот код завтра. Фаулер однажды сказал: "I am not a good engineer, I am an engineer with good habits". Эта фраза стала для меня ключевой. Я понял, что хороший код это не про талант, а про привычки. Про то, что ты делаешь каждый день, даже когда никто не смотрит.

Хороший ли я программист? Если коротко — я не знаю, что это значит.

Вот я программирую уже 52 года, с 1973 года, спасибо урокам в государственной средней школе — тогда это было редкостью и не все школы давали подобную возможность. Я работал в 15 разных компаниях в самых разных отраслях. Болше скажу, я основал две небольшие софтверные компании — одну в 1985 году и вторую в 1987-м, и руководил ими до 1994 года. А потом я вышел на пенсию в 2021-м году.

Так что же, я хороший программист потому, что я в целом 52 года в отрасли и всё это время программирую?

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

Долговечность — это преимущество лишь в том смысле, что ты всё это время сумел оставаться ценным и востребованным, но это не обязательно значит, что ты хорош.

Всем привет. Меня зовут Вакорин Михаил и я работаю системным аналитиком в компании SENSE. Нередко ко мне обращаются более молодые коллеги: 

«Я джун и я хочу вырасти до сеньора. С чего мне начать, какие навыки нужно прокачивать, чтобы через несколько лет зарабатывать по 300 тысяч в месяц?»

В такие моменты я вспоминаю себя в их возрасте: куда пойти, чему учиться? К сожалению, я так и не встретил «доброго волшебника», который бы взял меня за руку на пути становления системным аналитиком, подсказал бы, какие книги читать и в какие hard skills вкладывать очки опыта в первую очередь. До многого приходилось доходить самому.

Но, как мне кажется, мне всё-таки повезло. Однажды, копаясь в интернете в поисках ответа на вопрос, что полезно знать системному аналитику (джуну и не только), я наткнулся на профессиональный стандарт 06.022 для системного аналитика. Его изучение, а также мой собственный опыт работы позволили сформулировать основные направления развития для начинающих аналитиков.

Для удобства я разделил их на hard skills и soft skills. Поехали!

Привет, Хабр! Меня зовут Алексей, я участвую в в разработке операционной системы для линейки коммутаторов KORNFELD в YADRO. Ранее я писал об организации L2-связности — она покрывает только часть потребностей, и рано или поздно требуется связать VXLAN-сегменты между собой или с внешними сетями. В этой статье рассмотрим варианты решения такой задачи. Все примеры беру из практики работы с KORNFELD, так как логика настройки и синтаксис схожи с популярными вендорами.

Проблема многих программ не в медленном процессоре, а в том, что они «забывчивы». Каждый раз, когда вы вызываете функцию с одними и теми же данными, она честно считает всё с нуля. Если внутри сложные расчеты или рекурсия — всё начинает тормозить.

Решение — Мемоизация.

Это техника, при которой функция запоминает результат своих вычислений. Если вы вызываете её снова с теми же аргументами, она не считает, а просто достает готовый ответ из памяти (словаря).

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

Берем интервью и лезем «под капот» к тем, кто задает вектор развития современных технологий в компании - к CTO.

Сегодня у нас в гостях человек с интересным бэкграундом: от разработки защищенных смартфонов на стыке «железа» и жестких гостандартов до управления современными ИТ-командами. Мы поговорили о том, каково делать продукт, когда 80% решений нельзя «загуглить», почему чиновники так и не оценили отечественные гаджеты и чем инженеры старой закалки круче современных «смузи-разработчиков». Погружаемся в мир реверс-инжиниринга, китайских заводов и суровой инженерной реальности.

Привет, Хабр!

В предыдущей статье мы рассказали, как установить Digital Q.DataBase на Astra Linux 1.8 и начать работу с этой российской СУБД, которая поддерживает нативную работу с диалектами MS SQL, PostgreSQL и Oracle. Сегодня мы поговорим о том, как перенести уже существующие данные в Digital Q.DataBase из других систем управления базами данных. 

Для решения поставленной задачи мы разработали инструмент – Мастер переноса БД. Он позволяет выгрузить структуру, данные и хранимую логику из уже развернутой БД на одной из трех СУБД (Oraсle, MS SQL и PostgreSQL) и загрузить их в Digital Q.DataBase без переписывания кода приложений в отличие от любых миграторов-конверторов.

Что делать, когда все корпоративные ИТ-системы, поддерживающие ежедневные операционные процессы, «полетели в трубу»? Как управлять такой масштабной программой восстановления всего ИТ-ландшафта, когда даже один день просрочки приводит к миллионным потерям?

Управлять по обычным правилам – не вариант. Важны высокая скорость работы и быстрое принятие решений. Никакого традиционного паспорта проекта, никакого талмуда с требованиями, реестра рисков, концепции, ТЭО и прочего. Максимальная упрощенка. Однако при такой скорости и упрощенном управлении… возникает большой риск что-то недосмотреть, упустить, что в итоге приведет к еще большим финансовым потерям.

Так как нужно управлять такой масштабной программой в форс-мажорных обстоятельствах, когда каждый день критически важен для бизнеса?

Рассказываю реальный кейс: как мы помогли клиенту выйти из ситуации глубокого кризиса и реализовать программу по восстановлению ключевых корпоративных ИТ-систем с минимальными потерями.

Проблема измерений

Узнав из Главы 2 об иерархии памяти, вы, возможно, захотите оптимизировать свой код. Но есть одна проблема: как понять, что оптимизация на самом деле сработала?

Этот урок дорого мне обошёлся.

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

Я запустил код. Мне показалось, что он быстрее. Я закоммитил изменения.

Неделю спустя коллега провёл бенчмарки и выяснил, что моя «оптимизация» замедлила код на 15%. Я оптимизировал не то, но у меня не было данных, чтобы подтвердить мои предположения.

Вывод: никогда не доверяйте своей интуиции, всегда проводите замеры.

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

В Veai 5.3 добавлены режимы работы агента (Modes), появился личный кабинет и возможность выбрать модель LLM для индивидуальных пользователей, отображение ИИ-текста стало более плавным и комфортным для восприятия.

Хабр, привет! Недавно завершилось ML-соревнование E-CUP 2025. Наша команда из X5 Tech заняла первое место в треке «Логистика: автопланирование курьеров», где было нужно оптимизировать время, затрачиваемое курьерами на доставку 20 000 заказов. В статье расскажем про подходы, которые использовали для решения этой задачи. Посмотрим, во сколько раз можно сжать JSON с матрицей расстояний. Какой код мы использовали для быстрого решения задачи TSP с помощью LKH-3. Обсудим, на что обращать внимание при кластеризации заказов.

Постановка задачи

Требовалось распределить порядка 20 000 заказов между 280 курьерами и построить для каждого из них маршрут так, чтобы минимизировать их суммарное время работы. Оно складывалось из времени перемещения курьеров между заказами и времени выполнения самих заказов (service time). За каждый невыполненный заказ добавлялся штраф 3000 секунд...

Нестеров Алексей Александрович, доцент, кандидат медицинских наук, зав. кафедрой стоматологии и челюстно-лицевой хирургии с курсом последипломного образования в АГМУ, эксперт компании Alpha-Bio Tec.

Проблема отсутствия зубов волновала человечество во все времена. Представители древних цивилизаций Междуречья, Египта, Южной Америки весьма искусно восстанавливали целостность зубного ряда умершим перед погребением, а также умели делать простые зубные протезы с креплениями из проволоки. Об этом говорят археологические находки в самых разных частях света. 

Что для вас хакатон? Тимбилдинг для разработчиков? Тусич с коллегами? Что-то айтишное? А что если хакатон — это вообще не про айтишку, а про... бизнес!?

Меня зовут Ануш Изян, я — внутриком в Dodo Engineering, а сегодня расскажу вам, как мы организовали хакатон для всей компании, позвав на него и IT, и бизнес, что из этого получилось и какие инсайты мы словили. Погнали!

Всем привет.

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

Уже нет сомнений в том, что искусственный интеллект позволяет оптимизировать и ускорить процесс разработки, помогая в написании и ревью кода. Но насколько полезен он может быть для задач в сфере инфраструктуры и девопс? 

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

В IntelliJ Idea (а, значит, и в OpenIDE) есть встроенный MCP-сервер. Активируется он достаточно просто и позволяет расширять стандартную функциональность command-line кодинговых агентов, таких как платный Claude Code или бесплатный, но тоже весьма неплохой Qwen Code. Преимущество CLI-агентов в том, что они работают с исходниками напрямую, держат контекст всего проекта и сами проверяют компилируемость кода. А MCP-сервер предоставляет такому агенту некоторую функциональность, которая обеспечивается средствами IDE. Поскольку IDE явно лучше заточена под работу с исходниками проекта, чем универсальные агенты, такие действия выполняются быстрее и точнее.

Я — системный аналитик. В моей жизни так повелось: чего боюсь, в то и попадаю. В начале своего пути столкнулась с проектом, где работали настоящие архитекторы решений. Глядя на них, я думала: «Они боги! Знают и понимают так много… ВАУ!». Они одновременно и привлекали, и пугали. С ними было легко, потому что они внушали доверие: нет нерешаемых задач, нужно просто подумать. И в то же время объёмно — от глубины их знаний захватывало дух.

Недавно мне раскрыли тайну: архитектор — это не тот, кто знает всё, а тот, кому доверяют построить систему для решения бизнес-задачи. И я поняла, что в начале пути меня привлекали их спокойствие и уверенность. Всё остальное — опыт, знание технологий — это hard skills, которые можно наработать. 

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

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

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

Особенно ценно это для компаний, работающих на устаревающих системах вроде «1С:Управление торговлей 10.3» и «1С:Альфа-Авто 5», где каждое новое требование регулятора превращается в технический вызов. Основываясь на собственном реальном опыте, историях и опыте наших ведущих партнёров-интеграторов, рассказываем, как пройти путь от ручного учёта «по бумажке» к автоматизированному контуру, совместимому с Честным ЗНАКом, без разрушения привычных бизнес-процессов.

Любая наука открыта к теориям, размышлениям и интерпретациям. Однако всегда существуют определенные законы, стандарты и нормы, которые являются постоянными и не обсуждаемыми. Особенно это проявляется в точных науках (физика, химия, математика и т. д.), от того и соответственное название. Точные измерения какого-либо параметра несут важнейшее значения не только в дальнейших расчетах, но и в последующем формировании теорий, физических опытах и создании чего-либо. Одним из самых ценных с точки зрения многих философий ресурсом является время, точное измерение которого крайне важно не только для многих расчетов различных отраслей, но и для работы многих устройств и систем. Эталоном измерения времени является ядерная хронометрия. Создания такого рода часов — это сложный и трудоемкий процесс, где малейшая ошибка приведет к неточной работе. Однако группа ученых из Калифорнийского университета в Лос-Анджелесе (США) обнаружили весьма простой и эффективный метод создания ядерных часов, который был вдохновлен старинной техникой ювелиров. В чем суть методики, как именно она была применена к ядерным часам, и насколько точными они были? Ответы на эти вопросы мы найдем в докладе ученых.