Цели восьмого процесса по ГОСТ Р 56939-2024:
5.8.1.1 Обеспечение эффективной и единообразной организации оформления и использования исходного кода в соответствии с предъявляемыми к ПО требованиями.
Основное время при работе с кодом программисты тратят не на его написание, а на чтение! Это подтверждено исследованиями, да и вы сами, если программируете и присмотритесь к своей работе, это заметите.
Быстро и много код пишется только в небольших и недавно начатых проектах. Или в новых модулях, которые, по сути, тоже новые мини-проекты. Но с ростом проекта всё больше времени тратится на изучение кода перед тем, как будет добавлена новая функциональность или исправлен баг. Бывает даже, что после внесения изменений строк кода становится не больше, а меньше :)
Есть сразу несколько причин, почему так происходит:
- В большом (legacy) проекте чаще нужно изменить старое поведение, а не создать что-то принципиальное новое. Все основные функции в каком-то виде уже существуют, и речь, скорее, идёт о их развитии или изменения поведения. Получается, прежде чем что-то изменить, нужно найти соответствующий код и понять, как он работает.
- Часто приходится сопровождать чужой код, из-за чего бывает трудно найти нужное место и понять, как всё устроено.
- В большом проекте, если вы долго с ним работаете, даже ваш собственный код со временем становится "чужим". Во-первых, через несколько лет вы его забываете и не помните деталей реализации. Во-вторых, ваши коллеги за это время тоже могли вносить в него правки или рефакторить.
- В legacy-проектах можно по аналогии с годичными кольцами деревьев наблюдать изменение в стиле написания кода. Чаще всего это связано с появлением новых версий языка и библиотек. Эта разнородность тоже добавляет сложность к пониманию старых частей проекта.
- Известно, что с ростом проекта плотность ошибок растёт нелинейно. Т.е. чем больше кода, тем выше вероятность, что при написании или изменении кода будет внесена ошибка. Это объясняется ростом взаимосвязей разных частей проекта, которые сложно учитывать. Рост сложности понимания влияет и на рост процента времени, который приходится тратить человеку прежде чем сделать правку.
- Думаю, вы и сами сможете добавить пару пунктов к этому списку.
Из сказанного вытекает, что требуется делать код по возможности простым для восприятия (чтения). Также очень важно, чтобы весь код был единообразно оформлен. Если оформление единообразно, то проще прочитать, понять и исправить код коллег.
Это можно достичь, сформировав, приняв и поддерживая в актуальном состоянии правила кодирования. Что, собственно, и описано в пункте 5.8 ГОСТ-а, который мы рассматриваем. Т.е. следует разработать регламент оформления кода и систематически его придерживаться.