Комментарии 7
Столько раз повторено слово "качество" а никаких примеров критериев в статье нет и в помине.. "договариваться", "разные интересы".. есть но всё же, давайте попробуем:
Переходя к программным продуктам, можно выделить следующие атрибуты качества:
функциональность;
надежность;
эффективность;
безопасность;
удобство использования.
Функциональность и .. "качество". Кмк, несколько странное сочетание, т.к. функциональность задается в основном ТЗ на тот или иной кейс, особенно что отдельно выделен п.3 - "эффективность". То есть тут или пункт избыточен вовсе или речь должна идти о качестве реализации заданного функционала в части "полноты", а не эффективности или красивости решения.. Но, неполностью реализованное ТЗ разве можно считать "выполненным"? Кмк, нет.
Надежность и "качество".. Надежность работы ПО напрямую связано с покрытием решения тестами, особенно с контролем "за" и "по" граничных решений. В идеале, каждое ветвление в функционале должно быть покрыто тестом. Каждый элемент входного набора покрыт как допустимыми, так и заграничными значениями.. Если это сделано, то надежность решения, как правило "работает годами и не требует поддержки" ибо "всё учтено могучим ураганом".. то есть, этот пункт фактически сводится к .. качеству (и количеству) тестов.
Эффективность и качество. Вот как раз тут и проявляется, кмк, "качественность" принятого решения, архитектуры данных, алгоритмов .. одно и то же ТЗ может быть решено разными способами, можно решать "в лоб", а можно взять какой-нибудь суперовый алгоритм Ухо-Пескарика и получить профит типа logN вместо O^3 "в лоб".. Но, тут возникает "дилемма" ибо далеко не каждый сеньор знаком с Ухо или Пескариком и откатывает на коде-ревью, т.к. "не качественно" в части "не понятно как это вообще работает" .. и тут мы вступаем в пропущенный пункт:
Эффективность как легкость восприятия (а есть ещё легкость сопровождения, расширяемость..). А восприятие как раз может быть самым разным, и оно у джуна, да в его первой команде - одно, у сеньора со стажем - совсем иное и то, что "тривиально" для первого, синьор ещё 100лет назад отказался применять и забыл как страшный сон.. и упс, ему снова "не понятно"!
Кмк, но это тот самый пункт где можно и нужно "договариваться" промеж коллег, вкупе с предыдущим: к чему стремимся? К эффективности по п.3 - кейс должен отрабатывать за минимальное время, иметь наименьшую сложность как алгоритмическую так и по данным (команда процессора имеет стоимость - hiload) или мы пишем "простой и понятный для джуна кот" а то что он О^3 как алгоритмически, так и по данным .. "бизнес раскошелиться на новый сервер" делов-то.. зато любой новый сотрудник разберется в процессе полета между отделом кадров при приеме на работу и кофемашиной на кухне, даже не погружаясь в транс раздумий..
Кмк, как обычно, истина где-то посередине, но возможность договариваться вижу только в этой части озвученного .. не всё озвучено, ну да ладно. И так неплохая замена статье по объему.. ;)
Ну вы из тех, кто не знает что такое качество
Да, точно! А в каком "разрезе" не знаю, можно уточнить? .. смишно..
Автор, тут я поддержу @VladimirFarshatov с его критикой. У вас статья "за всё хорошее против всего плохого", "давайте делать хорошо, а нехорошо делать не будем".
Продуктовой команде постоянно приходится балансировать между "херак-херак и в продакшен, иначе конкуренты обгонят, или клиенты уйдут" и "перерабатываем легаси, а то новые фичи в среднем впиливаются в старый код по 3 месяца", а ваша статья совсем не помогает принимать решения.
Ещё хотел затронуть пропущенный пласт "коде-ревью и качество", начиная с вопроса "А сколько времени выдается сеньору на коде ревью?" и не из-за сего ли сеньоры часто требуют dif а не полный текст метода?
Так, вставка item = New(..) может и решает проблему тикета, но .. попадает во внутренний цикл, а "умный" компилятор текущего ЯВУ вполне может (и такое сеньор знать - обязан!) воткнуть malloc(), что приведет к существенному изменению скорости исполнения .. но, видя только dif спокойно аппрувит мердж, ещё и лайк не забывает поставить автору.. Ясен пень, что потом возникнет новый тикет .. но вот что с "качеством"?
"Однако не каждый способен его четко обозначить, а тем более объяснить, как его достичь."
Вот и у вас, без ГОСТа, не получилось...
Занимайтесь тестированием, а не управлением качеством, не вводите людей в заблуждение!
Поддержу Ваш комментарий. Добавлю ссылку на стандарт по качеству https://docs.cntd.ru/document/1200121069
Качество ПО: определение и постановка целей