мой вам совет по поводу презентации - важно: люди слушают оратора или "читают" презентацию -> картинки и тезисы на экран + рассказать голосом по пунктам, так чтобы рассказ дополнял все остальное
Basil_Dev, плюс в том, что ни один вменяемый человек, которому нужно решить бизнес задачу не хочет копаться в чужом коде библиотеки и искать какие же параметры принимает тот или иной метод (вспоминая себя), и почему "вдруг" не сработало приведение типов или почему ошибка возникла на этапе выполнения при каких либо краевых случаях. И уж тем более программист хочет копаться в документации вычитывая все тоже самое. Если говорить оглядываясь на статистику, то до 70% всего времени разработки уходит на отлавливание ошибок.
Таким образом написав заранее типы часть ошибок можно существенно сократить и сократить время на поддержку. Да в TS есть порог входа, и оно того стоит, поскольку большинство разработчиков работает с чужим кодом. Если это реально пет-проект, то вам не надо заморачиваться над этим так как большая часть картины у вас в голове, но никак не в голове другого разработчика который может придти за вами.
Грубо говоря - программирование, это умение разбить на логические блоки, правильно назвать, и скомпоновать все это вместе - что крайне сложно. Если даже страдает это все сразу - то TS позволяет видеть что идет на вход и на выход и легче рефакторить и манипулировать сущностями.
представьте что вы фрилансер которого хотят нанять за почти бесплатно... обычно все узкие места можно рассматривать с такой позиции поставив себя на место других. из дельного могу посоветовать нанять контрактников через ИП, что в итоге выйдет немного выгоднее
Как человек с большим опытом, скажу честно что не читал эти подписи с картинками из СССР. Что могу посоветовать - думать сразу на 5-10 лет вперед и работать над этими планами, поскольку относительно большие зарплаты (это очевидно почти при любом сравнении) и относительная свобода (сравните с графиком какого нибудь сторожа и привязанностью его к компании) и безответственность как рядовой единицы (как сказали ниже код писать не жизни спасать) расслабляют очень многих. Думать только единицами написания кода очень глупо и бесперспективно, все что вы себе придумаете в планах на 5-10 лет реально выстроить как и везде, даже более реально чем прогрессировать из сторожа или кого то еще, поскольку отрасль постоянно растет и возможности растут. Резюмируя есть большая разница между плыть заменяемым планктоном по течению и построить свой корабль.
да обычно чужой труд ведь ничего не стоит, не то что вы сами делаете что то за деньги не правда ли? 15 в час - это мало за специалиста многие спецы даже разговаривать с вами не будут за эти деньги, сравнение с историей про Уатта (99 долларов за то что знаешь куда бить)
> адский труд, куча ежедневных уроков
ну это же вы наверно про себя?
важно: компонентный подход подразумевает (барабанная дробь) компоненты! (модули)
например: App, LoginPage, LoginForm - вам стоит подумать что именно за данные и параметры на всех 3 уровнях, если четко придерживаться контекста, то вы избежите массу проблем. Например уровень приложения не должен знать о временных данных в форме и наоборот если например был неудачный вход в систему и вам нужен тот же самый емейл для восстановления пароля в другой форме
разработчикам это не нужно - в этом и прелесть, менеджер должен как то это "продать" и мотивировать и показывать зачем разработчикам и компании это нужно но никак не менеджеру
Смысла никакого в этом нет. Это не архитектура а полуфабрикат. Главный вопрос: что хотели получить в итоге?
Судя по описанию - React SSR вместо twig, данные из window - это норм практика, например, для redux-store, возможна оптимизация под СЕО за счет динамического рендеринга части страниц, динамические компоненты.
основная идея SSR - простой рендеринг, рендеринг c последующей динамикой и отложенный рендеринг после загрузки данных, так что если убрать php-twig-react прослойку то все выглядит "хорошо"
надо четко понимать что почти везде есть легаси и "местные" правила в которые надо въехать, только небольшой процент разработчиков будет задавать тон в разработке - отсюда куча библиотек. все то нужно сказать на собеседовании - это то что не работал, но готов изучить все что понадобится
мой вам совет по поводу презентации - важно: люди слушают оратора или "читают" презентацию -> картинки и тезисы на экран + рассказать голосом по пунктам, так чтобы рассказ дополнял все остальное