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

Разработчик мобильных приложений

Отправить сообщение

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

Хм... а вдруг этот модуль можно было ещё на 15-20% быстрее сделать?
Вы бы на всякий случай отложили заначку, а то вдруг другой программист сделает быстрее и придётся возвращать деньги заказчику.

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


Статья забавная, тут не поспоришь, но порой удивление автора вызывает не меньшее удивление.

Откуда он знает, что человек имел в голове

Никак не узнает. Но и скобочки тут тоже не помогут.

Это скорее доказательство того, что используемый инструмент (интерпретатор) неисправен или что знания команды недостаточны для использования этого инструмента.


В первом случае нужно починить/заменить инструмент, во втором — следовать заветам дедушки Ленина.
А обмазывание скобками это заметание проблемы под ковёр.


UPD: Ну и кстати, для некоторых ЯП есть статические анализаторы, которые умеют отлавливать всякие неочевидные вещи. Очень рекомендую.

Всё ещё не понимаю, как это относится к бизнесу. Вместо условного "2 + 2 × 2" с таким же успехом мог быть не менее трудно отлавливаемый NPE или ещё какая дичь.


В любом случае, это повод провести пост мортем, пересмотреть процессы/правила линтера/используемый интерпретатор/etc, чтобы такого не повторилось и двигаться дальше. И всё это на уровне команды разработки — бизнесу по-прежнему нет дела до ваших интерпретаторов и линтеров.

Из ваших уст звучит так, будто принятое правило откровенно плохое, а ваше решение несомненно лучше.
Напомню контекст, мы сейчас говорим о правилах code style (вроде расстановки запятых или отступов). Так вот в этом контексте унифицированное правило однозначно лучше — хотя бы потому что не позволяет появиться мусорным изменениям в гите и не создаёт предпосылок для отклонения PR по этим причинам на ревью.


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


Насчёт "за ваши деньги любую дурость" не согласен — бизнесу вообще нет дела до ваших линтеров, это внутреннее дело разработчиков и решаться оно должно внутри команды.


Ну и кстати, "всегда иметь основание сказать "а я ведь предупреждал!" — не самое главное.

Есть мнение, что стоит придерживаться принятых в команде code style, даже если они лично вам не нравятся.
Да, эти правила можно изменить, от каких-то вообще отказаться, но пока они действуют — им нужно следовать.

А когда наступает это волшебное время для ревью и рефакторинга в вашей модели?
Есть все основания полагать, что после


быстрее выпустить MVP и получить обратную связь

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

А если предположить, что "умник" действительно умник, без кавычек, и предлагает более хорошее (по каким-то критериям) решение, то всё ещё не нужно?


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

Может они ожидали, что вы сами будете нарезать задачки?

Для таких вещей придумали линтеры.
Достаточно один раз договориться в команде и настроить правило линтера — с этого момента вопросы о запятых/переносах/etc возникать не будут.

Так-то оно так, но я пока не нашёл простого способа сделать это из Flutter.
Буду благодарен за пример.

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

Это может быть, например, генерация RSA ключей (или любая другая криптография).

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

Под мобилки или десктоп — есть такая возможность.
С Flutter for Web немного сложнее: там нет нативных дартовых изолятов (что-то типа тредов в других языках), но можно попытаться использовать родные для веба Web Worker.
Правда я пока не научился этому кунг фу.

Это зависит.
Обычно производительности PWA хватает, но вот такие числодробилки перевариваются плохо.
Если у вас как раз такая ситуация и WASM не помогает, то стоит задуматься над тем, а точно ли нужны эти вычисления на клиенте?

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


Логично предположить, что и этот Mojo должен уметь в дженерики — раз уж он умеет использовать питонячий код, который может их содержать.

Язык активно развивается, ничего удивительного — и хорошо, что развивается.
1
23 ...

Информация

В рейтинге
3 416-й
Зарегистрирован
Активность