Thread by @mobileunderhood

День 3.5.
Фак! Up!

Друзья!
То, что мы мобильные разработчики - это не ваша вина!

Поэтому давайте поговорим про факапы. Факапы - это неотъемлемая часть нашей работы, мы ошибаемся тысячи раз.

Расскажите про ваши неудачи? То, где вы прямо ошиблись так, что аж стыдно.

Цена ошибки бывает разная, если в медицине цена ошибки зачастую человеческая жизнь, то у нас(если мы не пишем софт специальный) - это деньги.

Были ли у вас ошибки, что называется, на миллион? В какой валюте?

Я понимаю, что у всех тут NDA, мало кто ошибается, но хотя бы мелкие косяки и очень давно, я думаю(и вам советую!), можно рассказать!

Расскажу про себя для затравочки один:
Как-то раз мы делали сервис в галере, сервису на старте приходит текстовый файлик, в файлике в строгом заданном порядке данные пользователей, их мы хешировали, а после делали фильтрацию по событиям(в событиях были тоже хешированные

данные). По сути, чтобы понять, что это один и тот же человек мы сравнивали строчки-хеши. Грубо говоря, такие GUID-ы ходили.

Мы согласовали алгоритм, получили тестовый файлик и захешировали его, после чего я спокойно поехал домой.

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

- Когда надо приехать?
- Немедленно. Но лучше еще побыстрее.

В итоге, оказалось, что файлик, который мы захешировали и засунули в сервис содержал непечатные символы(BOM, в частности).

Отсюда была ошибка с пользователем.
Вот так простой маленький BOM устроил мне огромный BOOM.

Зато обратно я домой доехал на реактивной жопогорящей тяге.

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

Еще из совсем простенького, я сейчас ВСЕГДА ставлю {} скобки для if, while и прочее, крайне не люблю однострочники.
Как вы понимаете, это тоже не беспочвенно.

Как-то раз один такой if и небольшая строчка с фичей сломали нам показ проекта.

Да и в целом, чем дальше - тем больше я стремлюсь к максимальной явности.
Не знаю с чем это связано, с ошибками, которые я вечно совершаю, или со старостью, но я за все явное, пусть оно будет и многословнее и некрасивей даже.

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

Раузмеется, у меня нет этого отношения, но сейчас я стал поспокойнее к этому. Хотя не так далеко то время, когда я просыпался от того, что мне снилось, что я сделал ошибку или не то написал. Особенно, когда ответственности было много и от меня кто-то зависел.

На эту тему очень круто мы как-то поговорили с одним моим друганом из JB, который рассказал историю свою, как страшно было катить супер-фичу. Частично, кстати, это обязанность тимлида - сделать так, чтобы вы не боялись совершать ошибки.

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

Это подводит нас к таким темам как тесты и тестирование своего кода!

Скажу честно: я ненавижу тестирование и тесты.
Господи, писать все эти юнит/интеграционные ужасы - это словно дрочить в боксерских перчатках, при этом повторяя алфавит задом наперед.

Читать, кстати, тоже.

Мать моя женщина, тут переменной то или методу простому название подбираешь сидишь по полчаса, потом еще на код ревью переписывая(про это еще поговорим), а тут надо ТЕСТ описать в одну строчку.

Да еще ладно тест и название, надо же еще тестовое окружение там поднять, что-то замокать, что-то подложить, а тут еще DI со своими классами по 100500 аргументов в конструкторе, такие, что пока объект создаешь вручную туннельный синдром разовьешь.

А если разработка идет быстро, все часто меняется, области ответственности(ну в single responsibility никто не верит же?), меняются/раздуваются, то вместо одной кодовой базы проекта надо вообще поддерживать две!

И нет ничего слаще и отраднее для ушей менеджера в дедлайны услышать: "Фича готова, НАДО ТОЛЬКО ТЕСТЫ ПОПРАВИТЬ".

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

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

Но если вы так рассуждаете - вы почти наверняка ошибаетесь.

Тесты писать зачастую СЛОЖНЕЕ чем фичи и код. Но об этом мноигие забывают.

Для хорошего теста надо понимать и предметную область, и код, и уметь еще в нехилые софт скиллы, чтобы донести кому-то, что код не рабочий и надо поправить.

Здесь работа для Ведьмака!
И зачастую, когда этим ведьмаком оказывается джун, то выходит:

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

НО!

Тесты - это то самое малое зло, потому секс - это, конечно, хорошо, но вы отлавливали баг тестом?
Заранее!

Хотя я работал и на проектах, где не было ни одного теста или они не работали.

Но зачастую в таком случае можно сказать, что пока не работают тесты - работают разработчики.

А это дороже обычно.

Тесты - это хотя бы какая-то гарантия того, что у вас хотя бы что-то работает!
И что повесив очередную аннотацию на класс из StackOverflow у вас в выдаче endpoint-а не пошли пароли.

За тесты - не чокаясь!