Оглавление

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

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

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

В качестве первой остановки в нашем путешествии мы обсудим важность качества кода.

Качество кода относится к общему уровню совершенства и надежности кода, написанного разработчиком программного обеспечения или командой. Он включает в себя широкий спектр факторов, включая удобочитаемость, ремонтопригодность, производительность, безопасность и соответствие отраслевым стандартам и передовым практикам. Это все хорошо на бумаге, но на практике это может означать многое для многих людей. Программная инженерия заполнена умными людьми, а иногда и умными, отличающимися мнениями. Иногда эти мнения могут быть догматичными и твердыми. Поскольку мы описываем «первый» шаг в повышении качества кода, как команда из 3, 10 или даже как команда из 1, должен существовать какой-то формализованный процесс определения стандартов, которым должна следовать команда. Обычно это делается в виде руководства по стилю. Это важные первые шаги, которые должна сделать команда. Они определяют, какие правила следует соблюдать. В руководстве по стилю также должен быть процесс, как что-то изменить. Лучшие практики постоянно развиваются, и на то есть веские причины.

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

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

К счастью, этим детям не пришлось страдать, и их быстро сняли с доски.

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

Качество кода важно по ряду причин:

  1. Повышенная надежность: высококачественный код более надежен, менее подвержен ошибкам и сбоям и в целом более надежен. Это приводит к лучшему пользовательскому опыту и меньшему количеству запросов в службу поддержки. Также улучшен опыт разработчиков, о котором я расскажу позже.
  2. Повышенная эффективность: хорошо написанный, организованный и простой для понимания код можно более эффективно поддерживать и обновлять, экономя время и ресурсы в долгосрочной перспективе.
  3. Лучшее сотрудничество: когда код высокого качества, нескольким разработчикам легче работать над одной кодовой базой, что снижает риск конфликтов и облегчает сотрудничество.
  4. Более быстрая разработка: высококачественный код часто быстрее и эффективнее, что позволяет разработчикам быстро внедрять новые функции и вносить изменения в кодовую базу.
  5. Улучшенная безопасность: код, который соответствует лучшим практикам и написан с учетом безопасности, менее уязвим для атак и утечки данных, защищая как пользователей программного обеспечения, так и репутацию команды разработчиков.

Мышление «Остановить кровотечение» можно применить к качеству кода, и это, несомненно, важная концепция, о которой следует помнить. Когда вы вводите новую кодовую базу, и это похоже на «Дикий, дикий Запад», когда вы читаете и пишете код, вероятно, есть некоторое «кровотечение». Как инженеры, мы всегда учимся чему-то новому, и мы несем ответственность за то, чтобы кодовая база была самого высокого качества. Улучшить работоспособность кодовой базы за счет соблюдения стандартов качества непросто, но необходимо убедиться, что код соответствует лучшим стандартам.

Очевидный шаг — обратить внимание на качество самого кода. Однако также важно сделать шаг назад и взглянуть на картину шире. «Кровотечение» в этом сценарии — это не код; это разработчики. Если вы единственный, кто придерживается мнения, что код должен быть написан определенным образом, без руководства по стилю, то вы настраиваете себя на провал. Важно убедиться, что все разработчики в команде понимают важность качества кода и что они все согласны с тем, что касается стандартов и ожиданий. Это поможет убедиться, что кодовая база максимально здорова и что каждый вносит свой вклад в положительную сторону. Первым шагом здесь является создание руководства по стилю вместе с командой. Вам не нужно начинать с нуля, есть множество шаблонных и самоуверенных руководств по стилю на выбор. На этой первой встрече настройте способ внести свой вклад в это руководство по стилю. Я не могу не подчеркнуть важность согласования руководства по стилю, а затем заставить всех следовать стандартам. Когда команда устанавливает процесс, а затем не следует этому процессу, может случиться гораздо хуже.

Разговоры об использовании точек с запятой, именах переменных и количестве строк в методе часто встречаются в обзорах запросов на включение, что может значительно замедлить время цикла PR. Без руководства по стилю, на которое можно ссылаться, одни и те же нарушения стиля часто повторяются, что приводит к отсутствию сплоченности команды, потере времени и разочарованию для всех участников. Запросы на вытягивание не должны использоваться в качестве форума для обсуждения преимуществ одного стиля над другим; вместо этого, если руководства по стилю нет, эти обсуждения должны происходить в более подходящей обстановке и должны привести к общему руководству по стилю, о котором знают и которого придерживаются все члены команды. Это создаст ощущение согласованности, обеспечивая при этом гибкость и индивидуальные предпочтения. Индивидуальные предпочтения также необходимы. Вот почему это называется руководством по стилю, а не законами стиля. Руководства предназначены для того, чтобы помочь разработчику следовать практикам, внедренным командой, но это программное обеспечение, и есть случаи, когда руководство можно отложить по уважительной причине. Разработчик программного обеспечения всегда должен иметь возможность отстоять свою позицию относительно того, почему он принял решение не следовать руководству по стилю.

*Дополнительный совет: во время собеседования в новой компании попросите показать их руководства по стилю и узнайте об их стандартах качества. Это отличный способ получить представление о том, как команда или компания создает стандарты и обеспечивает их соблюдение.

После того, как у вас есть руководство по стилю, следующим шагом будет перенос ворчания на бота. Это отличный способ автоматизировать процесс соблюдения правил, с которыми мы все согласились. В мире ruby ​​у нас есть несколько инструментов, помогающих нам применять правила, которым мы все пытаемся следовать. Rubocop, ruby ​​gem, который запускает статический анализ, является отличным инструментом для использования, поскольку он способен обнаруживать любые нарушения руководства по стилю и предупреждать команду о любых синтаксических ошибках или других проблемах. Кроме того, Rubocop можно использовать в качестве отличного обучающего инструмента, позволяющего разработчикам изучать передовой опыт и гарантирующего, что все пишут код, соответствующий одним и тем же стандартам. Используя Rubocop, мы можем не только упростить процесс соблюдения правил, но и гарантировать, что каждый пишет последовательный, читабельный и качественный код. Brakeman — это мощный инструмент безопасности, предлагающий эффективный подход к повышению безопасности кодовой базы. Он может обнаруживать уязвимости в приложениях, написанных на Ruby on Rails, и предоставлять полезную информацию, помогающую выявлять и устранять недостатки безопасности. Брейкман также может отслеживать изменения с течением времени, чтобы убедиться, что кодовая база остается в безопасности и что любые новые изменения не создают проблем с безопасностью. Он также предоставляет подробные отчеты для разработчиков, которые могут просматривать и устранять любые проблемы безопасности. Brakeman — отличный помощник для любого разработчика Ruby on Rails, который хочет обеспечить безопасность своей кодовой базы. Это всего лишь 2 примера, напрямую связанных с рубиновым миром, но не ограничивающихся им. Каждый язык программирования имеет встроенные инструменты, помогающие инженерам решать проблемы, не выполняя кропотливый процесс вручную. Эти процессы уже решены и могут быть автоматизированы, что в конечном итоге сэкономит время и ресурсы. Здесь важно отметить, что продукт «Качество» Code Climate является одним из таких инструментов, который я использую в течение многих лет, даже до того, как начал свою работу в компании. Это позволяет вам выполнять все эти проверки как часть запроса на включение, тем самым уменьшая потребность в отладке и стремясь к более высокому качеству кода. Более того, вы даже можете получить автоматический обзор всей кодовой базы, что позволит вам понять структуру и любые потенциальные проблемы, которые могут возникнуть из-за этого.

Используя продукт Code Climate «Quality», инженеры могут сэкономить время и ресурсы, автоматизировав процесс отладки и стремясь к более высокому качеству кода. Кроме того, продукт обеспечивает автоматический обзор всей кодовой базы, чтобы лучше понять структуру и любые потенциальные проблемы. Это может быть особенно полезно при работе с большой и незнакомой кодовой базой. Кроме того, продукт легко интегрируется в существующие рабочие процессы, что делает его отличным выбором для любой команды разработчиков. Статический анализ — это один из тех инструментов, которые я хотел бы преобразовать в диаграмму EMS, выделяя области, где ЕМТ должен был выполнять одно действие вместо другого. К сожалению, это по-прежнему ручной процесс, однако я хотел бы в будущем поэкспериментировать с некоторыми инструментами ИИ, чтобы улучшить этот процесс.

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

Ключевым аспектом является использование руководства по стилю, которое описывает стандарты и ожидания для команды и помогает обеспечить согласованность и удобочитаемость кодовой базы. Кроме того, автоматизация процесса обеспечения соблюдения этих стандартов с помощью таких инструментов, как Rubocop, Brakeman и продукт Code Climate «Quality», может сэкономить время и ресурсы при одновременном повышении качества кода.

Всем привет! В нашей следующей серии мы углубимся в тему «Опыт разработчика» и то, как мышление «Остановить кровотечение» может помочь сделать его еще лучше. Не пропустите последние новости и информацию о разработке программного обеспечения и образе мышления EMS!