«этод метод лучше, потому что в нем меньше строчек» — это эвристический критерий, и да, он гуманитарный.
А вот цикломатическая сложность — уже нет, считается однозначно и выражает, например, количество ветвлений в коде (меньше тестов для покрытия, меньше branch prediction miss => лучше перфоманс — сплошные объективные показатели).
Я вернусь к вопросу «в каком месте?» и дальше нам придется заняться выяснением того, что такое «программирование» и решать являются ли декомпозиция и формализация техническими практиками или гуманитарными. Мне очевидно, что техническими и к «гуманитарной» части программирования они мало относятся, хотя имеют прямое отношение к восприятию кода.
Речь то про java и final. Про const и js я ничего не писал.
Проблема в том, что компиляторы действительно могут определить, что переменная не меняется в одном потоке. Более того, они могут посчитать, что если переменная не меняется в одном потоке и явно не помечена как final или volatile, то ее можно всячески оптимизировать, инлайнить и реордерить.
Справедливости ради, в java, о которой речь, такая лямбда не скомпилируется.
Но ведь никто не мешает положить в переменную ссылку на объект и менять там что угодно.
Или работаете над созданием системного ПО, промышленной системы, которая используется на более чем 1 500 000 рабочих мест и работает на всех платформах?
Просто это немного разная специфика и требует разного подхода к работе.
Нет там никакой специальной специфики. И вопрос про график разработчиками внутри самой 1С поднимается регулярно, благо там уже есть люди работающие по индивидуальным графикам или вообще удаленно. Просто компания большая, консервативная и неповоротливая.
В общем-то, и ужасов, которые возникает в голове при упоминании «фиксированного графика» там нет, все вопросы легко решаются если предупредить за день, штрафов и санкций за опоздания нет.
Пока вы измеряете знания и скилл в языках и фреймворках — вы останетесь вечным миддлом. Независимо от того фуллстек вы, бэкендер, фронтендер или еще какой -ендер.
Учите фундаменталку, «нинужные» алгоритмы и вот это вот все — и будет вам счастье.
Я, конечно, глупее вас, и первый раз слышу, чтобы extends употреблялось по отношению к методам в контексте наследования (и не extension method'ам, которые вообще про другое), а не классам.
UPD Я вот сейчас погуглил, нашел такую формулировку только в одной единственной статье про C# в MSDN.
И о чем дальше спорить?
А вот цикломатическая сложность — уже нет, считается однозначно и выражает, например, количество ветвлений в коде (меньше тестов для покрытия, меньше branch prediction miss => лучше перфоманс — сплошные объективные показатели).
Я, пожалуй, тот самый технарь, что с тобой в этом месте целиком согласен.
Но ведь это относительно небольшая часть программирования.
В каком месте?
Проблема в том, что компиляторы действительно могут определить, что переменная не меняется в одном потоке. Более того, они могут посчитать, что если переменная не меняется в одном потоке и явно не помечена как final или volatile, то ее можно всячески оптимизировать, инлайнить и реордерить.
Но ведь никто не мешает положить в переменную ссылку на объект и менять там что угодно.
А как же initialization safety?
А можно пример компилятора, который в силах определить, что переменная может поменяться из соседнего потока?
А как изменится рейтинг если спросить мечтают ли сотрудники JetBrains уйти на работу в Demis Group (или в Совкомбанк, ага) и наоборот?
Нет там никакой специальной специфики. И вопрос про график разработчиками внутри самой 1С поднимается регулярно, благо там уже есть люди работающие по индивидуальным графикам или вообще удаленно. Просто компания большая, консервативная и неповоротливая.
В общем-то, и ужасов, которые возникает в голове при упоминании «фиксированного графика» там нет, все вопросы легко решаются если предупредить за день, штрафов и санкций за опоздания нет.
Несмотря на это, 1С для технаря — отличная место работы за счет действительно очень интересных и уникальных задач.
Учите фундаменталку, «нинужные» алгоритмы и вот это вот все — и будет вам счастье.
Я, конечно, глупее вас, и первый раз слышу, чтобы extends употреблялось по отношению к методам в контексте наследования (и не extension method'ам, которые вообще про другое), а не классам.
UPD Я вот сейчас погуглил, нашел такую формулировку только в одной единственной статье про C# в MSDN.