Comments 30
Я просто в "восторге" от щедрости НЛО. Статья с тривиальными фразами о пользе тестирования дает человеку инвайт на Хабр... Инфляция того, что было раньше.
Да. Я признаю, что бурчу по старчески. НО мне реально обидно.
Очевидные вещи про пользу тестирования для одних не всегда являются такими для других (процент уточнять не будем). Лучше еще раз повторить и поднять эту тему, в целом вектор правильный и про качество и как сохранить баланс со скоростью разработки фичей и проч.. Проблема то существует. Не понимаю в чем ужас-ужас. Можно в комментариях дополнить про граничные условия, когда тесты не получается написать или они не нужны для некоторых типов проектов.
>>по старчески
Видел тут рекламу выступления струнного оркестра с хором на произведения Короля и Шута. И мне почему-то стало смешно :), когда я ярко представил как они будут петь "Ели мясо мужики". Дамы в строгих таких платьях на своих скрипках смычками туда-сюда - "ели мясо мужики, пивом запиваали" и хор такой "о чем конюх говорил, они не по ни мали". Вот она - старость.
Иногда НЛО проще позволить автору ошибиться, а другим - учиться на его ошибках. Думаю, вы замечали такие шалости. А так в целом мы до сих пор даже слишком жёстко отсеиваем - просто никто из пользователей никогда не видел модераторскую Песочницу ;-)
Замечательное эссе, не хватает подписи "Ваш КО". По сути то правильно, а по факту - уходит в совсем другие причины. а про печальный результат мы здесь прочитаем и обсудим..
НО, кто те 9 человек, что добавили пост в закладки? Кто нибудь может мне объяснить? Возможно я, как неспециалист, упустил рациональное зерно...
Что то мне подсказывает, что просто выполняется план по валу. И это еще хорошо, если так. На Хабре, в последнее время, и более странные вещи происходят.
Но осознаем ли мы всегда глубокую ответственность, которую это несет? Наши решения определяют функционирование всего: от банковских систем до медицинских устройств.
Жаль что мы редко что-то решаем, по факту есть менеджеры и заказчики, которые обычно там сами решают как, что должно выглядеть работать, и за сколько мы должны по их мнению это сделать. Ещё могу и технологии сами выбрать и сказать так вот надо. А я за это должен нести ответственность, нафиг.
Но как часто мы, разработчики, задаем себе вопросы о качестве своего продукта? Сколько раз мы возвращаемся к своему коду, чтобы оптимизировать его, даже если он уже "работает"?
Мне уже новых фич накидали, все возвращения за мой счёт. А послезавтра проект вообще закроют и всё будет смыто в унитаз. Ну и какой смысл.
Наши пользователи доверяют нам. Они полагаются на наш продукт, на наш код. Они ожидают, что все будет работать без сбоев и ошибок. Каждый раз, когда мы жертвуем качеством ради скорости, мы рискуем потерять это доверие.
Каждый раз когда я жертвую скоростью ради качества, я рискую огрести люлей за срыв сроков. И эти пользователи давят на сроки, ноют о том что срочно вчера нужна фича, и что мне делать 12 часов вместо 8 работать. Конец немного предсказуем.
Но не менее важно помнить, что мы создаем продукты для людей. И каждый уголок кода, который мы пишем, влияет на их опыт использования, безопасность и удовлетворенность.
Очень много людей создают проект для денег. Моя цель чтобы вышестоящее руководство было радо. Когда оно довольно, я получаю премии. А оно бывает радо и когда пользователю плохо и он хочет ещё вот такую фичу, и готов за неё заплатить вот столько денег. Внедри я её раньше, пользователь рад конечно, но я огребаю.
Но что если из-за ошибки в коде дозировка лекарства, которая была указана в формате "10.0 мг", изменилась на "100 мг
А если чуть чуть не ленится то можно былобы найти вот это(https://habr.com/ru/companies/pvs-studio/articles/307788/) и не выдумывать гипотетические случаи.
В эпоху цифровизации, когда многие аспекты нашей жизни тесно связаны с программным обеспечением, ответственность перед конечным пользователем стоит на первом месте для каждого разработчика.
Да вообще не стоит никак, сбойнет у него морской бой, или три кристала в ряд не так отработаеют, а может птичка на тап не отреагирует и он впилится ей в трубу, или фотка не дойдёт до инстограмы, и ничего с ним не случится. Ну может матернется да и всё. Вот он эффект.
стоит ли действительно экономить на времени разработки или на тестировании, рискуя безопасностью пользователей?
Оно у меня не бесконечное, и его очень даже мало. Или вы мне лично предлагаете тратить?
И что же, если вы видите в коде ошибку, которая принесет кучу проблем в будущем, но с большой вероятностью уже не вам, вы будете делать вид, что ее нет, лишь бы вас не трогали? Если мы программисты не будем говорить о проблемах, то как бизнес о них узнает? Если мы не будем доказывать, что нам надо время на качественную работу, то нам его никто и не предложит. Поэтому последние годы и лепится г..но на скорую руку практически везде.
вы будете делать вид, что ее нет, лишь бы вас не трогали?
Очень зависит от ситуации, скорей всего уведомлю вышестоящих руководителей, пусть они решают, что делать.
Если мы программисты не будем говорить о проблемах, то как бизнес о них узнает?
Когда придёт время узнает, а если не узнает то проблемы и небыло.
Если мы не будем доказывать, что нам надо время на качественную работу, то нам его никто и не предложит.
А мне от этого хорошо или плохо?
Поэтому последние годы и лепится г… но на скорую руку практически везде.
Но ведь бизнес это устраивает.
Очень зависит от ситуации, скорей всего уведомлю вышестоящих руководителей, пусть они решают, что делать.
Вот, вы в большинстве случаев ответственный человек, который всё-таки отнесет проблему на уровень выше. За свои 15+ лет в профессии я много раз видела то, что называется пассивная агрессивность или по-простому - халатность, когда проблемы осознанно замалчиваются и специально закапываются поглубже, пока не всплывут в экстренном порядке.
А мне от этого хорошо или плохо?
На работе вас отдельно нет, есть команда, идущая к цели. Если каждый будет думать только про себя, то один будет пирожки есть, другой - в игры играть вместо того, чтобы работать :)
А вообще у вас хорошие ответы, соответствующие современному положению дел. Оттого и печально.
За свои 15+ лет в профессии я много раз видела то, что называется пассивная агрессивность или по-простому — халатность, когда проблемы осознанно замалчиваются и специально закапываются поглубже, пока не всплывут в экстренном порядке.
Это всё не просто так появилось. Зачастую это всё нарабатывается годами. Ты нашёл сказал, начальство повесило эту работу на когото, на другие задачи срезали время. Итог вроде сделал хорошее дело, а либо ты либо коллеги оказались в дерьме. Пару таких раз, и думаешь, а нафиг оно мне надо, всплывет экстренно, экстренно пофиксят, но инициатор этого эксренного уже не ты. А может когда оно всплывет, ты вообще будешь в отпуске, или уже на другой работе.
На работе вас отдельно нет, есть команда, идущая к цели. Если каждый будет думать только про себя, то один будет пирожки есть, другой — в игры играть вместо того, чтобы работать :)
Вот честно мне не хочется кривить душой, я скажу честно. Я сначала думаю о себе, потом о команде и куда она идёт. Если я не думаю о себе, то кто обо мне подумает. Не на работе я тоже могу много пафосных вещей говорить о том что мы команда, итд.
А вообще у вас хорошие ответы, соответствующие современному положению дел. Оттого и печально
Я бы сказал даже противно а не только печально. Но, пока выход непонятен.
Жаль что мы редко что-то решаем, по факту есть менеджеры и заказчики, которые обычно там сами решают как, что должно выглядеть работать, и за сколько мы должны по их мнению это сделать. Ещё могу и технологии сами выбрать и сказать так вот надо. А я за это должен нести ответственность, нафиг.
Лично я вообще никогда не сталкивался с тем, чтобы кто-то из менеджеров явно говорил, что надо делать плохо, сроки важнее. Возможно, у других людей все иначе, но я такого не видел.
Да, были ситуации, когда менеджмент хочет быстрее, но это ситуации больше похожие на "Вы готовы сделать это быстрее? Что для этого нужно? Готовы ли работать больше? К чему это приведет?" А многие разработчики, к сожалению, воспринимают это как давление и необходимость делать плохо, так как бизнес требует.
И самое интересное, что потом, на других встречах, бизнес совершенно искренне говорит, что они не понимают, почему в проекте все так плохо, они готовы были дать разработчикам все нужное, им подтвердили сроки, а в итоге получился плохой продукт.
Но, надо признать, что чаще проще сделать плохо, чем объяснять, почему это плохо, к каким последствиям это приведет.
Лично я вообще никогда не сталкивался с тем, чтобы кто-то из менеджеров явно говорил, что надо делать плохо, сроки важнее.
Никто никогда не скажет делай плохо, это могут быть намеки из разряда сейчас надо сделать чтобы, что то показать а поооооооотом сделаем как надо. Скроки важней никто тоже не скажет, просто надо сдать во второй неделе ноября иначе мы теряем заказ, а так сроки вообще не важны но ко второй неделе ноября.
Вы готовы сделать это быстрее?
Есть известный график с тремя кружками, в котором есть быстро, качественно, и недорого. И чтобы стало быстро то либо либо убираем качество, либо убираем "недорого". Обычно "недорого" убирать дорого, вот и пришли к тому что убирать.
Что для этого нужно?
Иногда для этого нужны инструменты, и когда их дают это действительно имеет результат. Но бывает что руководство вместо покупки KVM в серверную, сказало админам что сделает тумбочку на колесиках, если им так трудно таскать 14 дюймовый трубочный монитор.
Готовы ли работать больше? К чему это приведет?
Чтобы корова меньше ела и давала больше молока, её надо меньше кормить и чаще доить. Так вот чтобы быть готовым больше работать надо как минимум больше платить, что уже обычно никого не радует. И второе иметь на это возможность. Не, работать 12 часов вполне возможно, но не долго и потом нужен отдых, а главное на 3-4 такой марафон ты начинаешь понимать, что а нахрен оно не надо.
воспринимают это как давление и необходимость делать плохо, так как бизнес требует.
Потому что на предложение дать денег и улучшить условия труда, бизнес часто реагирует негативно, воспринимая это как давление.
И самое интересное, что потом, на других встречах, бизнес совершенно искренне говорит, что они не понимают, почему в проекте все так плохо, они готовы были дать разработчикам все нужное, им подтвердили сроки, а в итоге получился плохой продукт.
А пост фактум, все всегда на всё готовы причем совершенно искренне, менеджеры поехали на бали, директора в дубай, админы пошли таскать 14' монитор.
Но вообще и сроки можно было добавить, и денег. Но уже когда всё окончено, а вот начнется следующий проект и все вернется на круги своя, сдать надо в декабре, денег нет, ну что вам трудно лишние 4 часа поработать, вам все равно делать нечего....
Но, надо признать, что чаще проще сделать плохо, чем объяснять, почему это плохо, к каким последствиям это приведет.
Именно. Проще, удобней и без проблем. В противном случае ты ещё можешь отдуваться за то, что сильно много инициативы проявлял.
Автор посмотрел-бы глазами как софт для промышленного ПО пишут. Это вам не он-Лайн магазин- копию на докерах не поднимешь чтобы протестировать. :) там куча большого железа которое как-то с чем-то взаимодействует. А автор про какие-то гипотетические случаи вещает. День даже интернет прошерстить и найти описание как не смотря на все тесты и контроли качества спутники не туда летят и ракеты падают из-за программных ошибок. Если искать лень- вот например ссылка 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, а поскольку данные вводили в Европе а сервер стоял в Америке, то вообще непонятно когда и что произошло …
Ожидал увидеть что-нибудь про SDLC, SAST... про что-нибудь, что призвано противостоять проблемам. Проблемы, кстати, толком тоже не раскрыты. Статья, как минимум, требует доработки.
В статье с таким кликбейтным названием и параграфом "пример из медицинской сферы" ожидаешь увидеть как минимум [уже пережеванный на хабре](https://habr.com/ru/companies/vk/articles/370153/) пример с Therac-25, а как максимум -- упоминания стандартов разработки типа MISRA, AUTOSAR с разбором каких-нибудь конкретных рекомендаций, а это... :(
Да ладно ругать автора, тема-то важная на самом деле. Может какой-нибудь такой же умненький или не ещё очень мальчик, увидев именно эту статью, поймет, что несёт ответственность за свою работу, а не просто пришел денег получать.
Но статью надо доработать! Что очень не понравилось:
1)Были уже в нашем мире и случаи гибели людей, и падения космических аппаратов и т.д. Зачем что-то представлять, если настоящие примеры можно привести.
2) Упор на тестирование как на важнейший атрибут. Но оно не освобождает от ответственности никого. Например, бизнес аналитиков, которые могут создать неверные требования, ведь разработчики и тестировщики часто действуют по принципу "у меня в ТЗ так написано, значит пусть так и будет"
Качество продукта. хоть софта, хоть какой-нибудь железяки, регулируется не чувством ответственности пилящего этот продукт мальчика или девочки, а исключительно требованиями менеджмента. Начиная от критериев набора мальчиков и девочек и заканчивая требованиями к надёжности продукта.
Существуют методологии создания надёжных продуктов, даже всякие стандарты. Но надёжные вещи стоят дороже и делаются дольше, вне зависимости от мастерства конечного исполнителя. А мы уже заказчику пообещали выкатить 9000 новых фич вот прям щас.
Когда 737 Max посреди полёта внезапно начинает идентифицировать себя как пикирующий бомбардировщик - проблема не в том, что кто-то написал код, в котором критичная функция полагается на показания единственного датчика. Проблема в том, что для написания кода был нанят самый дешёвый аутсорс, и не были наняты достаточно квалифицированные люди, отвечающие за надёжность.
Так ответственность не только у мальков и девочек должна быть, но у менеджеров и бизнеса. Тут уровни ответственности просто разные: у одних - все тесты написать, которые им утвердили, а не спать полдня, а потом копипастом не глядя хреначить, а у других - квалифицированный персонал нанять, а не с соседями по двору договариваться.
А статья перекладывает всю ответственность на конечных исполнителей:
крайне важно подходить к процессу разработки ответственно ... каждая написанная нами строка кода имеет значение
В то время как на самом деле надёжность продукта зависит в первую очередь от выстроенного рабочего процесса и от степени приоритета требований к качеству по отношению к требованиям скорости разработки.
Вы абсолютно правы про настроенные процессы. Но это статья все же из песочницы, для мальчиков и девочек, которым ещё до процессов ой как далеко. Но я в корне не согласна, что им не надо думать про ответственность за свою работу и валить все на менеджера. Опять же разные уровни ответственности. Да с выстроенными процессами плохой код просто не пройдет ревью, но это опять же не повод писать как придется в надежде, что прокатит. Каждый винтик в механизме важен.
Конечно, написана статья слишком высокопарно что ли... Но зато дискуссия-то пошла в комментах прямо радует :)
Потому что всё, что делает человек, убивает людей.
Плохие детали. Плохое обслуживание. Нарушение технологии изготовления или монтажа. Ошибки при работе. Ошибки при проектировании. Неучтённое сочетание факторов. Неучтённые внешние воздействия. И так далее, и так далее.
И да, в том числе плохой код.
Да даже просто повышение пенсий (напиваются на радостях) или снижение реальной пенсии (кому-то перестаёт на лекарства) - приводят к смертям.
Если вы пишите или делаете что-то, затрагивающее миллионы людей - кто-то от этого умрёт.
Больше того, иногда смерть людей - не баг, а фича проекта. Например в случае инъекций для эвтаназии, электрических стульев или оружия. И в этих примерах отсутствие смертей было бы проблемой.
Еще очень часто смерти становятся следствием идеально работающих вещей. Пример - антидепрессанты. В психиатрии частый кейс, что человек, находящийся в сильной депрессии, часто не способен убить себя, потому что это волевое решение, а воля подавлена. Начинает принимать антидепрессанты, депрессия немного отступает и сил как раз хватает на суицид. Большинство суицидов во время депрессии случаются от того, что антидепрессант сработал.
Почему код, который мы пишем — убивает людей?