В современном мире, когда программное обеспечение проникает в каждый уголок нашей жизни, качество кода становится критически важным. Мы, разработчики, каждый день создаем новые продукты, улучшаем старые и автоматизируем различные процессы. Но осознаем ли мы всегда глубокую ответственность, которую это несет? Наши решения определяют функционирование всего: от банковских систем до медицинских устройств. Сколько раз мы задавались вопросом о потенциальных последствиях нашего кода? В этой статье я хочу подчеркнуть важность написания качественного кода и рассмотреть потенциальные риски его пренебрежения.
Производительность или качество?
Мир IT-разработки сложен и многогранен. Особенно когда речь идет о сроках и производительности. В гонке за выполнением проектов и разработкой новых фич, легко потерять из виду главное: качество продукта. Но что такое "качественный код"?
Конвейер разработки: Сегодня большинство компаний внедряют методологии быстрой разработки, которые направлены на ускорение процессов. Это, безусловно, эффективно с экономической точки зрения. Но при этом возрастает риск ошибок, потому что мы постоянно находимся под давлением. Недостаточно времени на анализ, планирование и, главное, тестирование. Результат? Код, который может работать, но не всегда корректно или эффективно.
Саморефлексия разработчика: Хороший код — это не только тот, который выполняет свою функцию. Это код, который легко читать, масштабировать, который эффективен и безопасен. Но как часто мы, разработчики, задаем себе вопросы о качестве своего продукта? Сколько раз мы возвращаемся к своему коду, чтобы оптимизировать его, даже если он уже "работает"?
Ответственность перед пользователем: Наши пользователи доверяют нам. Они полагаются на наш продукт, на наш код. Они ожидают, что все будет работать без сбоев и ошибок. Каждый раз, когда мы жертвуем качеством ради скорости, мы рискуем потерять это доверие.
В завершение: производительность — это важно. Но не менее важно помнить, что мы создаем продукты для людей. И каждый уголок кода, который мы пишем, влияет на их опыт использования, безопасность и удовлетворенность.
Значимость тестирования
Тестирование – это не просто шаг в процессе разработки; это крайне важное звено, которое обеспечивает качество и надежность кода. Рассмотрим несколько ключевых аспектов этой стадии.
Не все тесты созданы равными: Многие разработчики воспринимают тесты как нечто формальное. "Покрытие кода тестами на 90%? Отлично! - А можем сделать 100?". Но покрытие кода не всегда коррелирует с качеством. Важнее фокусироваться на реальных сценариях использования и критически важных функциях, чем на цифре в отчете.
Регрессионное тестирование: С каждым обновлением кода возрастает риск нарушить уже существующую функциональность. Регрессионное тестирование позволяет удостовериться, что новые изменения не внесли нежелательных последствий. К сожалению, это то, что многие продукты упускают из вида в погоне за сроками.
Проактивное тестирование: Хорошо, когда разработчик не просто реагирует на ошибки, но и предугадывает потенциальные проблемы, создавая тестовые сценарии даже перед тем, как начать написание кода. Но будем честны, сколько из нас так делают?
Каждый код, который мы пишем, может влиять на жизни людей – независимо от того, создаем ли мы медицинский софт или простое мобильное приложение. Это не просто строка кода; это ответственность. Тестирование не является дополнительной опцией или шагом, который можно пропустить; это неотъемлемая часть создания качественного продукта.
Реальные последствия недостаточного качества кода
Многие разработчики ошибочно полагают, что их обязанности завершаются, как только функция исполняется или ошибки исправлены. Однако в реальности даже незначительный промах в кодировании может привести к катастрофическим результатам.
Пример из медицинской сферы:
Представим систему для медицинских учреждений, предназначенную для отслеживания назначенных пациентам препаратов. Все кажется простым: врач назначает препарат, система фиксирует его, а пациенту предоставляются рекомендации по дозировке и режиму приема. Но что если из-за ошибки в коде дозировка лекарства, которая была указана в формате "10.0 мг", изменилась на "100 мг" после обновления программы из-за пропавшей десятичной точки? Такая ошибка может привести к тому, что пациент примет в десять раз больше лекарства, чем ему было назначено, что грозит серьезными осложнениями или даже смертью.
И многие могут подумать: "Это же очевидная ошибка. Пациент наверняка проконсультируется с врачом или свяжется с медицинским центром перед тем, как принять такую дозу". И хотя в большинстве случаев это может быть так, всегда найдется человек, который просто подумает, что врач изменил рекомендованную дозу или даже не обратит на это внимания и примет лекарство, руководствуясь ошибочной инструкцией. Таким образом, даже одна маленькая ошибка в коде может иметь глубокие и трагические последствия для конкретного индивида.
Многие ошибки в коде не всегда очевидны или проявляются непосредственно. Некоторые могут стать заметными только при определенных условиях или при взаимодействии с другими системами. Именно поэтому крайне важно подходить к процессу разработки ответственно, обращая внимание на детали и проводя глубокое тестирование. Недоразумения, поспешность или пренебрежительное отношение в разработке могут привести к потере жизни, ущербу репутации или большим финансовым потерям.
В заключение: каждая написанная нами строка кода имеет значение. Будь то масштабный медицинский проект или небольшое приложение для локального предприятия, последствия нашей работы ощущаются, и мы должны осознавать свою ответственность.
Заключение
В эпоху цифровизации, когда многие аспекты нашей жизни тесно связаны с программным обеспечением, ответственность перед конечным пользователем стоит на первом месте для каждого разработчика. Каждая строка кода и каждое решение в процессе разработки могут оказать влияние на благосостояние и даже физическое здоровье людей.
Ответственность разработчика не заключается лишь в создании функционирующего продукта. Она также включает в себя гарантирование безопасности, надежности и корректности работы продукта в различных ситуациях и условиях.
С учетом этого, нам, разработчикам, следует осмыслить свои приоритеты: стоит ли действительно экономить на времени разработки или на тестировании, рискуя безопасностью пользователей? Не лучше ли иногда уделить дополнительное время проверкам, чтобы гарантировать высокое качество продукта?
Пользователи доверяют нам свои данные, задачи и, иногда, свою жизнь. Давайте оправдывать это доверие, внимательно относясь к качеству своей работы и осознавая последствия своих решений.
Комментарии (29)
NutsUnderline
09.10.2023 09:40+2Замечательное эссе, не хватает подписи "Ваш КО". По сути то правильно, а по факту - уходит в совсем другие причины. а про печальный результат мы здесь прочитаем и обсудим..
MAXH0
09.10.2023 09:40+9НО, кто те 9 человек, что добавили пост в закладки? Кто нибудь может мне объяснить? Возможно я, как неспециалист, упустил рациональное зерно...
Что то мне подсказывает, что просто выполняется план по валу. И это еще хорошо, если так. На Хабре, в последнее время, и более странные вещи происходят.
ihouser
09.10.2023 09:40+8кто те 9 человек, что добавили пост в закладки?
Сам, три друга и пять любовников.
MAXH0
09.10.2023 09:40+3А я думал, что автор и 8 троллей :)
НО уже счетчик сдвинулся...ihouser
09.10.2023 09:40Родня подключилась :)
"Какой умненький мальчик, уже статьи на хабре постис. Далеко пойдет."
NutsUnderline
09.10.2023 09:40Справедливости умненьких мальчиков хвалить нужно, материал даже и такого уровня скомпилировать может далеко не всякий
saege5b
09.10.2023 09:40+1Как уже ранее говорили, в закладки закидывают не ради статьи, а ради коментариев "потом".
DrZliden
09.10.2023 09:40+6Но осознаем ли мы всегда глубокую ответственность, которую это несет? Наши решения определяют функционирование всего: от банковских систем до медицинских устройств.
Жаль что мы редко что-то решаем, по факту есть менеджеры и заказчики, которые обычно там сами решают как, что должно выглядеть работать, и за сколько мы должны по их мнению это сделать. Ещё могу и технологии сами выбрать и сказать так вот надо. А я за это должен нести ответственность, нафиг.
Но как часто мы, разработчики, задаем себе вопросы о качестве своего продукта? Сколько раз мы возвращаемся к своему коду, чтобы оптимизировать его, даже если он уже "работает"?
Мне уже новых фич накидали, все возвращения за мой счёт. А послезавтра проект вообще закроют и всё будет смыто в унитаз. Ну и какой смысл.
Наши пользователи доверяют нам. Они полагаются на наш продукт, на наш код. Они ожидают, что все будет работать без сбоев и ошибок. Каждый раз, когда мы жертвуем качеством ради скорости, мы рискуем потерять это доверие.
Каждый раз когда я жертвую скоростью ради качества, я рискую огрести люлей за срыв сроков. И эти пользователи давят на сроки, ноют о том что срочно вчера нужна фича, и что мне делать 12 часов вместо 8 работать. Конец немного предсказуем.
Но не менее важно помнить, что мы создаем продукты для людей. И каждый уголок кода, который мы пишем, влияет на их опыт использования, безопасность и удовлетворенность.
Очень много людей создают проект для денег. Моя цель чтобы вышестоящее руководство было радо. Когда оно довольно, я получаю премии. А оно бывает радо и когда пользователю плохо и он хочет ещё вот такую фичу, и готов за неё заплатить вот столько денег. Внедри я её раньше, пользователь рад конечно, но я огребаю.
Но что если из-за ошибки в коде дозировка лекарства, которая была указана в формате "10.0 мг", изменилась на "100 мг
А если чуть чуть не ленится то можно былобы найти вот это(https://habr.com/ru/companies/pvs-studio/articles/307788/) и не выдумывать гипотетические случаи.
В эпоху цифровизации, когда многие аспекты нашей жизни тесно связаны с программным обеспечением, ответственность перед конечным пользователем стоит на первом месте для каждого разработчика.
Да вообще не стоит никак, сбойнет у него морской бой, или три кристала в ряд не так отработаеют, а может птичка на тап не отреагирует и он впилится ей в трубу, или фотка не дойдёт до инстограмы, и ничего с ним не случится. Ну может матернется да и всё. Вот он эффект.
стоит ли действительно экономить на времени разработки или на тестировании, рискуя безопасностью пользователей?
Оно у меня не бесконечное, и его очень даже мало. Или вы мне лично предлагаете тратить?
starlet86
09.10.2023 09:40+1И что же, если вы видите в коде ошибку, которая принесет кучу проблем в будущем, но с большой вероятностью уже не вам, вы будете делать вид, что ее нет, лишь бы вас не трогали? Если мы программисты не будем говорить о проблемах, то как бизнес о них узнает? Если мы не будем доказывать, что нам надо время на качественную работу, то нам его никто и не предложит. Поэтому последние годы и лепится г..но на скорую руку практически везде.
DrZliden
09.10.2023 09:40вы будете делать вид, что ее нет, лишь бы вас не трогали?
Очень зависит от ситуации, скорей всего уведомлю вышестоящих руководителей, пусть они решают, что делать.
Если мы программисты не будем говорить о проблемах, то как бизнес о них узнает?
Когда придёт время узнает, а если не узнает то проблемы и небыло.
Если мы не будем доказывать, что нам надо время на качественную работу, то нам его никто и не предложит.
А мне от этого хорошо или плохо?
Поэтому последние годы и лепится г… но на скорую руку практически везде.
Но ведь бизнес это устраивает.
starlet86
09.10.2023 09:40Очень зависит от ситуации, скорей всего уведомлю вышестоящих руководителей, пусть они решают, что делать.
Вот, вы в большинстве случаев ответственный человек, который всё-таки отнесет проблему на уровень выше. За свои 15+ лет в профессии я много раз видела то, что называется пассивная агрессивность или по-простому - халатность, когда проблемы осознанно замалчиваются и специально закапываются поглубже, пока не всплывут в экстренном порядке.
А мне от этого хорошо или плохо?
На работе вас отдельно нет, есть команда, идущая к цели. Если каждый будет думать только про себя, то один будет пирожки есть, другой - в игры играть вместо того, чтобы работать :)
А вообще у вас хорошие ответы, соответствующие современному положению дел. Оттого и печально.
DrZliden
09.10.2023 09:40За свои 15+ лет в профессии я много раз видела то, что называется пассивная агрессивность или по-простому — халатность, когда проблемы осознанно замалчиваются и специально закапываются поглубже, пока не всплывут в экстренном порядке.
Это всё не просто так появилось. Зачастую это всё нарабатывается годами. Ты нашёл сказал, начальство повесило эту работу на когото, на другие задачи срезали время. Итог вроде сделал хорошее дело, а либо ты либо коллеги оказались в дерьме. Пару таких раз, и думаешь, а нафиг оно мне надо, всплывет экстренно, экстренно пофиксят, но инициатор этого эксренного уже не ты. А может когда оно всплывет, ты вообще будешь в отпуске, или уже на другой работе.
На работе вас отдельно нет, есть команда, идущая к цели. Если каждый будет думать только про себя, то один будет пирожки есть, другой — в игры играть вместо того, чтобы работать :)
Вот честно мне не хочется кривить душой, я скажу честно. Я сначала думаю о себе, потом о команде и куда она идёт. Если я не думаю о себе, то кто обо мне подумает. Не на работе я тоже могу много пафосных вещей говорить о том что мы команда, итд.
А вообще у вас хорошие ответы, соответствующие современному положению дел. Оттого и печально
Я бы сказал даже противно а не только печально. Но, пока выход непонятен.
pyrk2142
09.10.2023 09:40Жаль что мы редко что-то решаем, по факту есть менеджеры и заказчики, которые обычно там сами решают как, что должно выглядеть работать, и за сколько мы должны по их мнению это сделать. Ещё могу и технологии сами выбрать и сказать так вот надо. А я за это должен нести ответственность, нафиг.
Лично я вообще никогда не сталкивался с тем, чтобы кто-то из менеджеров явно говорил, что надо делать плохо, сроки важнее. Возможно, у других людей все иначе, но я такого не видел.
Да, были ситуации, когда менеджмент хочет быстрее, но это ситуации больше похожие на "Вы готовы сделать это быстрее? Что для этого нужно? Готовы ли работать больше? К чему это приведет?" А многие разработчики, к сожалению, воспринимают это как давление и необходимость делать плохо, так как бизнес требует.
И самое интересное, что потом, на других встречах, бизнес совершенно искренне говорит, что они не понимают, почему в проекте все так плохо, они готовы были дать разработчикам все нужное, им подтвердили сроки, а в итоге получился плохой продукт.
Но, надо признать, что чаще проще сделать плохо, чем объяснять, почему это плохо, к каким последствиям это приведет.DrZliden
09.10.2023 09:40Лично я вообще никогда не сталкивался с тем, чтобы кто-то из менеджеров явно говорил, что надо делать плохо, сроки важнее.
Никто никогда не скажет делай плохо, это могут быть намеки из разряда сейчас надо сделать чтобы, что то показать а поооооооотом сделаем как надо. Скроки важней никто тоже не скажет, просто надо сдать во второй неделе ноября иначе мы теряем заказ, а так сроки вообще не важны но ко второй неделе ноября.
Вы готовы сделать это быстрее?
Есть известный график с тремя кружками, в котором есть быстро, качественно, и недорого. И чтобы стало быстро то либо либо убираем качество, либо убираем "недорого". Обычно "недорого" убирать дорого, вот и пришли к тому что убирать.
Что для этого нужно?
Иногда для этого нужны инструменты, и когда их дают это действительно имеет результат. Но бывает что руководство вместо покупки KVM в серверную, сказало админам что сделает тумбочку на колесиках, если им так трудно таскать 14 дюймовый трубочный монитор.
Готовы ли работать больше? К чему это приведет?
Чтобы корова меньше ела и давала больше молока, её надо меньше кормить и чаще доить. Так вот чтобы быть готовым больше работать надо как минимум больше платить, что уже обычно никого не радует. И второе иметь на это возможность. Не, работать 12 часов вполне возможно, но не долго и потом нужен отдых, а главное на 3-4 такой марафон ты начинаешь понимать, что а нахрен оно не надо.
воспринимают это как давление и необходимость делать плохо, так как бизнес требует.
Потому что на предложение дать денег и улучшить условия труда, бизнес часто реагирует негативно, воспринимая это как давление.
И самое интересное, что потом, на других встречах, бизнес совершенно искренне говорит, что они не понимают, почему в проекте все так плохо, они готовы были дать разработчикам все нужное, им подтвердили сроки, а в итоге получился плохой продукт.
А пост фактум, все всегда на всё готовы причем совершенно искренне, менеджеры поехали на бали, директора в дубай, админы пошли таскать 14' монитор.
Но вообще и сроки можно было добавить, и денег. Но уже когда всё окончено, а вот начнется следующий проект и все вернется на круги своя, сдать надо в декабре, денег нет, ну что вам трудно лишние 4 часа поработать, вам все равно делать нечего....Но, надо признать, что чаще проще сделать плохо, чем объяснять, почему это плохо, к каким последствиям это приведет.
Именно. Проще, удобней и без проблем. В противном случае ты ещё можешь отдуваться за то, что сильно много инициативы проявлял.
Kahelman
09.10.2023 09:40+6Автор посмотрел-бы глазами как софт для промышленного ПО пишут. Это вам не он-Лайн магазин- копию на докерах не поднимешь чтобы протестировать. :) там куча большого железа которое как-то с чем-то взаимодействует. А автор про какие-то гипотетические случаи вещает. День даже интернет прошерстить и найти описание как не смотря на все тесты и контроли качества спутники не туда летят и ракеты падают из-за программных ошибок. Если искать лень- вот например ссылка https://www.bbc.com/future/article/20150505-the-numbers-that-lead-to-disaster
А вы про какие-то лекарства с какой-то дозировкой которая вдруг изменится. Она не вдруг, а 100% изменится, потому что у одного на компе европейские настройки а у другого американские 1.000,00 vs 1,000.00
А данные в итоге в систему из Excel импортировали. А вы специалист не умел в Date Time with Timezone, а поскольку данные вводили в Европе а сервер стоял в Америке, то вообще непонятно когда и что произошло …
Explorus
09.10.2023 09:40+2Ожидал увидеть что-нибудь про SDLC, SAST... про что-нибудь, что призвано противостоять проблемам. Проблемы, кстати, толком тоже не раскрыты. Статья, как минимум, требует доработки.
quandisti
09.10.2023 09:40+3В статье с таким кликбейтным названием и параграфом "пример из медицинской сферы" ожидаешь увидеть как минимум [уже пережеванный на хабре](https://habr.com/ru/companies/vk/articles/370153/) пример с Therac-25, а как максимум -- упоминания стандартов разработки типа MISRA, AUTOSAR с разбором каких-нибудь конкретных рекомендаций, а это... :(
starlet86
09.10.2023 09:40Да ладно ругать автора, тема-то важная на самом деле. Может какой-нибудь такой же умненький или не ещё очень мальчик, увидев именно эту статью, поймет, что несёт ответственность за свою работу, а не просто пришел денег получать.
Но статью надо доработать! Что очень не понравилось:
1)Были уже в нашем мире и случаи гибели людей, и падения космических аппаратов и т.д. Зачем что-то представлять, если настоящие примеры можно привести.
2) Упор на тестирование как на важнейший атрибут. Но оно не освобождает от ответственности никого. Например, бизнес аналитиков, которые могут создать неверные требования, ведь разработчики и тестировщики часто действуют по принципу "у меня в ТЗ так написано, значит пусть так и будет"
selivanov_pavel
09.10.2023 09:40Качество продукта. хоть софта, хоть какой-нибудь железяки, регулируется не чувством ответственности пилящего этот продукт мальчика или девочки, а исключительно требованиями менеджмента. Начиная от критериев набора мальчиков и девочек и заканчивая требованиями к надёжности продукта.
Существуют методологии создания надёжных продуктов, даже всякие стандарты. Но надёжные вещи стоят дороже и делаются дольше, вне зависимости от мастерства конечного исполнителя. А мы уже заказчику пообещали выкатить 9000 новых фич вот прям щас.
Когда 737 Max посреди полёта внезапно начинает идентифицировать себя как пикирующий бомбардировщик - проблема не в том, что кто-то написал код, в котором критичная функция полагается на показания единственного датчика. Проблема в том, что для написания кода был нанят самый дешёвый аутсорс, и не были наняты достаточно квалифицированные люди, отвечающие за надёжность.
starlet86
09.10.2023 09:40Так ответственность не только у мальков и девочек должна быть, но у менеджеров и бизнеса. Тут уровни ответственности просто разные: у одних - все тесты написать, которые им утвердили, а не спать полдня, а потом копипастом не глядя хреначить, а у других - квалифицированный персонал нанять, а не с соседями по двору договариваться.
selivanov_pavel
09.10.2023 09:40А статья перекладывает всю ответственность на конечных исполнителей:
крайне важно подходить к процессу разработки ответственно ... каждая написанная нами строка кода имеет значение
В то время как на самом деле надёжность продукта зависит в первую очередь от выстроенного рабочего процесса и от степени приоритета требований к качеству по отношению к требованиям скорости разработки.
starlet86
09.10.2023 09:40Вы абсолютно правы про настроенные процессы. Но это статья все же из песочницы, для мальчиков и девочек, которым ещё до процессов ой как далеко. Но я в корне не согласна, что им не надо думать про ответственность за свою работу и валить все на менеджера. Опять же разные уровни ответственности. Да с выстроенными процессами плохой код просто не пройдет ревью, но это опять же не повод писать как придется в надежде, что прокатит. Каждый винтик в механизме важен.
Конечно, написана статья слишком высокопарно что ли... Но зато дискуссия-то пошла в комментах прямо радует :)
konst90
09.10.2023 09:40+2Потому что всё, что делает человек, убивает людей.
Плохие детали. Плохое обслуживание. Нарушение технологии изготовления или монтажа. Ошибки при работе. Ошибки при проектировании. Неучтённое сочетание факторов. Неучтённые внешние воздействия. И так далее, и так далее.
И да, в том числе плохой код.
ksbes
09.10.2023 09:40+1Да даже просто повышение пенсий (напиваются на радостях) или снижение реальной пенсии (кому-то перестаёт на лекарства) - приводят к смертям.
Если вы пишите или делаете что-то, затрагивающее миллионы людей - кто-то от этого умрёт.
MAXH0
Я просто в "восторге" от щедрости НЛО. Статья с тривиальными фразами о пользе тестирования дает человеку инвайт на Хабр... Инфляция того, что было раньше.
Да. Я признаю, что бурчу по старчески. НО мне реально обидно.
akardapolov
Очевидные вещи про пользу тестирования для одних не всегда являются такими для других (процент уточнять не будем). Лучше еще раз повторить и поднять эту тему, в целом вектор правильный и про качество и как сохранить баланс со скоростью разработки фичей и проч.. Проблема то существует. Не понимаю в чем ужас-ужас. Можно в комментариях дополнить про граничные условия, когда тесты не получается написать или они не нужны для некоторых типов проектов.
>>по старчески
Видел тут рекламу выступления струнного оркестра с хором на произведения Короля и Шута. И мне почему-то стало смешно :), когда я ярко представил как они будут петь "Ели мясо мужики". Дамы в строгих таких платьях на своих скрипках смычками туда-сюда - "ели мясо мужики, пивом запиваали" и хор такой "о чем конюх говорил, они не по ни мали". Вот она - старость.
Exosphere
Иногда НЛО проще позволить автору ошибиться, а другим - учиться на его ошибках. Думаю, вы замечали такие шалости. А так в целом мы до сих пор даже слишком жёстко отсеиваем - просто никто из пользователей никогда не видел модераторскую Песочницу ;-)