x
 
Василий
9 августа 2018
Советы почтой каждую неделю
Пожалуйста, получите наше письмо, чтобы подтвердить свой адрес:
Вы подписаны на «Советы за неделю»:

Как бороться с багами? Часть восьмая: порефлексировать


Когда баг исправ­лен, оста­ётся поре­флек­си­ро­вать, отве­тив на два вопроса: что пошло не так и что сде­лаем, чтобы в буду­щем такого не было?

Что пошло не так?

Чтобы не допус­кать подоб­ных оши­бок в буду­щем, сна­чала надо понять, что не так в про­цессе раз­ра­ботки. Почему баг вообще появился в системе?

Чтобы отве­тить на этот вопрос, я про­хожу по списку:

  • Пони­ма­ние задачи. Что оста­лось непо­нят­ным или упу­щен­ным на этапе про­ек­ти­ро­ва­ния? Какие кра­е­вые слу­чаи мы не учли?

  • Архи­тек­тура при­ло­же­ния. Что не учли или исполь­зуем непра­вильно? Как обра­ба­ты­ваем ошибки? Как рабо­таем с сетью и сто­рон­ними сер­ви­сами? Каких огра­ни­че­ний в базе дан­ных не хватает?

  • Тести­ро­ва­ние. Были ли тесты? Почему про­пу­стили ошибку? Нет ли оши­бок в самих тестах? Каких тестов не хватает?

  • Обра­зо­ва­ние. Каких зна­ний об исполь­зу­е­мых тех­но­ло­гиях не хва­тает? Чем мы поль­зу­емся непра­вильно? Какие про­белы в наших стан­дар­тах? Что раз­ра­бот­чики не знают о том, как про­грамма эксплуатируется?

  • Люди. Нет ли про­блем с вни­ма­тель­но­стью из‑за пере­ра­бо­ток или выго­ра­ния? Нет ли про­блем с дед­лай­нами? Может, в этом про­цессе вообще не дол­жен участ­во­вать человек?

Что сделаем, чтобы в будущем такого не было?

Когда понятно в чём про­блема с про­цес­сом раз­ра­ботки, оста­ётся при­ду­мать, как её испра­вить и исправить:

В Издательстве бюро

Пер­вая вер­сия билинга непра­вильно про­дле­вала под­писки: про­дле­ние «на месяц» на самом деле про­дле­вало под­писку на 30 дней от теку­щей даты.

При­чина — пони­ма­ние задачи. Раз­ра­бот­чики по‑сво­ему поняли «под­писка про­дле­ва­ется на месяц» и не согла­со­вали, как на самом деле это должно было работать.

Чтобы в буду­щем таких про­блем не было, обнов­ляем стан­дарт, по кото­рому пишутся спе­ци­фи­ка­ции: дого­ва­ри­ва­емся все детали, каса­ю­щи­еся вре­мени и дат, опи­сы­вать раз­вёр­ну­тыми примерами:

В при­ме­рах учи­ты­ваем кра­е­вые слу­чаи: фев­раль, конец месяца, конец года

В Школе бюро

Часть сту­ден­тов, при­ня­тых на вто­рую сту­пень, не полу­чила при­гла­ше­ния, потому что у них не было актив­ных карт, при­вя­зан­ных в Бюросфере.

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

Чтобы в буду­щем таких про­блем не было, учим при­гла­ше­ния рабо­тать и без карты, учим систему сиг­на­ли­зи­ро­вать о про­бле­мах с пла­тёж­ным сер­ви­сом и нор­мально их пере­жи­вать. Допол­ни­тельно пере­про­ве­ряем дру­гие сер­висы, рабо­та­ю­щие с кар­тами: все ли из них нор­мально пере­жи­вают сбои в пла­тёж­ной системе.

В Издательстве бюро

О Педанте рассказывал Сергей Фролов в Техноведре

Книги изда­тель­ства бюро про­ве­ряет Педант. Он делает скрин­шоты раз­во­ро­тов в раз­ных бра­у­зе­рах и све­ряет их с эталонами.

О Педанте рассказывал Сергей Фролов в Техноведре

Арт‑дирек­тор нахо­дит про­блемы в вёрстке в бое­вой вер­сии книги, кото­рые Педант пропустил:

Серого фона у лей­бла точно не должно быть

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

Чтобы в буду­щем таких про­блем не было, заме­няем биб­лио­теку и пере­про­ве­ряем самого Педанта.

В Бюросфере

Такой баг — XSS, одна из самых распространённых уязвимостей сайтов. См. XSS в Википедии

В Бюро­сфере нашли баг: поль­зо­ва­тель может напи­сать ХТМЛ в тек­сте о себе, кото­рый дви­жок никак не филь­трует. Можно внед­рить любой вре­до­нос­ный код.

Такой баг — XSS, одна из самых распространённых уязвимостей сайтов. См. XSS в Википедии

При­чина — обра­зо­ва­ние. Раз­ра­бот­чики не знали о XSS и дру­гих типич­ных уяз­ви­мо­стях в вебе.

Чтобы в буду­щем таких багов не было, орга­ни­зо­вы­ваем Security Fridays. Каж­дую пят­ницу раз­ра­бот­чики раз­би­ра­ются с типич­ными уяз­ви­мо­стями в вебе: как устро­ены, как исполь­зуют, как защи­титься. В конце заня­тия раз­ра­бот­чики полу­чают домашку: допол­ни­тель­ное чте­ние по теме, зада­ние найти похо­жую уяз­ви­мость на сайте бюро и испра­вить её.

См. Brakeman

Допол­ни­тельно под­клю­чаем авто­ма­ти­че­ские лин­теры, обна­ру­жи­ва­ю­щие типо­вые уязвимости.

См. Brakeman

В Школе бюро

Всту­пи­тель­ные баллы на вто­рой сту­пени счи­та­лись вруч­ную, а раз­ра­бот­чики затем пере­но­сили их в базу дан­ных. Это зани­мало пару дней и часто при­во­дило к ошибкам.

При­чина — люди. Про­цесс под­счёта всту­пи­тель­ного балла на вто­рой сту­пени вообще не дол­жен был делать чело­век: это тупая и моно­тон­ная работа, в кото­рой легко допу­стить ошибку.

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

См., например, триллер от Злых Марсиан о замалчивании исключений внутри транзакций

Сове­тую для особо серьёз­ных багов фик­си­ро­вать такие отчёты и делиться ими в бло­гах, рас­сыл­ках и на мита­пах: дру­гие раз­ра­бот­чики научатся на чужих ошибках.

См., например, триллер от Злых Марсиан о замалчивании исключений внутри транзакций

Что запомнить

Когда баг исправ­лен, нужно поре­флек­си­ро­вать: понять, что не так с про­цес­сом раз­ра­ботки (из‑за чего баг про­со­чился?) и что сде­лать, чтобы в буду­щем таких багов не было.

Ещё по теме

P. S. Это был совет о веб‑разработке. Хотите знать всё о коде, тестах, фронтенд‑разработке, цеэсэсе, яваскрипте, рельсах и джейде? Присылайте вопросы.
Вёрстка и прототипирование — дисциплина Школы дизайнеров. Набор открыт. Чем раньше поступите, тем ниже стоимость и выше шанс на бесплатное место.
 

Поделиться
Отправить

Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры. Мы ожидаем, что такие комментарии составят около 20% от общего числа.

Решение о публикации принимается один раз; мы не имеем возможности комментировать или пересматривать свое решение, хотя оно может быть ошибочно. Уже опубликованные комментарии могут быть удалены через некоторое время, если без них обсуждение не становится менее ценным или интересным.

Вот такой веб 2.0.

Как объяснить значимость фичи разработчику? 1 Как называть классы в ЦСС. Часть первая Расскажите об обязанностях технического директора в бюро. Вторая часть: встречи один на один Как быть, если твой руководитель некомпетентнее или незаинтересованнее тебя?




Недавно всплыло

Где хранить скриншоты интерфейсных решений, чтобы было удобно искать референс? 9 Как просить коллег о помощи, как оценить код программиста, навигация между книгами бюро, как научиться спрашивать 2 Каким должно быть ресторанное меню на сайте? 1 Как улучшить запись автоответчика? 4