Кажется у вас проблема с процессами, а не с ревью.
"Ожидание в очереди 10 часов" -- можно взять за правило, например, начинать рабочий день с проведения ревью. Тогда среднее время в худшем случае будет 8 часов. Можно придумать ещё какие-то соглашения.
"львиная доля времени senior'а тратится ... на наведение красоты" -- что мешает таки настроить один раз линтеры и статические анализаторы, чтобы больше не тратить это время?
"львиная доля времени senior'а тратится ..." -- есть мнение, что выполнять ревью могут не только сеньоры. Если не делать их узким горлышком, то они и не будут тормозить разработку.
"Среднее время жизни PR 2.5 дня" -- опять таки, возможно это специфика конкретных стеков/проектов/команд. Потому что так не везде -- особенно, если стремиться делать небольшие PR.
"Чистое время работы на PR 45 минут" -- см. предыдущий пункт. Если подавляющее число PR состоит из 3-5 файлов, с пятком изменений в каждом, то и ревью обычно требует меньше времени.
Первую часть статьи читал с интересом. Но когда началась навязчивая реклама вашего продукта, желание читать дальше сильно поубавилось. Примерно так же было и в предыдущих статьях.
Кстати, я правильно понимаю, что последний созвон в 22:00, после которого вы написали заявление, был в YouGile?
Знаю, что это перевод, но всё равно напишу: на rust есть довольно любопытный движок Fyrox, он выглядит более зрелым инструментом, по сравнению с Bevy (в частности, из коробки есть весьма функциональный редактор).
Хм... а вдруг этот модуль можно было ещё на 15-20% быстрее сделать? Вы бы на всякий случай отложили заначку, а то вдруг другой программист сделает быстрее и придётся возвращать деньги заказчику.
Есть ощущение, что примерно половина названных проблем характерна и для других языков программирования (в том числе — статически типизированных) или не является проблемой на самом деле (если человек уже знаком с этими концепциями). А вторая половина — наследие языка с долгой историей.
Статья забавная, тут не поспоришь, но порой удивление автора вызывает не меньшее удивление.
Это скорее доказательство того, что используемый инструмент (интерпретатор) неисправен или что знания команды недостаточны для использования этого инструмента.
В первом случае нужно починить/заменить инструмент, во втором — следовать заветам дедушки Ленина.
А обмазывание скобками это заметание проблемы под ковёр.
UPD: Ну и кстати, для некоторых ЯП есть статические анализаторы, которые умеют отлавливать всякие неочевидные вещи. Очень рекомендую.
Всё ещё не понимаю, как это относится к бизнесу. Вместо условного "2 + 2 × 2" с таким же успехом мог быть не менее трудно отлавливаемый NPE или ещё какая дичь.
В любом случае, это повод провести пост мортем, пересмотреть процессы/правила линтера/используемый интерпретатор/etc, чтобы такого не повторилось и двигаться дальше. И всё это на уровне команды разработки — бизнесу по-прежнему нет дела до ваших интерпретаторов и линтеров.
Из ваших уст звучит так, будто принятое правило откровенно плохое, а ваше решение несомненно лучше.
Напомню контекст, мы сейчас говорим о правилах code style (вроде расстановки запятых или отступов). Так вот в этом контексте унифицированное правило однозначно лучше — хотя бы потому что не позволяет появиться мусорным изменениям в гите и не создаёт предпосылок для отклонения PR по этим причинам на ревью.
Для продуктивности команды такое решение лучше и если члены команды не могут прийти к консенсусу, то вариант с волевым решением считаю приемлемым.
Насчёт "за ваши деньги любую дурость" не согласен — бизнесу вообще нет дела до ваших линтеров, это внутреннее дело разработчиков и решаться оно должно внутри команды.
Ну и кстати, "всегда иметь основание сказать "а я ведь предупреждал!" — не самое главное.
Есть мнение, что стоит придерживаться принятых в команде code style, даже если они лично вам не нравятся.
Да, эти правила можно изменить, от каких-то вообще отказаться, но пока они действуют — им нужно следовать.
А если предположить, что "умник" действительно умник, без кавычек, и предлагает более хорошее (по каким-то критериям) решение, то всё ещё не нужно?
Ну и кстати, чтобы не попасть в такую ситуацию, можно перед началом выполнения задачи обсудить с коллегами решение — что-то вроде ревью результатов проектирования.
Для таких вещей придумали линтеры.
Достаточно один раз договориться в команде и настроить правило линтера — с этого момента вопросы о запятых/переносах/etc возникать не будут.
Всё это зависит от ограничений конкретного приложения — почему выбираются те или иные решения.
В любом случае, история не про криптографию, а про поиск обходного решения возникшей проблемы (которое может пригодиться кому-то ещё).
Да, с момента появления этой статьи утекло много воды и с тех пор некоторые вещи я делаю уже по-другому:)
Наверное надо как-нибудь написать римейк (с учётом полученного опыта), заодно рассмотреть озвученные вами вопросы. Но пока я не готов называть конкретные сроки.
Под мобилки или десктоп — есть такая возможность.
С Flutter for Web немного сложнее: там нет нативных дартовых изолятов (что-то типа тредов в других языках), но можно попытаться использовать родные для веба Web Worker.
Правда я пока не научился этому кунг фу.
Это зависит.
Обычно производительности PWA хватает, но вот такие числодробилки перевариваются плохо.
Если у вас как раз такая ситуация и WASM не помогает, то стоит задуматься над тем, а точно ли нужны эти вычисления на клиенте?
Кажется у вас проблема с процессами, а не с ревью.
"Ожидание в очереди 10 часов" -- можно взять за правило, например, начинать рабочий день с проведения ревью. Тогда среднее время в худшем случае будет 8 часов. Можно придумать ещё какие-то соглашения.
"львиная доля времени senior'а тратится ... на наведение красоты" -- что мешает таки настроить один раз линтеры и статические анализаторы, чтобы больше не тратить это время?
"львиная доля времени senior'а тратится ..." -- есть мнение, что выполнять ревью могут не только сеньоры. Если не делать их узким горлышком, то они и не будут тормозить разработку.
"Среднее время жизни PR 2.5 дня" -- опять таки, возможно это специфика конкретных стеков/проектов/команд. Потому что так не везде -- особенно, если стремиться делать небольшие PR.
"Чистое время работы на PR 45 минут" -- см. предыдущий пункт. Если подавляющее число PR состоит из 3-5 файлов, с пятком изменений в каждом, то и ревью обычно требует меньше времени.
Первую часть статьи читал с интересом. Но когда началась навязчивая реклама вашего продукта, желание читать дальше сильно поубавилось. Примерно так же было и в предыдущих статьях.
Кстати, я правильно понимаю, что последний созвон в 22:00, после которого вы написали заявление, был в YouGile?
Знаю, что это перевод, но всё равно напишу: на rust есть довольно любопытный движок Fyrox, он выглядит более зрелым инструментом, по сравнению с Bevy (в частности, из коробки есть весьма функциональный редактор).
Хм... а вдруг этот модуль можно было ещё на 15-20% быстрее сделать?
Вы бы на всякий случай отложили заначку, а то вдруг другой программист сделает быстрее и придётся возвращать деньги заказчику.
Есть ощущение, что примерно половина названных проблем характерна и для других языков программирования (в том числе — статически типизированных) или не является проблемой на самом деле (если человек уже знаком с этими концепциями). А вторая половина — наследие языка с долгой историей.
Статья забавная, тут не поспоришь, но порой удивление автора вызывает не меньшее удивление.
Никак не узнает. Но и скобочки тут тоже не помогут.
Это скорее доказательство того, что используемый инструмент (интерпретатор) неисправен или что знания команды недостаточны для использования этого инструмента.
В первом случае нужно починить/заменить инструмент, во втором — следовать заветам дедушки Ленина.
А обмазывание скобками это заметание проблемы под ковёр.
UPD: Ну и кстати, для некоторых ЯП есть статические анализаторы, которые умеют отлавливать всякие неочевидные вещи. Очень рекомендую.
Всё ещё не понимаю, как это относится к бизнесу. Вместо условного "2 + 2 × 2" с таким же успехом мог быть не менее трудно отлавливаемый NPE или ещё какая дичь.
В любом случае, это повод провести пост мортем, пересмотреть процессы/правила линтера/используемый интерпретатор/etc, чтобы такого не повторилось и двигаться дальше. И всё это на уровне команды разработки — бизнесу по-прежнему нет дела до ваших интерпретаторов и линтеров.
Из ваших уст звучит так, будто принятое правило откровенно плохое, а ваше решение несомненно лучше.
Напомню контекст, мы сейчас говорим о правилах code style (вроде расстановки запятых или отступов). Так вот в этом контексте унифицированное правило однозначно лучше — хотя бы потому что не позволяет появиться мусорным изменениям в гите и не создаёт предпосылок для отклонения PR по этим причинам на ревью.
Для продуктивности команды такое решение лучше и если члены команды не могут прийти к консенсусу, то вариант с волевым решением считаю приемлемым.
Насчёт "за ваши деньги любую дурость" не согласен — бизнесу вообще нет дела до ваших линтеров, это внутреннее дело разработчиков и решаться оно должно внутри команды.
Ну и кстати, "всегда иметь основание сказать "а я ведь предупреждал!" — не самое главное.
Есть мнение, что стоит придерживаться принятых в команде code style, даже если они лично вам не нравятся.
Да, эти правила можно изменить, от каких-то вообще отказаться, но пока они действуют — им нужно следовать.
А когда наступает это волшебное время для ревью и рефакторинга в вашей модели?
Есть все основания полагать, что после
стейкхолдеры попросят проделать то же самое с новой бизнес-хотелкой.
А если предположить, что "умник" действительно умник, без кавычек, и предлагает более хорошее (по каким-то критериям) решение, то всё ещё не нужно?
Ну и кстати, чтобы не попасть в такую ситуацию, можно перед началом выполнения задачи обсудить с коллегами решение — что-то вроде ревью результатов проектирования.
Для таких вещей придумали линтеры.
Достаточно один раз договориться в команде и настроить правило линтера — с этого момента вопросы о запятых/переносах/etc возникать не будут.
Так-то оно так, но я пока не нашёл простого способа сделать это из Flutter.
Буду благодарен за пример.
Всё это зависит от ограничений конкретного приложения — почему выбираются те или иные решения.
В любом случае, история не про криптографию, а про поиск обходного решения возникшей проблемы (которое может пригодиться кому-то ещё).
Это может быть, например, генерация RSA ключей (или любая другая криптография).
Да, с момента появления этой статьи утекло много воды и с тех пор некоторые вещи я делаю уже по-другому:)
Наверное надо как-нибудь написать римейк (с учётом полученного опыта), заодно рассмотреть озвученные вами вопросы. Но пока я не готов называть конкретные сроки.
Под мобилки или десктоп — есть такая возможность.
С Flutter for Web немного сложнее: там нет нативных дартовых изолятов (что-то типа тредов в других языках), но можно попытаться использовать родные для веба Web Worker.
Правда я пока не научился этому кунг фу.
Это зависит.
Обычно производительности PWA хватает, но вот такие числодробилки перевариваются плохо.
Если у вас как раз такая ситуация и WASM не помогает, то стоит задуматься над тем, а точно ли нужны эти вычисления на клиенте?
Так-то и питон со строгой типизацией (пусть и динамической).
И уже пару-тройку лет там можно добавлять аннотацию типов, в том числе и дженерики.
Логично предположить, что и этот Mojo должен уметь в дженерики — раз уж он умеет использовать питонячий код, который может их содержать.