- PVSM.RU - https://www.pvsm.ru -
Много приходится читать и обсуждать разные стандарты кодирования, ограничивающие применение тех или иных конструкций языка (goto, множественное наследование классов в C++) или приемов программирования (рекурсия, динамическое выделение памяти после инициализации приложения). Применительно к С/С++, наиболее известными стандартами кодирования являются MISRA [1], HICPP [2], Google C++ Style Guide [3]. Интересной является и статья на Хабре про 10 правил, которые позволяют NASA писать миллионы строк кода с минимальными ошибками [4].
Под катом немного юмора и серьезных рассуждений о применении различных практик ведения проектов.
Как утверждается, эти стандарты позволяют писать более чистый и легко читаемый код. Они позволяют избегать некоторых видов ошибок кодирования, и облегчают поддержку программного продукта.
Однако, на мой взгляд, незаслуженно мало внимания уделяется тому, как члены команды взаимодействуют друг с другом. Слаженная работа команды, эффективная коммуникация между людьми не менее важна для успеха проекта. Недопонимание, неправильная интерпретация сказанного, трудно понимаемые комментарии в исходном коде в конечном итоге сказываются на качестве программного продукта.
Для того, чтобы заполнить этот пробел, предлагаю ввести 10 правил, которые бы позволили бы избежать наиболее досадных ситуаций, происходящих из неясного изложения своих мыслей:
А теперь абсолютно серьезно.
Есть правила, имеющие универсальное и повсеместное применение. Это уголовный и гражданский кодексы, правила техники безопасности и пр. Соблюдение этих правил иногда позволяет избежать определенного рода неприятностей, но эти правила никоим образом не являются инструкцией, как достичь успеха.
Есть также книжки и психологические курсы о том, как быстро разбогатеть. Но мало кто воспринимает это всерьез. Не существует сколько-нибудь серьезно воспринимаемых правил или инструкций, гарантирующих успех проекта или успех в личной жизни.
Означает ли это, что к стандартам кодирования, разного рада практикам (SCRUM, Continues Integration, Code Review и пр.) не стоит относиться серьезно? Вовсе нет. Но надо понимать, что ни одна из практик в IT не является универсальной. Ни одна практика не приводит к гарантированному повышению эффективности проекта. Только накопленный опыт, интуиция и профессионализм менеджеров и ведущих разработчиков помогает принять правильное решение в каждой конкретной ситуации. Иначе бы наша профессия не была настолько трудной и интересной.
Если какой-то менеджер говорит о необходимости использования юнит тестов и аргументирует это красивыми диаграммами, убеждающими, что стоимость бага в геометрической прогрессии зависит от того, на какой стадии развития проекта этот баг найден – бегите из этого проекта или из этой компании. Я ничего не имею против юнит тестов. Однако, решение о том, использовать их или нет, и как их реализовывать, должно исходить из специфики данного проекта. Вот неполный перечень вопросов, на которые надо ответить прежде, чем принять решение:
Если мне надо что-то разрубить, я ищу топор. Но если у меня есть топор, и я хорошо умею им пользоваться, то это вовсе не означает, что я буду бегать и искать, что бы разрубить. Точно также и с правилами/практиками в программировании. Если я хорошо владею какой-либо практикой, я не буду требовать, чтобы ее применяли повсеместно.
Автор: erezer
Источник [5]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/programmirovanie/139903
Ссылки в тексте:
[1] MISRA: https://en.wikipedia.org/wiki/MISRA_C
[2] HICPP: http://www.programmingresearch.com/coding-standards/high-integrity-cpp
[3] Google C++ Style Guide: https://google.github.io/styleguide/cppguide.html
[4] 10 правил, которые позволяют NASA писать миллионы строк кода с минимальными ошибками: https://habrahabr.ru/company/hexlet/blog/303160
[5] Источник: https://habrahabr.ru/post/303786/?utm_source=habrahabr&utm_medium=rss&utm_campaign=sandbox
Нажмите здесь для печати.