Статья интересная. Но сложно читать, поэтому не помешала бы сторонная редактура. А также, есть подозрение, что статься попросту не окончена, из-за последних двух слов.
«программисты» не знают как устроен компьютер и используют реакт/ангуляр /вуе и т.д. там, где не нужно/вредно
Возник вопрос: а как программисту на условном реакте поможет знание архитектуры ЭВМ? Ибо от реакта до железа нагорожена такая туева хуча абстракций, так что, чтобы понять, какой машинный код отдастся на сьедение железу, придется очень хорошо разбираться в устройстве всех этих слоев, а не только нижайшего. А следовательно, почти невозможно, учитывая ограниченность человеческих ресурсов и огромное количество альтернатив…
Откуда я делаю вывод, что такому программисту необходимо лишь среднее понимание принципов устройства того же реакта и знание хороших практик, а с остальным разберется машина (за что спасибо умным и талантливым разработчикам хороших фреймворков, умных компиляторов и т.д.)
Что-то видимо у меня не получилось донести ту мысль, что в сигнатуре очень мало информации для столь огромного количества строк кода, и этот код наверняка делает много больше заявленного, либо не делает ничего (индусский код). Если же он делает только то, что можно понять по сигнатуре, то наверняка его можно (и нужно) уместить в гораздо меньший обьем.
Т.е. принцип «код делает только то, что понятно по сигнатуре» и простыня на 1000 строк — практически несовместимы.
Хорошо, пусть будет в вашем примере не 1000 непонятных строк, а 5 *очень* непонятных строк с черной магией и прочим.
Проблема: аргх, у нас в системе опять что-то сломалось, пользователи злы и не могут работать, репутация тает
Задача: выяснить, что сломалось, почему сломалось и как быстро это исправить
Анализ: возник непредвиденный кейс, невыявленный ранее из-за сложности системы
Сопутствующая проблема: Исправить сходу не получится из-за ограничений платформы и отсутствия нужных инструментов
Сопутствующая задача: выяснить способы обхода проблемы
Сопутствующий анализ: определить наилучшее в данной ситуации обходное решение
Сопутствующее решение: реализовать решение
Решение: выкатить сопутствующее решение, устранить возможность похожих проблем в будущем.
И при таком подходе «проблема -> задача -> анализ -> решение» не возникает противоречия, а неизбежный фрустрирующий фактор сведен до минимума.
Решение:
Что врядли сильно сигнатура поможет понять, что делается в «1000 строк нечитаемого кода». Ладно бы 10, 100, но в 1000 строк наверняка попутно делается намного больше из заявленного сигнатурой. Т.е. если Вы напишете свою реализацию в 10 строк, то наверняка она не будет обладать тем же поведением, что и 1000 строк (всякие побочные действия)
Ибо 1000 строк простыни — это почти всегда очень дурно.
Возможно, к ним уже не применим термин «выгорание», т.к. они уже пришли «выгоревшими», но какое-то время отчаянно боролись между «мне это не интересно» и «но за это же платят» в постоянном компромиссе «как сделать быстро, некачественно, но чтобы мне за это ничего [плохого] не было»
В своё время ради интереса написал маленькое решение по противодействию таким программам поиска и изменения критических значений в памяти, как ArtMoney, путем хранения числа в шифрованном (а потому и избыточном) виде с методами манипуляции значением динамически.
Возможно, дело в том, что в 1С, как правило, идут программисты с заниженной планкой социальной ответственности?
Я сам (сдуру) заглядывал в исходники фреймворка от той же конторы (Битрикс) а от того, что я там увидел, меня трясет от каждого упоминания — такое впечатление, что его делали люди, которые только вчера научились включать комп, а сегодня ваяют на пхп.
15 лет назад мне было всё интересно.
Я благодарен отцу за то, что еще раньше, когда мне было 10 лет, у него получилось заинтересовать меня программированием и обучить основам бейсика на Спектруме, поэтому вопрос «кем я буду, когда вырасту» был однозначно «программистом».
Мне было интересно все, это был сумбурный подход «все интересно, во всем разобраться, все попробовать сделать самому», кладбище мертворожденных проектов тянет на отдельный мир.
Извините, а отвечая на Ваш вопрос «как стать опытным программистом если нет ни любопытства, ни желания что-то изучать» — иметь мотивацию, которую я наблюдал у младших коллег «за это хорошо платят, поэтому идем на SO, копипастим работающий код и изменяем под свои нужды»
Эх, каюсь, но подходом «не знаю как сделать — нахожу решение на SO, понимаю принцип и пишу свой код» пользуюсь и до сих пор, а то и даже «не понимаю код, что написали на SO — копирую как есть, изменяю те места, которые понимаю, но до тех пор, пока код работает»
Я все же зря написал про «простыню», мой код все же не напоминает код школьника и я даже прошел этап «мне стыдно за код, написанный несколько лет назад» — я иногда открываю свои проекты, писаные много лет назад, чтобы что-то улучшить, добавить. Смотрю — и не нахожу возможных улучшений (все же я плохой программист, да? :) )
Однако я пишу код так, что он может быть нечитаем со стороны. Например, я инлайню сложные выражения, если они используются однажды, вместо вынесения их в отдельную переменную. Также (речь про Java) раньше я ставил final и this. везде, где только можно (сейчас я так не делаю)
Т.е. меня будут ругать за то, что я не пишу
int width = innerWidth/2; // здесь может быть выражение и посложнее этого
int height = innerHeight/2;
out(width, height, text);
а пишу
out(innerWidth/2, innerHeight/2, text);
за что меня часто и ругают «непонятно, что здесь написано!»
Хмф, зато я сразу вижу возможные ошибки («а что, если аргумент будет null — все упадет с NPE», «слишком большая область видимости — руками изменят и все упадет») и пишу код так, чтобы уменьшить вероятность ошибок и неправильного обращения с обьектом.
Зато подход «сначала пишем как пишется, потом рефакторим до годного» оправдывает себя тем, что не приходится задавать вопросы «а что, если...» на раннем этапе — сначала ставится вопрос «как решить эту задачу», и когда уже PoC-код работает, переходим к рефакторингу «сделать код универсальным, сделать код безопасным»
Если внутренняя система, если по ТЗ и прочим требованиям удовлетворяет.
Реализовано? Реализовано. Быстро. Дешево.
Не нужно пилить фейсбук там, где достаточно 2 html страничек.
0: _
1: 1
2: 11
3: 111
4: 1111
5: 11111
и т.д.
вот что вики знает: Унарная система счисления
Возник вопрос: а как программисту на условном реакте поможет знание архитектуры ЭВМ? Ибо от реакта до железа нагорожена такая туева хуча абстракций, так что, чтобы понять, какой машинный код отдастся на сьедение железу, придется очень хорошо разбираться в устройстве всех этих слоев, а не только нижайшего. А следовательно, почти невозможно, учитывая ограниченность человеческих ресурсов и огромное количество альтернатив…
Откуда я делаю вывод, что такому программисту необходимо лишь среднее понимание принципов устройства того же реакта и знание хороших практик, а с остальным разберется машина (за что спасибо умным и талантливым разработчикам хороших фреймворков, умных компиляторов и т.д.)
Ох уж эти заголовки.
Между прочим, например, на Youtube давно можно отключить комментарии.
Т.е. принцип «код делает только то, что понятно по сигнатуре» и простыня на 1000 строк — практически несовместимы.
Хорошо, пусть будет в вашем примере не 1000 непонятных строк, а 5 *очень* непонятных строк с черной магией и прочим.
Проблема: аргх, у нас в системе опять что-то сломалось, пользователи злы и не могут работать, репутация тает
Задача: выяснить, что сломалось, почему сломалось и как быстро это исправить
Анализ: возник непредвиденный кейс, невыявленный ранее из-за сложности системы
Сопутствующая проблема: Исправить сходу не получится из-за ограничений платформы и отсутствия нужных инструментов
Сопутствующая задача: выяснить способы обхода проблемы
Сопутствующий анализ: определить наилучшее в данной ситуации обходное решение
Сопутствующее решение: реализовать решение
Решение: выкатить сопутствующее решение, устранить возможность похожих проблем в будущем.
И при таком подходе «проблема -> задача -> анализ -> решение» не возникает противоречия, а неизбежный фрустрирующий фактор сведен до минимума.
Решение:
Что врядли сильно сигнатура поможет понять, что делается в «1000 строк нечитаемого кода». Ладно бы 10, 100, но в 1000 строк наверняка попутно делается намного больше из заявленного сигнатурой. Т.е. если Вы напишете свою реализацию в 10 строк, то наверняка она не будет обладать тем же поведением, что и 1000 строк (всякие побочные действия)
Ибо 1000 строк простыни — это почти всегда очень дурно.
В своё время ради интереса написал маленькое решение по противодействию таким программам поиска и изменения критических значений в памяти, как ArtMoney, путем хранения числа в шифрованном (а потому и избыточном) виде с методами манипуляции значением динамически.
Я сам (сдуру) заглядывал в исходники фреймворка от той же конторы (Битрикс) а от того, что я там увидел, меня трясет от каждого упоминания — такое впечатление, что его делали люди, которые только вчера научились включать комп, а сегодня ваяют на пхп.
Я благодарен отцу за то, что еще раньше, когда мне было 10 лет, у него получилось заинтересовать меня программированием и обучить основам бейсика на Спектруме, поэтому вопрос «кем я буду, когда вырасту» был однозначно «программистом».
Мне было интересно все, это был сумбурный подход «все интересно, во всем разобраться, все попробовать сделать самому», кладбище мертворожденных проектов тянет на отдельный мир.
Извините, а отвечая на Ваш вопрос «как стать опытным программистом если нет ни любопытства, ни желания что-то изучать» — иметь мотивацию, которую я наблюдал у младших коллег «за это хорошо платят, поэтому идем на SO, копипастим работающий код и изменяем под свои нужды»
Эх, каюсь, но подходом «не знаю как сделать — нахожу решение на SO, понимаю принцип и пишу свой код» пользуюсь и до сих пор, а то и даже «не понимаю код, что написали на SO — копирую как есть, изменяю те места, которые понимаю, но до тех пор, пока код работает»
Однако я пишу код так, что он может быть нечитаем со стороны. Например, я инлайню сложные выражения, если они используются однажды, вместо вынесения их в отдельную переменную. Также (речь про Java) раньше я ставил final и this. везде, где только можно (сейчас я так не делаю)
Т.е. меня будут ругать за то, что я не пишу
а пишу
за что меня часто и ругают «непонятно, что здесь написано!»
Хмф, зато я сразу вижу возможные ошибки («а что, если аргумент будет null — все упадет с NPE», «слишком большая область видимости — руками изменят и все упадет») и пишу код так, чтобы уменьшить вероятность ошибок и неправильного обращения с обьектом.
Зато подход «сначала пишем как пишется, потом рефакторим до годного» оправдывает себя тем, что не приходится задавать вопросы «а что, если...» на раннем этапе — сначала ставится вопрос «как решить эту задачу», и когда уже PoC-код работает, переходим к рефакторингу «сделать код универсальным, сделать код безопасным»
Реализовано? Реализовано. Быстро. Дешево.
Не нужно пилить фейсбук там, где достаточно 2 html страничек.