Введение

Решение вашей ИТ-проблемы найдено. Радуйтесь! QA одобрил это, и без лишних раздумий его запускают в производство, и больше о нем не беспокоятся.

Большинство людей, работающих в сфере ИТ и связанных с ней, знают, что это не так просто. По мере того, как все больше пользователей используют программное обеспечение, обнаруживаются ошибки, требуются новые функции, а другие желают немного изменить вкус для решения своей конкретной проблемы. С этими потребностями растут затраты на обслуживание и кодовую базу. Эти затраты на обслуживание будут широко варьироваться в зависимости от ряда переменных, основной из которых является качество кода. Плохо написанный и спроектированный код будет гноиться, ставя в тупик будущие усилия. Хорошо написанный и спроектированный код будет более плавно развиваться в будущих фазах. Чистый код является приоритетом.

Последствия плохого кода

Проще говоря, плохой код — это код, который сложнее исправить, понять, улучшить и/или добавить в него усовершенствования. Это определение может быть произвольным и абстрактным, но оно должно служить цели показать, почему плохой код имеет негативные последствия. Согласно Институту инженерии по электротехнике и электронике (IEEE), обслуживание программного обеспечения — это модификация программного обеспечения для исправления ошибок, повышения производительности или адаптации продукта к изменившейся среде. Таким образом, плохой код усложняет обслуживание.

Поскольку обслуживание программного обеспечения в среднем составляет от 40% до 80% конечной стоимости, обычно это самый дорогой аспект создания ИТ-продукта. Конечно, основная причина этих расходов заключается в том, что любые изменения продукта после его доставки считаются техническим обслуживанием, поэтому оно охватывает более широкий спектр задач и, как правило, более длительный период времени. По оценке автора Cбережливого кода Роберта Мартина, из времени, затрачиваемого на сопровождение, от 40 до 60 % уходит на понимание кода, над которым ведется работа. Это означает, что написание чистого кода является основным способом минимизации затрат, потому что его легче понять и использовать.

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

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

Другой, менее количественный эффект плохого кода — это влияние морального духа на разработчиков. Вообще говоря, плохо работающий сотрудник заставит других выполнять дополнительную работу, поскольку не сможет выполнить свою работу или сделать ее хорошо. Плохой код, хотя и созданный не только плохими сотрудниками, — это плохо выполненная работа, с которой другим разработчикам придется иметь дело в какой-то момент в будущем. Столкнувшись с таким кодом, многие разработчики тратят дополнительное время, пытаясь понять, что он делает, почему он был сделан таким образом или как с ним работать. В конечном итоге разочаровавшись в этом. Разочарование идет рука об руку с плохим моральным духом, а плохой моральный дух может быть фактором, способствующим снижению производительности или качества, что усугубит запах кода и срыв сроков. Решение этой проблемы должно быть очевидным; привлекать разработчиков к ответственности за их код и его недостатки.

Обеспечение чистого кода

Чистый код важен для успеха в сфере ИТ. Создание культуры, которая планирует будущее и делает упор на качество, является основой для достижения чистого кода.

Один из способов обеспечить чистоту кода — спланировать неизбежное обслуживание после выпуска. Фактические детали, связанные с проектированием программного обеспечения, чтобы его можно было обслуживать, зависят от проекта, но наиболее распространенный способ планирования сопровождения — это принятие того, что оно потребуется. Это должно привести к распознаванию повторяющихся процедур, потоков и т. д. Это также должно означать планирование проблемы, а не обязательно деталей. Это заставляет разработчиков проектировать вокруг абстракций, а не конкретной реализации. Цели разработки программного обеспечения таким образом должны изолировать реализации и ошибки, способствовать повторному использованию кода и держать его открытым для добавления функций.

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

Еще один способ минимизировать время обслуживания — использовать стандарты кода. То есть четко определите, как должны обрабатываться некоторые основные аспекты, такие как имена переменных и методов, варианты использования шаблонов проектирования, форматирование кода (табуляция или пробелы) и т. д. Это объединяет всех разработчиков. Что должно означать, что разработчикам не нужно прыгать по коду, пытаясь понять структуру файла, им просто нужно сосредоточиться на понимании того, как работает код. Другими словами, большая часть кода может быть шаблоном для команды разработчиков, что, надеюсь, освободит их, чтобы они могли полностью сосредоточиться на его логике.

Эти стандарты кодирования легко могут и, возможно, должны быть проанализированы сторонними инструментами. Есть еще один способ убедиться, что код соответствует установленному стандарту, а также предоставляет команде доступ к большему количеству кодовой базы; обзоры кода. Правильно проведенные проверки кода должны быть сосредоточены на анализе удобочитаемости, понятности и ремонтопригодности определенных частей кода. Человек, просматривающий свой код, должен продемонстрировать свои изменения в целом, но более конкретно сосредоточить внимание на конкретных областях, которые, по его мнению, были сложными, могли бы чему-то научить других или задать вопрос, если все сделано правильно. Это также означает, что те, кто делает обзор, должны потратить некоторое время на просмотр кода и заранее подготовиться с базовым пониманием всего этого. Помните, что цель этих обзоров не должна быть сосредоточена на дизайне или процессе в целом, а должна быть сосредоточена на конкретном коде. Анализ дизайна и процесса, вероятно, следует проводить на более ранних этапах жизненного цикла, чтобы он не был ошибочным для его реализации.

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

Еще один возможный способ содержать код в чистоте — обеспечить хорошую гарантию качества. Хороший контроль качества может сократить время, необходимое для тестирования, при этом тщательно тестируя приложения. Это тестирование должно выявлять краеугольные случаи, необычные сценарии и быть воспроизводимым, позволяя разработчикам изменять и легко тестировать код. Это очень хорошо означает, что тестировщики должны иметь возможность разрабатывать инструменты, помогающие их тестированию, от моделирования высоких нагрузок до автоматизации кликов по каждому сценарию приложения. Короче говоря, QA предлагают еще один уровень, гарантирующий, что код работает во всех случаях, а хорошее обеспечение качества должно быть воспроизводимым.

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

Вывод

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