О "простых" и "непростых" программистах.
На идею этой заметки меня натолкнуло одно старое обсуждение в комментах на Хабре и разговоры с коллегами в курилке.
Как известно, программисты всякие нужны, программисты всякие важны.
Работодатели, правда, так не всегда считают, и можно встретить в одном и том же городе программиста, пишущего софт для автоматизации производственной линии, производящий в день продукта на сотни тысяч рублей, с зарплатой в 40 тысяч в месяц, и программиста, пишущего код интернет-магазина торгующего плюшевыми Ждунами и чехлами на айфоны за 80 тысяч рублей в месяц. Но раз люди люди выбирают первый вариант, значит у них есть причины, либо же их все устраивает, да и вообще, это не относится к сегодняшней теме.
С коллегами же зашла тема "как кому работалось на предыдущих работах" и упоминание разных штук, отсутствие которых для нас сейчас воспринимается как дикость, но когда-то было (а много где и до сих пор есть) в порядке вещей. И сведя все байки вместе, и добавив свой личный опыт, возникла мысль изложить, чего, общеизвестного и общепринятого в мире "простых программистов" часто не хватает в мире "непростых программистов" :) И нет, мы не будем сейчас упоминать совсем страшные случаи, когда новые проекты пишутся на Delphi 7 или C++ стандарта 98-го года (в конце концов, нас могут читать дети).
Большинство этих пунктов будут применимы к разработчикам, пишущим софт под встраиваемые системы и микроконтроллеры, а также десктопные приложения для взаимодействия с различным оборудованием (конфигурирование, сбор и обработка данных, и т.д.), но и программисты "классических" ПЛК на МЭКовских языках возможно смогут применить что-то из описанного.
1. Системы контроля версий.
Вот честно, я бы никогда не подумал, что в XXI-веке где-то еще не используют SVN или Git. Но мой коллега действительно подтвердил, что в одном НПО, где он работал несколько лет назад, новая версия программы делалась копированием папки с другим названием, а обмен кодом между сотрудниками производился через сетевой диск, а иногда вообще на флешках. Хотя, казалось бы, очевидные и ощутимые плюсы есть не только для людей, сообща работающих над одной кодовой базой (слияния, разрешения конфликтов), но и для каждого разработчика в отдельности (четкий контроль изменений между версиями, откат изменений, ветки для нового функционала и экспериментов, и многое другое). А еще, оказываются, бывают места где до сих пор пушат сразу в master-ветку. Но не будем о грустном.
2. Стандарт кодирования.
В некоторых местах я насмотрелся на код, в котором табовые отступы перемешаны с пробельными, скобки расставлены как попало, переменные обозваны то венгерской нотацией, то camel-case'ом, то вообще транслитом с русского языка -- выглядит ужасно, честно слово. Но вообще, это понятие относится не только к стилю написания кода, а в целом к правилам "что можно, а что нельзя". Грамотно выбранный или сформулированный стандарт кодирования, соблюдение которого строго обязательно всем разработчикам, поможет не только улучшить читаемость и понимаемость кода, но и избежать распространенных программных ошибок и неопределенного поведения. Если вы пишете софт, у которого высокие требования к надежности (например, управление какой-то установкой), то можно взять за основу MISRA C, если это простая прикладная программа - то, например, стандарт от Google. А выбрав и утвердив стандарт, очень больно бить по рукам тех, кто его не соблюдает. Разработчикам на C++ настоятельно рекомендую ознакомиться также с Core Guidelines. А для форматирования всегда есть clang-format :)
3. Юнит- и интеграционное тестирование.
Здесь как бы все очевидно. Тесты (с обязательным их прогоном после любого изменения) нужны всему, что сложнее небольшой утилитки или Proof-of-Concept-проекта (хотя и ему понадобятся, если он выстрелит и вырастет). Я слышал много отговорок на тему "почему мы не пишем тесты", среди которых самых популярных две:
- "мы не можем себе позволить выделить время на написание тестов". Но, видимо, "можем" потратить в пять раз больше времени потом на поиск "что сломалось здесь, когда исправили там" и разгребание жалоб от заказчиков, не говоря уже о том что через 5-10 лет жизни проекта любой рефакторинг или переделка архитектуры превратятся в хождение по минному полю.
- "наши разработки сложно протестировать стандартными средствам". Может быть, где-то такое действительно есть, но в большинстве случаев, которые я видел, эта фраза означала или незнание говорящим возможностей инструментов юнит- и интеграционного тестирования, или отвратительную программную архитектуру продукта, в которой все запутано и разные модули прибиты гвоздями друг к другу. В конце концов, уже много лет известны SOLID-принципы, известен IoC подход (который можно реализовать даже на чистом Си без классов), и многое другое. Соблюдение простых правил позволяет тестировать части даже контроллерного кода (например, относящиеся к мат. расчетам или автоматам состояний) отдельно на обычном компьютере, а работу с железом можно покрыть интеграционными тестами на стендах, не говоря уж о том, что грамотный подход к проектированию окажет вам в будущем огромную услугу, когда будет необходимо переделывать или расширять функционал или переносить код на другую аппаратную платформу.
4. Документация. Иногда программа делается в спешке, иногда вообще "на коленке" где-нибудь на объекте в поле. Такое бывает. Но просто вспомните старую шутку про то, что код надо писать и документировать так, будто в дальнейшем поддерживать его будет психопат, знающий, где вы живете. Если принят хороший стандарт кодирования и грамотно спроектирована архитектура, то комментарии к коду часто даже не нужны (а если и нужны, то стоит описывать не "что происходит", а "как происходит и зачем происходит"), но вот Doxygen-заголовки к методам и структурам не помешают никогда. К тому же, с помощью Doxygen можно легко сгенерировать удобный справочник с описанием всех блоков и связей между ними, и многие среды разработки также могут использовать эти комментарии при навигации по коду и автодополнении.
5. Bus factor != 1. Понятие "число автобуса" обычно означает количество человек, с которыми должно случиться что-то нехорошее (например, попадание под автобус), чтобы проект начал испытывать неиллюзорные трудности. Я встречал команды, в которых это число равно единице (только один сотрудник хорошо знает как работает какая-то часть программы или даже программа целиком), и если у вас дело обстоит так же, то это тревожный звонок. Кроме распределения задач между разными сотрудниками, документирования, совместных обсуждений и прочего, для этого есть еще один очень хороший инструмент...
6. ...и называется он Code Review. Одним ударом убивается сразу несколько зайцев. Обязательная проверка кода коллегами для поиска потенциальных ошибок, проверки на соответствия стандарту кодирования и полноты документации, и понимания "что здесь происходит, зачем и почему". Пока не получены +1 и +1, код в основную ветку программы не попадает. Инструментов для подобного много -- Gerrit, GitLab, и т.д. И сюда же можно заодно добавить систему баг-трекинга и локальную wiki. Те, кто будут поддерживать ваш продукт через много лет, скажут вам спасибо.
Ну вот и все. Понятное дело, что случаи у всех разные, и волшебных пилюль не существует. Но всегда стоит периодически оглядываться по сторонам и задумываться о том, как сделать написание кода проще и надежнее. Удачи в работе!