ха! код расширения брать в расчет не стоит, он же не на php
Если говорить про php, то чуток ошиблись. Функционал клинапа точно внес новый код в репу, а именно такие: 3640 lines, 36 files, 175 methods
Хороший вопрос, и у меня нет красивого и правильного ответа.
Можно посчитать сколько кода было удалено в ветках по автоматическим тикетам. Но нельзя на все ветки. Многие стараются удалять лишнее по ходу разработки нового связанного функционала в продуктовых задачах. Так же могут инициироваться рефакторинги, и тут подсветка в IDE призвана помогать понять что должно быть удалено.
По итогу кода стало явно не меньше: штат растет, количество нового функционала тоже.
Автоматику для удаления кода, как я уже ответил выше, мы не делали.
В целом весь код у нас поделен на компоненты. Каждый файл принадлежит одному компоненту. И в дашборде мы показываем для каждого компонента статистику по размеру кодовой базы для компонента и какой процент из этого потенциально неиспользуемый. Дальнейшее решение, что с этим делать, лежит за ответственными по компоненту (кроме автоматических тикетов по A/B тестам и поддержки флагов).
В целом ты прав и спорить бессмысленно. Но как говорится «дьявол в деталях».
Если это поддержка core частей и библиотек, то мертвый код сильное зло. Если мы говорим про продуктовый код, с которыми мы и сталкиваемся в основном, то он может как увеличить стоимость разработки новых фичей, так и дать козырь быстрой разработки, если часть наработок уже есть.
Пока мы пошли по компромиссному решению не делать автоматику, удовлетворившись полученным профитом. Вполне допускаю, что в будущем будем делать и ее, но пока потребности в этом нет.
Если быть честным, то причины почему мы не хотели делать автоматику были описаны :)
В целом прошло время и сейчас есть понимание, что можно сделать автоматику на удаление тоже, и не то чтобы это большая задача, но все равно остаются причины оставить пока как есть:
во-первых это все равно надо проверять. У нас есть замороженный функционал, который может не работать на бою, но поддерживается работоспособность автотестами. и `заморозка` введена по продуктовым или стратегическим причинам
во-вторых, пока не было большой потребности в этом — разве только ради тех задачи для фана
По экранированию. Ты прав, что формулировка «нужно для LSD» была не совсем правильная с нашей стороны. Точнее надо было сказать «нужно было для нашей системы доставки сообщений, основанной на LSD». Самому демону это не надо, он доставит как есть. Но мы там можем доставлять сообщение не только в виде одной строки, но и в виде нескольких строк. Для этого мы экранируем при записи и ревертим при обработке и самое простое было сделать чтобы все клиенты писали одинаково.
Перестать экранировать можно опцией, если это кому-то надо будет, но пока просили мы сами себя как внутренние заказчики и потому она есть и выпиливать полностью пока не планируется.
По записи в файл. При записи маленьких кусочков будет атомарно. Но ты уже сам все тут ответил :) могу только подтвердить факт, который ты и так прекрасно знаешь, что для нас более важно экономия на CPU.
Плюс это было очень удобно для дебага посмотреть что пишется одним воркером и никто не обязывать использовать плейсхолдер для имени файла. Это просто опция :)
Возможно не до конца понял твой вопрос про автоматическое удаление неиспользуемых методов. Если мои ответы не о том, то дай знать пожалуйста. Вообще в целом мы не хотели автоматику по следующим причинам:
Нет было задачи выпиливать все и сразу. Была задача помочь разработчику не снимая с него ответственности за чистоту кода
Не хотелось захламлять код и историю репы автоматическим добавлением логирования в этот метод. Но рассматривали возможность делать это автоматом по требованию для конкретных случаев — пока не пригодилось, возможно поднимем вопрос еще раз позже
Выпиливать код хочется логическими частями подобно тому как делаются логически завершенные изменения каждым коммитом, а не хаотичными автовыпилами. Как это сделать структурировано — я пока не представляю. Если есть мысли, то буду рад твоему совету.
Ну например по ip или клиенту последних авторизаций (которые можно увидеть в профиле кстати)
Например хотмейл и яху, на сколько я знаю, иногда могут задать вопрос типа: «а ты ли это? а подтверди» да ещё может быть и с капчёй
Думаю, что у Корпорации ** точно есть свои хитрости по определению всяких уловок.
P.S. порадовало в коде авторизации:
/* Anti-spam. Want to say hello? Contact (base64) Ym90Z3VhcmQtY29udGFjdEBnb29nbGUuY29tCg== */
Если говорить про php, то чуток ошиблись. Функционал клинапа точно внес новый код в репу, а именно такие: 3640 lines, 36 files, 175 methods
Можно посчитать сколько кода было удалено в ветках по автоматическим тикетам. Но нельзя на все ветки. Многие стараются удалять лишнее по ходу разработки нового связанного функционала в продуктовых задачах. Так же могут инициироваться рефакторинги, и тут подсветка в IDE призвана помогать понять что должно быть удалено.
По итогу кода стало явно не меньше: штат растет, количество нового функционала тоже.
Автоматику для удаления кода, как я уже ответил выше, мы не делали.
В целом весь код у нас поделен на компоненты. Каждый файл принадлежит одному компоненту. И в дашборде мы показываем для каждого компонента статистику по размеру кодовой базы для компонента и какой процент из этого потенциально неиспользуемый. Дальнейшее решение, что с этим делать, лежит за ответственными по компоненту (кроме автоматических тикетов по A/B тестам и поддержки флагов).
Если это поддержка core частей и библиотек, то мертвый код сильное зло. Если мы говорим про продуктовый код, с которыми мы и сталкиваемся в основном, то он может как увеличить стоимость разработки новых фичей, так и дать козырь быстрой разработки, если часть наработок уже есть.
Пока мы пошли по компромиссному решению не делать автоматику, удовлетворившись полученным профитом. Вполне допускаю, что в будущем будем делать и ее, но пока потребности в этом нет.
В целом прошло время и сейчас есть понимание, что можно сделать автоматику на удаление тоже, и не то чтобы это большая задача, но все равно остаются причины оставить пока как есть:
Перестать экранировать можно опцией, если это кому-то надо будет, но пока просили мы сами себя как внутренние заказчики и потому она есть и выпиливать полностью пока не планируется.
Плюс это было очень удобно для дебага посмотреть что пишется одним воркером и никто не обязывать использовать плейсхолдер для имени файла. Это просто опция :)
Например хотмейл и яху, на сколько я знаю, иногда могут задать вопрос типа: «а ты ли это? а подтверди» да ещё может быть и с капчёй
Думаю, что у Корпорации ** точно есть свои хитрости по определению всяких уловок.
P.S. порадовало в коде авторизации:
/* Anti-spam. Want to say hello? Contact (base64) Ym90Z3VhcmQtY29udGFjdEBnb29nbGUuY29tCg== */