SerzN1

Просто не дорос до уровня. Это нормально. Очевидно есть задачи которые решаются на другом уровне знаний.

Говорят чтобы свободно понимать материал нужно иметь 20% нового максимум в этом материале. 80-20 правило.

Practice makes perfect.

И однозначный ответ на вопрос - нет, если только не стоит прямая задача на рефакторинг.

Поскольку это обычная вещь как недооценить сложность + возможно эта система работает в продакшене и люди работают с ней.

Тоесть вопрос о временном отключении системы вообще не стоит. Применении больших нестабильных изменениий которые могут положить систему - тоже не вариант.

Если делать все по нормальному - необходимо знать входные и выходные параметры модулей или сделать покрытие модулей под последующий рефакторинг тестами, чтобы убедиться в правильности изменений.

Я бы рекомендовал постепенные улучшения и декомпозицию. Говнокод в 1 месте, новые и отрефакторенные модули в другом.

Если критерии по доступности системы никому не интересны, то можно просто фигачить свой код как считаете нужным пока есть бюджет.

Факт 2: По результатам исследования персональных отличий лучшие программисты до 28 раз превосходят слабейших. Если учесть что их оплата труда никогда не бывает соразмерной, то лучший программист и есть самое выгодное приобретение в индустрии ПО.

Рекомендую почитать обоснование

Сходу я бы не поставил ни на одного кандидата на то что он из группы А, как по уровню знаний и опыту, так и по скорости работы и степени мотивации
Надеюсь что каждый может примерно оценить свое место на подобной шкале, но для этого нужно работать хотя бы где то рядом с такими людьми

И еще: из моего опыта и новых веяний ввиде diversity, когда берут на работу людей которые закрывают типовые задачи за втрое большее время - очень сложно объективно прицелится на этой шкале, как уже было сказано выше - нормальные программисты не будут искать так работу, скорее всего им просто нужно поставить статус "в поиске" в линкедин и через день они будут выбирать из кучи предложений, другое дело если есть интерес в какой то определенной компании

тут уже сказано и не раз - распределение задач и нагрузки является прямой задачей менеджмента, не вижу смысла расписывать остальные вещи

человек приходя на работу подписывается на ЗП в большинстве случаев и ему неважно что он делает а важна лишь мотивация - что тоже задача менеджмента как не странно звучит (ну или самого разработчика если он хочет больше)

ответ прост - инженерам это не надо - это интелектуальный труд, но можно их а) замотивировать/продать и б) автоматизировать процесс (это лучшее решение)

и при этом не имеется ввиду "Я ХОЧУ, Я РЕШИЛ, Я..."

var event = new MouseEvent('click', {
    'view': window,
    'bubbles': true,
    'cancelable': true
  });
var b = $0.dispatchEvent(event)

`$0` в данном случае текущий выделенный элемент в chrome dev.tools и вместо него можно использовать `document.getElementById` и тп

возможно имеется ввиду это видео

1 - "сложное" в вебе связано с 3D и шейдерами example

2 - возможно некоторые решения позволяющие проигрывать анимашки из других программ. как правило без вашего вмешательства в код самой анимации - все что вам нужно знать сказать кому-то где это сделать и знать куда это потом вставить и еще как оптимизировать при необходимости link

что дает одно и другое?
CSSinJS - удобное темирование, инкапсуляцию
CSS Modules - инкапсуляцию

из минусов - подход CSSinJS своеобразный сомнительный код

собственно делаем выводы - без разницы если активно не пользоваться темированием

все намного проще - это целый кусок HTML приходит в запросе на конкретную модель
`https://razmerkoles.ru/finder/search/by_model/?mak... .
можно открыть вкладку network в dev tools и убедиться в этом

На Wiki есть хорошая таблица со сравнением

Тестирование - это сложно и нужно знать куда смотреть, знать где могут быть затыки, не говоря уже о программировании.

Самое большое заблуждение это типа прокликал и готово. Поскольку есть определенные инструменты , например postman, которые лучше знать чем нет, куча девайсов как мобилки и таблеты, отчеты по производительности, автоматическое тестирование и тонны всего другого типа конкретного фреймворка в команде под тестирование... Поскольку это более монотонный труд чем творческий и тп. То порог вхождения может быть очень высокий в случае разработки качественного продукта. В противном случае тестирование могут проводить сами разработчики.

Шанс есть всегда и не надо спрашивать ничего. Если интересно, то просто надо заниматься этим знать как минимум основы, что-то подучить, где-то поэкспериментировать, взять тонкости работы конкретной команды, предложить своё решение для улучшения процесса и снижения монотонности и главное закончить задавать дурацкие вопросы типа «а смогу ли я?» на сайтах, так как это вопрос к себе. И задать как по мне более правильный вопрос «а хочу ли я?».

`margin` по горизонтали лишний, в итоге лучше все считать в `%` и в сумме 100 в ряд - это вроде очевидно

думаю исходя из специфики всех платформ нужно просто разделение рендера в самом простом случае или компилятор, можно попробовать скрестить что то из этого
https://github.com/ptmt/react-native-macos (3 из 4)
https://github.com/necolas/react-native-web (3 из 4)
https://github.com/gabrielbull/react-desktop

`overflow: hidden;`

https://jsfiddle.net/dejcnuz0/2/

в разных командах разный подход, начиная от описания комитов, веток и заканчивая тем что все в 1 ветке

ИМО нужно уметь
- слить и залить изменения
- уладить конфликты
... остальное дело практики, так как учится на раз два

Пока этого не реализовано
https://github.com/zenorocha/clipboard.js/issues/533
но есть интересные решения (сам не проверял)
https://stackoverflow.com/questions/33175909/copy-...

• собирать gists в копилку
  
• попытаться внести вклад в какой либо open source проект чтобы проверить весь цикл разработки на себе
  
• сделать какое либо тестовое задание и выложить его и постоянно улучшать не делая новых заданий до определенного момента (лучше взять простую сборку для начала и постепенно докручивать ее)
  

$('.selector')
  .attr('value', 33)
  .attr('data-dtv-val', 456)

return $('.selector')[0].outerHTML

1. нужно учитывать ожидаемое поведение приложения под каждую платформу:
андроид - перемотка табов смахиванием влево вправо, табы сверху
иос - прокрутка в основном по вертикали и вкладки снизу
2. навигация на андроид может и должна использовать кнопку назад, на иос только 1 кнопка на телефоне
3. плагины дают разный интерфейс работы с нативным апи и как это разрулить - это на ваш выбор

это вроде основное. лучше посмотреть последние дизайн гайды, возможно уже что-то поменялось. в целом все на ваш выбор. никто не заставляет вас делать однотипные приложения на материал фреймворке, но и с другой стороны не ожидаемое поведение нужно продумать чтобы не было конфузов. лучше приложение лепить из элементов, для начала, чем дать дизайнеру резвиться. возможно дизайнер будет опытный и будет знать стайл и поведенческие гайды и не плшлет вас когда речь зайдет об андроиде и его поведении

Как человек ввязавшийся в эту авантюру хочу сказать что открывать ИП не стоит если не хотите головной боли и других заморочек.
Как мне предлагали - бухгалтерия будет вести все дела, но мне нужно будет все равно бегать что-то сдавать или платить лично - в итоге - никаких плюсов не было за весь период и теперь у меня проблема с закрытием этой шняги.