Стоит один раз менеджменту увидеть время, потраченное всей командой на звонки и умножить на почасовую ставку, и выводы делаются сами собой.
Были прецеденты или вы это умозрительно говорите? Могут сделать и другие выводы: не успеваешь -- твои проблемы, значит ты такой плохой разработчик, что с тобой нельзя без совещаний, оставайся доделывай после работы, задания с тебя никто не снимал.
Промпт не промпт, но в "человеческом" мире меня с некоторых пор начала забавлять ситуация, когда ТЗ по объёму превосходит сделанный на основе него код. Поэтому, мне кажется, в реальной жизни "качественные ТЗ" и встречаются настолько редко, что все о них слышали, но мало кто видел.
А не надо поддерживать, по изначальному замыслу. Просто уточняете "заклинание". "Поддерживать" теперь надо промпт, а не сгенерированный по нему код, код уходит на уровень, на котором раньше был байт-код.
Писал я на этом ассемблере 30+ лет назад, INCB занимает два байта, а BISB -- три или четыре (забыл как там с выравниванием по чётности, скорее всего таки четыре): там есть ещё аргумент -- битовая маска. Чел сэкономил программную память, судя по применению однобайтовой переменной для флага, это было актуально...
Если во время собеседований не удается выдавить ни слова, и голова пустая, что даже своими словами не объяснить, можно попросить продемонстрировать на практике.
Мне кажется, я нашёл ключевой ответ: потому что они увеличивают связность кода. Этим ответом покрывается и конкретизируется также предыдущий мой ответ. В случае гигантской монолитной (как ныне модно выражаться) библиотеки это нужно, в случае много-микро-модульной системы это создаёт лишние зависимости между модулями.
Если глобально и коротко, то потому, что подход к разработке встроенной стандартной библиотеки Java и подход к разработке прикладной коммерческой программы - разные
Дополнительная причина - что синтаксис языка Java вынуждает писать много boilerplate-кода вокруг исключений. Тут и предыдущий абзац "в строку", потому что именно в стандартной библиотеке такое терпимо и даже, по соображениям надёжности, потребно, а в прикладной программе в основном засоряет код, закапывая "основной путь" в глубине обработчиков исключений.
при использовании линтеров с кастомными правилами, настроенными на подобные кейсы
Привыкли полагаться на универсальный встроенный "линтер" под названием "статическая проверка типов", а тут вдруг его оказывается принципиально недостаточно. Ну придётся поднапрячься и настроить дополнительную проверку...
Вообще, на языке нужно программировать так, как на нем принято.
Хорошее, вроде как, замечание. Если встать в позицию школьного учителя вместо того чтоб пытаться понять, зачем оно так было "принято". Кроме того, само "принято" со временем меняется. В случае с Java это явно видно за 30 лет. Из-за этого нередко приходится "танцевать на одной ножке" для обеспечения обратной совместимости, и это в общем нормально: всё заранее уточнить и предусмотреть невозможно. Легаси, оставшееся от гениального старожила, потом окажется фактическим кривым прототипом новой функциональности языка: один раз и навсегда написать невозможно, а люди склонны упрощать себе жизнь, избегая необходимости творить копипасту.
Особенно когда в анамнезе имеется ковид с реанимацией, от которого страдают внимание и память. Крадут последние остатки внимания.
Были прецеденты или вы это умозрительно говорите? Могут сделать и другие выводы: не успеваешь -- твои проблемы, значит ты такой плохой разработчик, что с тобой нельзя без совещаний, оставайся доделывай после работы, задания с тебя никто не снимал.
Промпт не промпт, но в "человеческом" мире меня с некоторых пор начала забавлять ситуация, когда ТЗ по объёму превосходит сделанный на основе него код. Поэтому, мне кажется, в реальной жизни "качественные ТЗ" и встречаются настолько редко, что все о них слышали, но мало кто видел.
А не надо поддерживать, по изначальному замыслу. Просто уточняете "заклинание". "Поддерживать" теперь надо промпт, а не сгенерированный по нему код, код уходит на уровень, на котором раньше был байт-код.
По крайней мере это так задумано.
И те и те.
Для гироскутера нужна поверхность без уклонов, это редкость.
По-моему, это у любых аккумуляторов так.
Как раз try/catch несколько мешает. Нельзя просто так взять и выделить в функцию блок, кидающий исключения, их нужно либо объявить либо обработать.
Есть подозрение, что первую версию оборудования, под которую писался софт, просто отключали чаще чем раз в 256 использований.
Писал я на этом ассемблере 30+ лет назад,
INCBзанимает два байта, аBISB-- три или четыре (забыл как там с выравниванием по чётности, скорее всего таки четыре): там есть ещё аргумент -- битовая маска. Чел сэкономил программную память, судя по применению однобайтовой переменной для флага, это было актуально...Читал, ждал, когда у людей с такими замашками дела пойдут плохо. И таки пошли...
На практику времени не дают...
Мне кажется, я нашёл ключевой ответ: потому что они увеличивают связность кода. Этим ответом покрывается и конкретизируется также предыдущий мой ответ. В случае гигантской монолитной (как ныне модно выражаться) библиотеки это нужно, в случае много-микро-модульной системы это создаёт лишние зависимости между модулями.
Если глобально и коротко, то потому, что подход к разработке встроенной стандартной библиотеки Java и подход к разработке прикладной коммерческой программы - разные
Дополнительная причина - что синтаксис языка Java вынуждает писать много boilerplate-кода вокруг исключений. Тут и предыдущий абзац "в строку", потому что именно в стандартной библиотеке такое терпимо и даже, по соображениям надёжности, потребно, а в прикладной программе в основном засоряет код, закапывая "основной путь" в глубине обработчиков исключений.
Привыкли полагаться на универсальный встроенный "линтер" под названием "статическая проверка типов", а тут вдруг его оказывается принципиально недостаточно. Ну придётся поднапрячься и настроить дополнительную проверку...
Хорошее, вроде как, замечание. Если встать в позицию школьного учителя вместо того чтоб пытаться понять, зачем оно так было "принято". Кроме того, само "принято" со временем меняется. В случае с Java это явно видно за 30 лет. Из-за этого нередко приходится "танцевать на одной ножке" для обеспечения обратной совместимости, и это в общем нормально: всё заранее уточнить и предусмотреть невозможно. Легаси, оставшееся от гениального старожила, потом окажется фактическим кривым прототипом новой функциональности языка: один раз и навсегда написать невозможно, а люди склонны упрощать себе жизнь, избегая необходимости творить копипасту.
Из серии "каждый уважающий себя ... доложен написать свою реализацию..." (я уже два раза писал). Вопрос, почему не существует стандартной...
Технологии идут вперёд, и образование будет с неизбежностью отставать от них...
В перспективе это ведёт к "крепостному праву" и стажировкам без оплаты (или вообще с приплатой от работника)...
Как и на реальных интервью. Но рабочей альтернативы нет.