Posts List
Health
«Смерть» проприетарного софта: Эпоха Open Source в проектировании электроники. KiCad против Altium — выживет ли инженер?
Десятилетиями в мире проектирования печатных плат (PCB Design) существовала «золотая триада»: Altium Designer, Cadence Allegro и Mentor Graphics (ныне Siemens EDA). Эти монстры индустрии сформировали стандарты, вырастили поколения инженеров и создали экосистемы, которые казались незыблемыми. Однако события последних двух лет нанесли по этой архитектуре сокрушительный удар. Уход проприетарных гигантов из РФ поставил перед российским инженером жесткий ультиматум: оставаться на «пиратских» версиях с риском для безопасности или совершить «прыжок веры» в мир Open Source и отечественных разработок.
Подробнее
Economy
Эпоха «одноразового» кода: Почему никто не пишет документацию и как это убивает ваш бизнес?
Давайте попробуем разобраться: почему никто не пишет документацию? Представьте себе классическую картину: процветающая компания по производству промышленной автоматики. Их флагманский контроллер успешно продается уже три года. Внезапно крупный заказчик сообщает о странном баге, который проявляется только при определенной комбинации температуры и влажности. Директор вызывает ведущего разработчика, но выясняется, что тот уволился три месяца назад, уехав на Бали или перейдя в крупный ИТ-гигант.
Новый инженер открывает папку с проектом и замирает в ужасе. Там нет ни описания алгоритмов, ни схемы взаимодействия модулей, ни даже комментариев в коде. В папке лежат файлы с названиями main_final.c, main_final_v2_fixed.c и test_working_DO_NOT_TOUCH.bin. Схемотехника устройства — это «черный ящик», а прошивка — монолитное полотно из «магических чисел» и недокументированных прерываний.
Проходит месяц. Новый инженер всё еще пытается понять, почему при включении таймера №2 отключается АЦП. Заказчик грозит судом. Компания теряет репутацию. Это и есть эпоха «одноразового» кода — время, когда проекты умирают вместе с увольнением их создателя. Сегодня на nk9.ru мы проводим вскрытие этой «тихой» проблемы и объясняем, почему ваш главный актив — это не печатная плата, а качественная документация.
1. Психология отрицания: Почему инженеры ненавидят писать и почему никто не пишет документацию?
Спросите любого разработчика: «Почему ты не описал этот кусок кода?». Вы услышите стандартный набор оправданий:
- «У нас Agile, нам нужно быстро выкатывать функции, а не бумажки писать».
- «Хороший код документирует сам себя (Self-documenting code)».
- «Я всё помню, если что — спросите меня».
- «Документация устаревает в тот момент, когда я нажимаю кнопку “Save”».
Горькая правда: Писать код — это творчество, созидание, мгновенный результат (светодиод мигнул — дофамин получен). Писать документацию — это скучная рутина, бюрократия и «работа в стол». Инженер подсознательно воспринимает документирование как признание собственной заменимости. «Если я всё опишу, меня смогут уволить и нанять студента».
Этот «инстинкт самосохранения через хаос» создает огромные риски для бизнеса. Компания становится заложником одного человека.
2. Фактор автобуса (Bus Factor): Когда ваш проект — смертник
В менеджменте есть понятие «фактор автобуса» — сколько ключевых сотрудников должен сбить автобус, чтобы проект остановился? В 90% российских малых и средних компаний в области электроники этот фактор равен единице.
Когда «единственный носитель знаний» уходит, проект переходит в стадию археологии. Новый разработчик тратит не 20%, а 80% времени на попытки понять:
- Почему этот резистор стоит именно здесь? (В схеме нет примечаний).
- Какая логика заложена в расчет коэффициентов ПИД-регулятора? (Формулы нет в документации, в коде — просто константы).
- Как вообще компилируется этот проект? (Зависимости не описаны, нужны специфические версии компилятора 2015 года).
Экономика катастрофы: Полгода зарплаты нового инженера, потраченные на «раскопки», — это прямые убытки. Срыв сроков по контракту — косвенные. В итоге дешевле оказывается переписать проект с нуля, чем поддерживать старый. Это и есть определение «одноразового» кода.
3. Специфика Embedded: Двойной удар «Железо + Софт»
В чистом ИТ документация важна, но в встраиваемых системах её отсутствие фатально. Здесь софт неразрывно связан с физикой.
- Магические числа в регистрах: Видеть в коде
RCC->CR |= 0x00010000;без комментария — это пытка. Что это? Включение внешнего кварца? Или настройка PLL? Без даташита и комментария понять это невозможно, а даташиты на китайские чипы (о чем мы говорили ранее) сами по себе — ребус. - Тайминги и гонки: В Embedded критически важны микросекунды. Если разработчик не описал, почему прерывание имеет такой приоритет, новый инженер, поменяв одну строчку, может «развалить» всю систему реального времени. Такие баги проявляются раз в неделю и сводят с ума.
- Схемотехнические хитрости: Иногда на плате стоит «лишний» конденсатор, который гасит наводку от конкретного мотора. Если это не задокументировано в описании ревизии платы, следующий инженер его уберет как «ненужный», и вся серия устройств начнет гореть в полях.
4. Документация — это не Word-файл на 200 страниц
Главная ошибка руководителей — требовать «Пояснительную записку по ГОСТу» в конце проекта. Это не работает. К концу проекта все выгорели и хотят только одного — сдать и забыть.
Современный подход — «Документация как код» (Docs like Code):
- Doxygen / Sphinx: Комментарии пишутся прямо в коде в определенном формате. Инструмент сам генерирует из них красивый сайт с графами вызовов и описанием функций. Если комментария нет в коде — код не принимается (Code Review).
- Markdown в Git: Рядом с файлами проекта в репозитории должен лежать файл
README.md. В нем — краткая инструкция: как собрать проект, какие библиотеки нужны, какой версией софта прошивать. Это занимает 15 минут, но экономит недели в будущем. - Wiki-системы (Confluence, Notion, Obsidian): Здесь живет высокоуровневое описание. «Почему мы выбрали этот чип?», «Как работает протокол обмена с сервером?», «Схема прохождения сигналов».
- Схемотехнические заметки: В Altium или KiCad можно и нужно писать текстовые блоки прямо на схеме. «Этот конденсатор — для защиты от помех мотора X», «Этот делитель напряжения рассчитан под 5-вольтовый датчик».
5. Инженерный долг и культура АРК
(АРК) продвигает простую мысль: проект закончен не тогда, когда он работает, а когда его может понять и модифицировать посторонний инженер.
Отсутствие документации — это самый тяжелый вид «технического долга». Вы берете кредит у своего будущего, и проценты по этому кредиту — это ваше время, нервы и деньги.
Совет руководителям:
- Выделяйте 20% времени спринта на документирование.
- Не платите финальный бонус, пока документация не прошла проверку «методом нового человека» (дайте проект другому инженеру и посмотрите, сможет ли он его собрать и объяснить логику).
- Внедрите стандарт описания регистров и макросов.
Заключение: Ваш главный актив — это смыслы
В эпоху, когда нейросети могут писать куски кода, роль инженера смещается от «писателя строк» к «архитектору смыслов». Программный код — это расходный материал, он устаревает. Но логика работы устройства, зафиксированная в документации, — это интеллектуальная собственность компании, которая сохраняет ценность десятилетиями.
Не позволяйте вашим проектам становиться «одноразовыми». На nk9.ru мы верим, что дисциплина в описании — это высшее проявление уважения к коллегам и к самому себе. Проект, который умирает вместе с разработчиком, — это не инженерия, это кустарничество.
Пишите документацию так, как будто человек, который будет поддерживать ваш код после вас — склонный к насилию психопат, который знает, где вы живете.
А как в вашей компании обстоят дела с документацией? Есть ли у вас «файлы-призраки», в которых никто не может разобраться? Поделитесь своими историями в комментариях!