Вы сейчас предлагаете сделать из динамического статический с помощью костылей и подпорок. Так как 90% кода с которым программист имеет дело это код библиотек языка и чужих библиотек, то реализация такой проверки лишь затруднит программирования и не даст нормального эффекта. По сути, вы предлагаете усложнить динамический язык определением типа, реализовать сложный парсер и статический анализатор и по сути все равно будите получать большую часть проблем динамического языка. Смысл если можно перейти на полностью статический или комбинированный (полустатический-полудинамический) язык?
А можно в питоне что вернет функция getIsEmailCorrect(«fff@mail.ru») чужого класса, если нет документации и код внутри черт ногу сломит? Я вот по названию могу предположить что он может вернуть как boolean, так и integer (1 — корректный, -1 — не корректный), String («правильно»/«не правильно») и даже какой-то Object. Иногда можно запустить код и проверить, а если это очень сложно (код работающий с базой данных/сетью/очень много сложных аргуементов и прочее) или банально долго?
Ничего, кроме того что вы предлагаете самому написать новый статический язык с новыми правилами… По сути, вы предлагаете самому написать аналог TypeScript для JavaScript, это, конечно, возможно, но смысл?
Естестевнно, под Junior в данной статье подразумеваются программисты без опыта или с минимальным опытом
Я знаю иностранных «джуниоров», которые могут на расслабоне русских «синьоров» попустить
Значит, эти синьноры это всего лишь джуниоры с 15-летним поытом, такое бывает, особенно из-за падания в одну из «ловушек» выше.
Приведенные в статье типажи абсолютно очевидны любому, кто вообще занимается разработкой ПО
Вроде написано
Давайте вспомним некоторые типичные грабли, на которые мы все (ну или большинство) наступали сами того не замечая. Конечно, для опытных разработчиков многое покажется очевидным капитанством, однако молодых специалистов такие ловушки могут легко увести на темную сторону силы.
Поверьте, для молодого разработчика без опыта работы это все не далеко не очевидно, многое написано по собственному печальному опыту.
Короче говоря, стетейки клепать — не мешки ворочить.
Так клепайте, лучше, быстрее, веселее, какие проблемы? :)
Нет, главный совет «не ходит туда где снег на башка попадет, совсем мертвый будешь» или вовремя уйти оттуда где перестал развиваться. Дело в том, что молодому специалисту сложно распознать, что что-то не так в его первой работе и годами сидит в джунирах без всякого развития, практически не замечая этого.
Нее, вы не поняли, я не говорил что любая гос.организация это болото, в первую очередь тут речь о симптомах на которые нужно обращать внимание, если есть желания развиваться и соответственно как-то «лечить» то что вызывает эти симптомы, от ухода из такой компании до попытки сменить климат и организовать реальную работу.
Ну, тут может получиться спор по понятиям. Есть роль программиста/разработчика в проекте, есть должность программиста. Если разделать по ролям, то teamlead это тот кто мотивирует и контролирует команду, бизнес-аналитик — тот кто угадывает желания клиента и создает бизнес требования, архитектор — тот кто создает архитектуру, программист — кодить по дизайну, тестер — его проверят и т.д.
То есть в идеализированном случае роль программиста не подразумевает ни угадывать желания клиента, ни знать чем занимаются соседи. Естественно, в реальном проекте чем опытней программист и меньше команда тем больше дополнительных ролей полностью и частично ложится на его плечи, но основная роль все-таки кодирование, все остальное это уже дополнения.
Тут надо понимать простую вещь если старший программист 50% обучает и мотивирует команду, 49% придумывает архитектуру и 1% времени тратит на написание кода, то это уже Team lead/Архитектор, которого просто не оформили официально (что бывает очень часто), а не программист.
Насчет Junior и Senior, видел я очень ответственных Junior'ов и «выгоревших» Senior'ов, которые знают что их все равно никогда не уволят и зар.плату кардинально уже не повысят. Нет, Senior это все-таки интуитивное понимание как сделать правильно, а не слепое повторение чужих методик, что характерно для Middle программистов.
Ничего, кроме того что вы предлагаете самому написать новый статический язык с новыми правилами… По сути, вы предлагаете самому написать аналог TypeScript для JavaScript, это, конечно, возможно, но смысл?
Естестевнно, под Junior в данной статье подразумеваются программисты без опыта или с минимальным опытом
Значит, эти синьноры это всего лишь джуниоры с 15-летним поытом, такое бывает, особенно из-за падания в одну из «ловушек» выше.
Вроде написано
Поверьте, для молодого разработчика без опыта работы это все не далеко не очевидно, многое написано по собственному печальному опыту.
Так клепайте, лучше, быстрее, веселее, какие проблемы? :)
То есть в идеализированном случае роль программиста не подразумевает ни угадывать желания клиента, ни знать чем занимаются соседи. Естественно, в реальном проекте чем опытней программист и меньше команда тем больше дополнительных ролей полностью и частично ложится на его плечи, но основная роль все-таки кодирование, все остальное это уже дополнения.
Тут надо понимать простую вещь если старший программист 50% обучает и мотивирует команду, 49% придумывает архитектуру и 1% времени тратит на написание кода, то это уже Team lead/Архитектор, которого просто не оформили официально (что бывает очень часто), а не программист.
Насчет Junior и Senior, видел я очень ответственных Junior'ов и «выгоревших» Senior'ов, которые знают что их все равно никогда не уволят и зар.плату кардинально уже не повысят. Нет, Senior это все-таки интуитивное понимание как сделать правильно, а не слепое повторение чужих методик, что характерно для Middle программистов.