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

Инженер

Отправить сообщение
Эта ветка — лучшая иллюстрация того что статическая типизация вредна для большинства проектов.
Не бывает ничего красивого «в ваккууме». Красота — субъективная оценка обусловленная опытом. Код становится красивым не потому что его перечитывают воздыхая на полную луну.

Красивым его делает воспоминание о чём-то похожем, проработавшем 25 лет без перезапуска и ночных побудок.

Некарсивым его делает похожее решение обернувшееся предрелизной вечеринкой до 1 ночи и падением отношения dev:QA до 1 за следующие 3 месяца.
> чем человек квалифицированнее, тем он проще пишет и тем проще его код понимать другим
Смотря кому другим. Другим высококвалифицированным программистам — да. Случайным чувакам которыми хряки закрыли план — вряяядли.
Замена «бизнес» на «государство» мало меняет смысл.
Не дали хацкель в прод протащить?
Одни люди друг другу нравятся, другие не нравятся. Что с этим делать наука пока не придумала. Деды решали проблему простыми и незатейливыми фразами вроде «Мы таких как ты тут не любим», без претензий на объективность. Но в нашем пузырике эльфиская меритократия, все должно быть объективно. Поэтому говорят «ты токсичный и портишь атмосферу». Не циклитесь на словах, ищите смысл.
Твой код плохой, я сейчас подробно изложу причины и дам советы
Один сплошной бессмысленный пируэт.

Если есть конкретные проблемы надо с них начинать. Оценки можно и в конце расставить, да и мало кто расстроится если на них вообще забить.

Если есть только ощущения и задетые эстетические чувства можно перейти к изложению альтернатив.

Если конкретных проблем и альтернативных решений нет стоит жать кнопку приянть, сэкномит время коллег и деньги работодателя.
Тем что не даёт перепутать имя с почтой.

Существует мнение что функции более 3х аргументов без их явного именования мажорный тормоз при чтении кода и источник ошибок. Отсутствие поддержки именавания аргументов на стороне вызова я, например, считаю крупнейшим дефектом языка.
> Концепция важнее новых требований
Пойдёт.

> Качество важнее скорости
Надо развернуть, в чём измеряется качество и в чём скорость? Без внятных определений очередная философская херня натянутая на инженерную дисциплину.

> Делать как надо важнее, чем делать как просят
Как надо кому? Просят кто?
Что-то вспоминается сцена допроса из матрицы…
Простите пожалуйста, редко сюда заглядываю, не в курсе нюансов этикета.

А надувать щёки и рассказывать что точно знаете Правильное Значение Слова а кто не знает тот джун/студент и не имеет права писать — норм?
Нескромный вопрос, а зачем? Нормальный пакет акций или зарплата которая позволяет годик пожить на бали?
Ой, а расскажите что они таки значат?
«Модульные тесты в Rust писать настолько легко и просто, что хочется это делать снова и снова. :) Зачастую вам будет проще написать модульный тест, чем пытаться протестировать функциональность другим способом.» и тест тавтологии и 2 + 2. Серьёзно? Вам отчаяно не хватало пунктов до круглого числа или Вы реально думаете что такой пример что-то доказывает?
Не совсем, но для некоторых целей уже пойдёт.
Бабуля разве жива?
1. Реализация в ручную означает еще один способ ошибиться. Во всех программах что мне приходилось писать в них небыло недостатка.
2. «Простой» — нет. Он путает два разных объекта и два пути исполнения. Еще полезное упражнение представить что ваша предметная область аудит логов, в которых есть удачные и неудачные записи и сообщения об ошибках :)
3. «Понятный» — нет. Он даёт возможность создавать объекты с неоднозначным состоянием в которых заполнены и поля данных и поля ошибок. Нужно разрабатывать соглашение что мы с ними делаем, как ищем источник, его надо доносить до всей команды, держать в голове.
4. «Приводящий обработку ошибок к единообразному стилю» — во снах CTO возможно. В коде — это гарантия бардака.
Вы рассказываете про оконные бибилиотеки 80-90х. Все преимущества такого подхода сводятся к «это было первое что пришло в голову». В качестве альтернативы можно посмотреть на HTML, просто структура данных.

Кстати, описывать событие как метод который зовёт бибилиотека и а прикладной разработчик переопределяет — исключительно плохая идея. Это крайне затрудняет обработку сценариев о которых авторы библиотеки не подумали и отличный способ запутать построение интерфейса с реакцией на события. Например QT видели эту проблему еще в середине 90х, и несмотря на некоторую ангажированность языка сделали более функциональную систему сигналов и слотов. Пользуясь случаем хочу передать горячий привет авторам андроида :)
Node.JS научился в потоки?

Информация

В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Зарегистрирован
Активность