Рубрика «quality»

На РИТ++ Никита Соболев (sobolevn) выступил, как он сам назвал это, с проповедью на тему качества кода и процессов в компании. Особо впечатлительных просим налить себе ромашкового чаю, но отойти от экранов не предлагаем. Вы можете не соглашаться ни с одним из тезисов, настаивать, что трёп о сериалах — залог здоровой атмосферы в коллективе, и утверждать, что вам не нужны строгие рамки линтера и CI, чтобы писать хороший код. Но если вы хоть раз винили окружающих в неудачах на работе, вам стоит прочитать или посмотреть рассказ Никиты.

Работали ли вы когда-нибудь на плохой работе?

Я работал и долго. Моя компания была ужасна. Все было очень плохо, за что ни возьмись — все из рук вон. У нас были отвратительные процессы, ненавистные клиенты и неумелые разработчики. С этим ничего нельзя было поделать. Когда все так плохо, просто не знаешь, за что взяться, с чего начать. Чувствуешь себя жалким винтиком, который не может ни на что влиять.

Blameless environment: никто не должен писать качественный код - 1

Когда я говорю, все плохо, я имею в виду, что у нас был:

  • плохой код — никто не думал о качестве кода, никто не мог даже сформулировать, что такое качество кода.
  • плохие процессы.
  • мы не могли нормально общаться,
  • мы не делали то, что хотел клиент.

Да, это была аутсорс-разработка, но не это делало её плохой. Люди сделали ее такой.Читать полностью »

Приглашаем на тематический митап AppsConf: QualityApps - 1

30 ноября в московском офисе Mail.Ru Group пройдёт митап, полностью посвящённый мобильному тестированию. Мы подготовили его совместно с организаторами октябрьской конференции AppsConf по многочисленным просьбам от сообщества. Программа и регистрация – под катом.
Читать полностью »

Если грубо считать качество в наработке на отказ, то понятно, что бюджеты под разные критерии разные. Как в айти, так и в нормальном производстве.

Если сковородка может сломаться через пол года, можно взять дешёвую сталь, простое покрытие и китайских рабочих. Если нужен срок жизни в десять лет, то придётся брать хорошие материалы, дорогие технологии и made in Germany.

Если мы можем игнорировать, что от сайта отваливается один пользователь из тысячи, можно быстро сварганить что-то простое. Если потеря одной финансовой транцакции грозит штрафом на пол миллиона, придётся подробно продумывать архитектуру, выбирать надёжные библиотеки и серьёзно заниматься тестированием.

Но при этом «быстро и просто» не значат «плохо».

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

И вот тут я хочу напомнить почему-то забываемый всеми момент.

Авралы, расходы и головную боль мы поимеем только тогда, когда система закрыта. Если она открыта, все эти радости достанутся кому-нибудь другому.
Читать полностью »

Маленькое предварительное замечание: Подробное объяснение потребовало бы объёмов средней книжки. Тут всё дано схематично, кратко и без подробностей. Текст, конечно, хулиганский, но прежде чем наезжать на автора, стоит учесть, что за ним стоит двадцать лет опыта и много-много литературы как классической, так и специалистам ИТ не ведомой.

Есть слово, приносящее индустрии каждый год огромные убытки. И слово это — bug.

Баги — это некие виртуальные вредоносные жучки, прячущиеся внутри программ. Они обладают собственной волей. Они проникают в самые важные участки. Они портят результаты, прерывают выполнение работы и делают другие гадости.

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

Массовая глобальная нескончаемая игра, которой увлечённо предаются практически все работники отрасли, включая тестеров, менеджмент, организаторов процессов и высоколобых теоретиков.

Почему так происходит? Потому что в индустрии совершенно превратно понимают, что такое исходный код и для чего он нужен.

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

Если сделать программиста не идеальным, получается одна интересная штука: код перестаёт быть готовым результатом. Он даже перестаёт быть результатом. И становится отражением текущего понимания программистом условий поставленной задачи и способов её решения.

Код именно отражает, а не описывает. Последнее возможно, но требует перестройки всего процесса, от форматов записи до мозгов.

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

Писать и говорить то, что думаешь, — это всегда отсутствие такта, презрение к окружающим и хамство. Если кто-то ставит в своём коде комментарий «Stupid idea. Does not work, if N < 0. Correct ASAP.», он рискует прослыть минимум странным. А вот если это попадёт в участок ответственности гениального программиста, тут уже мелкой истерикой не ограничится. Даже, если «stupid» будет подразумеваться только по контексту. Или напишите в комментарии что-нибудь типа «I do not know why this works, but otherwise the function generates an exception.» Потом покажите это начальнику и попросите повышения.

И, конечно, гораздо выгоднее говорить «Мы исправляем баги в коммуникационном модуле», а не «Читая документацию мы прошляпили несколько критических моментов и неделю будем всё с нуля переделывать.»

Ладно, оставим. Большинство такого не выдерживает. Страшно. И ронять чувство собственного достоинства тоже страшно. И лицо потерять… И начальство тоже… Короче, фиг с ним, перейдём к плюшкам.

Читать полностью »

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

Капитан Очевидность намекает: чтобы такого не допустить, важно уметь понимать, в каком состоянии находится ваш продукт на каждом этапе его развития. В этой большой статье предлагается методика оценки его состояния в самой наглядной форме – в форме таблиц и графиков. Здесь обобщен мой опыт и опыт всей команды новосибирского офиса Parallels за последние шесть лет. Чтобы было понятно: мы делаем Parallels Plesk Panel – хостинг-панель, которая используется примерно на каждом втором сервере в мире, предоставляющем услуги веб-хостинга. Применив эту методику, мы получили вот такие результаты:

  1. существенно улучшилось качество выпускаемых релизов (согласно Incident rate);
  2. релизы стали более предсказуемыми, точность наших прогнозов и оценок выросла в разы;
  3. появилось понимание, почему что-то идёт не так и как этого избежать в будущем.

Заинтересованных лиц прошу под кат и в комменты. Отвечу на любые вопросы.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js