Под прошлым постом много кто описал как можно обосраться с мобилкой, чтобы компании финансово было больно. Не сказать, что примеры сильно пугают, однако я давно не делал полезных постов, поэтому… Разбираем инженерные практики как сделать так, чтоб если даже вы повторили путь разбов AGP (сделали на релизе полную херню) минимизировать риски и не обанкротить компанию.

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

1️⃣ уровень – фича тоглы.  Подход заключается в том, что новые фичи или какие-то изменения мы закрываем флагом, например тупо boolean.  Этот флаг у нас периодически обновляется через API. Далее через бэк мы можем открыть функциональность, когда в ней уверены. Прикол в том, что мы можем открыть не у всех пользователей, а только у части и посмотреть как пойдет. Идет криво – быстро ее закрываем и фиксим, идет нормально – увеличиваем процент пользователей. Однако есть изменения, которые не закроешь флагом. Например, какой-то глобальный рефакторинг. Тогда на сцену выходит:

2️⃣ уровень – канареечные релизы ?. Суть омерзительно проста, мы не раскатываем новую версию приложения сразу на 100% пользователей, а используем подход фича тоглов. Раскатили на 5%, подождали, посмотрели как пошло, затем на 30%, ну далее до 100%. Если происходит какая-то херня, мы вероятнее всего ее успеем отловить на первых 10%. И даже если там что-то невероятно критичное, это заденет лишь малую часть пользователей. Да больно, но что хуже отрубить палец или голову?

3️⃣ Если же, мы совсем боимся, то добавляем третий уровень – бета. В основном этот способ используют медиа приложения, но теоретически подходит всем. Тут прикол в том, что мы сначала раскатываем приложение на ограниченную группу пользователей, которые сами захотели в этом поучаствовать. Они берут на себя риски того, что у них все может вылетать и баговать, но получают новый функционал раньше. Мы же получаем возможность протестить функционал на реальных пользователях еще до релиза. Сложность в том, что если у нас например банковское приложение и мы как-то задели бабки путь даже и пользователей беты. Регулятору будет похер и придется отвечать, поэтому с этим тоже аккуратнее.

Ну и разумеется самое прекрасное тут в том, что эти методы можно комбинировать. Что значит, если хотим спать по ночам как младенцы, мы можем раскатывать приложение на бету постепенно. Пока раскатываем на бету, открываем фича флаг только для части пользователей и все время мониторим. 

Можно ли при таком подходе проебаться? Разумеется да, проебаться можно во всем, уж поверьте мне, я в этом профи! Однако вероятность этого снижается настолько, насколько это возможно.

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

Вот например история одного разраба, который пилил свой open source и никого не трогал. По стечению обстоятельств, он в своей тулзе по умолчанию указал свой приватный бакет в S3. Если вдруг не знаете что такое, S3 – то можно представить что это огромных размеров директория, куда можно складывать файлы через API. Когда его программа начала пользоваться популярностью, все клиенты дружно начали стучаться в этот закрытый бакет. Оказывается AWS вполне непрочь, взять за тебя бабки, даже за неавторизованный доступ.

Еще раз, бакет закрытый, доступ есть только у конкретного пользователя, однако если в этот бакет кто-то начинает ломиться, Amazon все равно списывает за такие запросы бабки. В итоге чуваку выставили счет 1500$. Справедливости ради, AWS решили пофиксить эту проблему, а то теоретически узнав бакет конкурентов, можно задешево скушать их бюджет.

Вот другая история, в которой гугл случайно удалил облако целой блять компании, вместе со всеми бэкапами. Благо разрабы компании оказались достаточно умны, чтобы не доверять гуглу и хранили бэкапы в другой системе, благодаря чему быстро восстановились. Там еще ответ гугла был в стиле: "Мы дичайше просим прощения, это повторится!" Представьте если бы разрабы доверяли гуглу полностью? Это же все, это конец бизнеса!

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

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

Может у вас есть истории когда ваша ошибка на мобилке привела к финансовым потерям?

Вы, случайно, не мобильный разработчик? Тогда откуда для вас такой оффер?

18 и 19 мая пройдет Mobile Weekend Offer в Тинькофф. Для iOS- и Android-разработчиков с опытом от 3 лет.

Вот что будет:

— пройдете все этапы собеседования за выходные;
— познакомитесь с командой;
— если все хорошо, получите оффер на неделе. уже в воскресенье.

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

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

— Я смешно кринжую на дейликах;
— Расскажу про 10 элегантных способов сделать утечку памяти;
— Помогу вам вырасти как специалисту (но это не точно...).

Чтобы попасть именно в мою команду, выбирайте "Тинькофф Бизнесс". Оставьте заявку до 15 мая.

#реклама
Реклама. АО «Тинькофф Банк», ИНН 7710140679

Пока я пишу посты, хочу поделиться с вами интересным наблюдением того, как работает самопрезентация и реклама в нашей сфере. Последнее время я пытаюсь где-то выступать, знакомится с людьми и вообще переставать быть воробушком социофобушком. Когда я рассказываю о себе, своем канале и работе, основным тезисом всегда является моя ненависть к gradle. И я это делаю не в ироничном контексте, я правда рот топтал задачи связанные с gradle и стараюсь держаться от него подальше. 

Однако что слышат люди вокруг: "ооо, этот парень смешно психует про gradle, наверняка профи". Два рандомных человека пришли ко мне с консультацией по gradle, да вы чо блять? С одной стороны такая заметность приятна, с другой, я не прям мега гуру по gradle, чтобы решить любую проблему, так еще по gradle. Это буквально самая последняя вещь в программировании в которую я бы хотел погружаться. И самым крутым достижением при работе с gradle, я считаю тот факт, что еще не разбил свой рабочий ноут.

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

```
@Test
public void turnOnLoTempAlarmAtThreashold() {
hw.setTemp(WAY_TOO_COLD);
controller.tic();
assertTrue(hw.heaterState());
assertTrue(hw.blowerState());
assertFalse(hw.coolerState());
assertFalse(hw.hiTempAlarm());
assertTrue(hw.loTempAlarm());
}

```

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

@Test public void turnOnLoTempAlarmAtThreshold() { wayTooCold(); assertEquals("HBchL", hw.getState()); }

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

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

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

Я тут слегка пропал, по причине того, что моя критика кода, медленно выросла в целый рофельный доклад на прошлой неделе. На весь доклад в сумме я убил часов 16. Где 6 часов это основная работа, а остальные 10 – боль от мучительных воспоминаний о чистом коде. Это было локальное мероприятие, но надеюсь в этом году я лишусь докладческой девственности и уже выступлю хоть на какой-то конфе.

Идем дальше, а дальше у нас объекты и структура данных. Вот тут вообще глава начинается с такой штуки, которая повлияла на целое поколение Java разработчиков. На меня, в том числе. Я уже упоминал, что немного работал бекендером на Java, и вот на бэке принято делать такие классы как DTO. Просто объекты для отправки результата, мы на мобилки такие делаем когда хотим получить какие-то данные от бэка.

DTO классы всегда делались с методами. Задумайтесь об этом на пару минут: есть класс, он используется исключительно для передачи данных, по факту он просто структура.  Однако мы для доступа к данным все равно делаем геттеры, даже если значения не меняются (т.е final)  и даже если нет никакой логики.

И вот только думая над этим сейчас, я не могу ответить себе на вопрос нахуя? После того как я попробовал go, python, typescript, kotlin я не могу понять, нахера джависты страдали и продолжают страдать этой херней? Почему нельзя напрямую к полю обратиться? Да например в kotlin под капотом как бы генерятся методы, но как часто вы в data классах вы getter подменяете на что-то другое?

И возможно я ошибаюсь, но складывается такое ощущение, что это эта дичь с книги Мартина и пошла. Мы решаем выдуманную проблему, а вдруг нужно будет реализацию подменить в поле. Знаете сколько раз мне такое пришлось делать? 0 раз. А знаете сколько такое нужно было сделать коллегам по бэку? Ответ вы уже знаете.

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

Мало того, что мы делаем лишние методы, он в книге еще и предлагает все интерфейсом закрывать. Поняли да, типо не класс Point, а интерфейс Point и потом еще реализация PointImpl...

Ну ладно, все что я написал выше уже давно не проблема. В kotlin мы и так обращаемся к полям напрямую (ну почти), а в современной java появились record те же data class из kotlin. Радует что развитие языков убивает странные практики.

Мне казалось это очевидно, но видимо стоит пояснить всем кто есть в канале. Любая реклама сомнительного характера в обход меня как админа канала, сразу будет удалена, а кто такую рекламу постит отправляется навечно в бан.

Вы можете прикладывать ссылки на свои проекты в github, или ссылки на статьи и видосы. Однако реклама всяких халтур или вакансий в комментах под запретом, давайте вы не будете охеревать!