Как стать автором
Обновить

Комментарии 28

мы просто убираем возможность пропустить этот скрин

Не пользовался Баду и его производными, но дайте угадаю: в истории изменений в сторах вы пишете что-то в духе «исправили ошибки, повысили производительность»? Знаете, вот как-то совсем не хочется обновлять приложение, когда оно такое пишет. Или тупо копирует этот текст из предыдущей/последней значимой версии. А вдруг я обновлю и оно начнёт у меня тормозить? Или пропадёт понравившаяся мне фича?

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

С одной стороны, довольно понятное опасение, такое, действительно, бывает, что в приложении появился баг или пропала понравившаяся фича. С другой стороны, всегда приходится искать компромисс между поддержкой старого кода и написанием нового. Как мне кажется, мы нашли довольно разумный компромисс: обязательное обновление включается для приложений, выпущенных примерно полгода назад, и только в том случае, если телефон поддерживает это обновление (иногда без апгрейда версии iOS или Android нельзя поставить новую версию приложения, а далеко не все производители телефонов обновляют прошивку до последних версий OS). Для таких пользователей мы делаем исключение и не показываем блокер.


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

А что насчёт истории версий?
С историей версий мы начали работать относительно недавно, раньше у нас в аппсторе всегда было написано Bugs and improvement fixes, теперь появился человек, который тестирует различные формулировки в истории и их влияние на основные метрики.

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

* Мы релизим новые версии каждую неделю, и зачастую окончательное понимание, что именно едет в релиз, возникает только в день релиза. А нам нужно ещё перевести историю изменений на несколько десятков языков, что сильно бы замедлило релиз.
* Часть изменений не появляются сразу для всех пользователей. Как Данил указал в статье, часть функций управляется с сервера либо A/B тестируется, соответственно мы не можем объявлять о том, что появилась новая функция, пока не включим ее для всех пользователей. Это довольно сложно контролировать и синхронизировать (нужно чтобы информация о завершенных A/B тестах и включенных на определенную страну фичах появлялась в релизе, который едет в момент раскатки теста или фичи), плюс это не совсем честно: функциональность может зачастую появиться в приложении даже без обновления, если например вы были в контрольной группе теста и вдруг тест раскатили на 100%.

В целом я согласен, что видеть в истории изменений только Fixed bugs and improved performance довольно грустно, но пока мы не можем себе позволить выделить достаточно ресурсов для решения всех перечисленных проблем.

Мы релизим новые версии каждую неделю, и зачастую окончательное понимание, что именно едет в релиз, возникает только в день релиза.
А нельзя ли немного тормознуть, и в релиз фичи пускать с «опозданием» на неделю? Чтобы можно было составить план «в релизе ТОЧНО не будет таких-то фич, хоть они и готовы». Да, список изменений будет намного меньше, но он будет точнее.
А нам нужно ещё перевести историю изменений на несколько десятков языков, что сильно бы замедлило релиз
Думаю, краткое описание на английском (одно предложение в 2-3) сэкономило бы кучу времени и не сильно бы расстроило пользователей.
Часть изменений не появляются сразу для всех пользователей. Как Данил указал в статье, часть функций управляется с сервера либо A/B тестируется, соответственно мы не можем объявлять о том, что появилась новая функция, пока не включим ее для всех пользователей
Аналогично, можно или не писать эти фичи вообще, или помечать как «экспериментальные», мол, возможно, у Вас будет, а возможно и нет.
В целом я согласен, что видеть в истории изменений только Fixed bugs and improved performance довольно грустно
Это не просто грустно, а достаточно раздражающе, т.к. зачастую (я рад, если не у вас!) это сообщение-отписку можно смело переводить как «добавили больше телеметрии и больше рекламы», увы.
А действительно исправленные bugs зачастую остаются незамеченными, и improved performance вот вообще не ощущается. И вот сидишь, как дебил, читаешь это сообщение и думаешь: ну и что же изменилось?
И вот сидишь, как дебил, читаешь это сообщение и думаешь: ну и что же изменилось?

Никто не скажет вам что изменилось. Обратите внимание на то, что было сказано выше:


раньше у нас в аппсторе всегда было написано Bugs and improvement fixes, теперь появился человек, который тестирует различные формулировки в истории и их влияние на основные метрики

Я понимаю это так: "у нас есть метрики, мы будем на них воздействовать посредством changelog". Соответственно, там может вообще не быть ни слова про сделанные изменения, если это не влияет на метрики. Другими словами: содержимое changelog определяют метрики, а не изменения.


P.S. Имхо: подобные приложения стоит расценивать как интерфейсы, у которых есть только одна версия — актуальная.

P.S. Имхо: подобные приложения стоит расценивать как интерфейсы, у которых есть только одна версия — актуальная.
Так вот откуда мода втюхивать «приложения», которые на деле оказываются всего лишь браузером с одним сайтом, по браузеру на сайт.
А нельзя ли немного тормознуть, и в релиз фичи пускать с «опозданием» на неделю?

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

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

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

Итак, «оставание» у нас будет всегда ровно на неделю (не более), по сравнению с тем, если бы мы планировали только один релиз, без его «замораживания».

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

Если быть честным, то причины почему мы не хотели делать автоматику были описаны :)
В целом прошло время и сейчас есть понимание, что можно сделать автоматику на удаление тоже, и не то чтобы это большая задача, но все равно остаются причины оставить пока как есть:
  • во-первых это все равно надо проверять. У нас есть замороженный функционал, который может не работать на бою, но поддерживается работоспособность автотестами. и `заморозка` введена по продуктовым или стратегическим причинам
  • во-вторых, пока не было большой потребности в этом — разве только ради тех задачи для фана

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

В целом ты прав и спорить бессмысленно. Но как говорится «дьявол в деталях».
Если это поддержка core частей и библиотек, то мертвый код сильное зло. Если мы говорим про продуктовый код, с которыми мы и сталкиваемся в основном, то он может как увеличить стоимость разработки новых фичей, так и дать козырь быстрой разработки, если часть наработок уже есть.
Пока мы пошли по компромиссному решению не делать автоматику, удовлетворившись полученным профитом. Вполне допускаю, что в будущем будем делать и ее, но пока потребности в этом нет.
В Badoo за всё время существования компании накопилось больше 5,5 млн строк логического бизнес-кода без учёта пустых строк и закрывающих скобок.
Так а насколько в итоге удалось сократить код в результате чистки неактуального?
Стало на 1600 строк кода больше. Так как появилось ещё и это расширение.
ха! код расширения брать в расчет не стоит, он же не на php
Если говорить про php, то чуток ошиблись. Функционал клинапа точно внес новый код в репу, а именно такие: 3640 lines, 36 files, 175 methods
а уж сколько нелогического…
комментарии в коде не пишите и отступы между блоками строк не ставите!? ;)
Хороший вопрос, и у меня нет красивого и правильного ответа.
Можно посчитать сколько кода было удалено в ветках по автоматическим тикетам. Но нельзя на все ветки. Многие стараются удалять лишнее по ходу разработки нового связанного функционала в продуктовых задачах. Так же могут инициироваться рефакторинги, и тут подсветка в IDE призвана помогать понять что должно быть удалено.

По итогу кода стало явно не меньше: штат растет, количество нового функционала тоже.
Автоматику для удаления кода, как я уже ответил выше, мы не делали.

В целом весь код у нас поделен на компоненты. Каждый файл принадлежит одному компоненту. И в дашборде мы показываем для каждого компонента статистику по размеру кодовой базы для компонента и какой процент из этого потенциально неиспользуемый. Дальнейшее решение, что с этим делать, лежит за ответственными по компоненту (кроме автоматических тикетов по A/B тестам и поддержки флагов).
Очень крутая штука, но затащить в проект может только кто-то уровня Badoo, наверное

Вот вам и php. В языках применяемых в вебе изначально промышленного уровня (java/c#) искать входящие функции и их использование — кратно проще.

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


Как c#/java помогают с решением такой задачи?

Очевидно же:


  • составить полное дерево API
  • включить на нём семплинг (автор всю статью тосковал о сложности сделать это)
  • запустить это всё в работу.

Ну т.е. не было бы "надо изменять код", "-20% производительности сервера" и прочего подобного. Как вам кажется, оно стоит того?


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

Не бойтесь удалять нерабочий код, система контроля версий о нём не забудет!
Народная программистская мудрость. ;-)

Иногда удаление не удобно, т. к. не видно эти строки в Blame и они не находятся поиском по всем исходникам, а иногда это нужно.

НЛО прилетело и опубликовало эту надпись здесь
«мертвого кода» полно в виде кучи js/css и большинству мягко говоря наплевать, по наблюдениям яндекс метрики (на разных проектах) время парсинга js/css на смартфоне приближается к времени на пк. Года 3 назад разница была больше.

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

А почему нельзя было закрыть Баду, и перезаписать и проверить код

Зарегистрируйтесь на Хабре , чтобы оставить комментарий