Юмористическая статья с 15 советами, которые помогут вам стать плохим разработчиком.
💡 Это юмористическая пьеса. Нам всем нужно время от времени расслабляться и немного веселиться. Пожалуйста, не принимайте всерьез ни один из этих советов.
Может быть, вы опытный разработчик и обладаете большим количеством навыков и опыта, которые помогут научить нас тому, как стать хорошим фронтенд-разработчиком.
К сожалению, я средний программист, и я могу поделиться с вами только тем, как стать худшим фронтенд-разработчиком.
Ха-ха, у меня 15 лет опыта в этой области. Давайте вместе выучим несколько плохих советов и уволимся из компании как можно скорее!
1. Пожалуйста, используйте глобальные переменные как можно чаще
Вы должны как можно больше использовать глобальные переменные и научить своих коллег использовать этот стиль кодирования.
2. Мы не можем возражать против какой-либо функциональности, предусмотренной менеджером по продукту.
Мы должны принять все требования, запланированные продакт-менеджером, а не выдвигать собственные мысли и возражения.
Пожалуйста, сделайте все возможное, чтобы реализовать сложные, хаотичные и громоздкие функции взаимодействия и получить через это ощущение технических достижений, и будьте маленьким белым кроликом, который не привередлив в еде.
3. Пожалуйста, никогда не пишите комментарии к коду
Почему мы должны писать заметки? Чтобы облегчить работу коллеге? Я отказываюсь!!!
const dpr = 2 // no comments
4. Мы должны отказаться от TypeScript
Мы не можем использовать TypeScript и должны преобразовать элементы, написанные с помощью TypeScript, в код JavaScript, который более удобен для обслуживания и расширения.
В прошлом году наш отдел нанял руководителя. После того, как он вкратце узнал о проекте редактора форматированного текста, который я поддерживал, он сказал мне, что проект нуждается в рефакторинге. Цель рефакторинга состояла в том, чтобы отказаться от TypeScript и переписать его с помощью JavaScript.
После нескольких дней борьбы я принял трудное решение покинуть компанию.
5. Мы не должны абстрагироваться и повторно использовать модули
Вы должны реализовать каждую функцию с нуля, не абстрагируя какие-либо общие компоненты.
Пожалуйста, не абстрагируйте высокочастотную логику в хуки, не абстрагируйте функции инструментов и категорически не используйте повторно никакую логику.
6. Следует отказаться от использования «хуков» для написания компонентов
Пожалуйста, используйте классы для написания компонентов, вы должны отказаться от функциональных компонентов и отказаться от всех хуков.
7. Пожалуйста, пишите компоненты с длинным содержанием
Пожалуйста, используйте только один компонент для завершения логики веб-страницы и держите количество строк кода компонента более 1000 строк.
8. Пожалуйста, используйте менеджер состояний как можно чаще.
Все состояния в проекте должны управляться менеджером состояний, таким как Redux или Mobx, хотя это делает ваш проект раздутым.
9. Пожалуйста, напишите стиль, смешав и принудительно перезаписав
Мы должны смешивать и переопределять встроенные стили со стилями файла CSS.
Пожалуйста, назовите «класс» свободно, не раскрывайте структурную информацию элемента DOM。
Если есть конфликт стилей, перезапишите его.
10. Пожалуйста, используйте «JavaScript» для реализации стиля компонента
Вы должны использовать JavaScript для достижения анимации и переходов, которые можно сделать с помощью собственного CSS.
11. Передайте параметры между многоуровневыми компонентами.
Родительский компонент передает много параметров дочернему компоненту, а затем дочерний компонент продолжает передавать эти параметры слой за слоем.
12. Вы не должны инкапсулировать функции общедоступных сетевых запросов.
Все запросы должны быть направлены на создание нового экземпляра Axios в нашем проекте.
Ошибки сетевых запросов не должны перехватываться единообразно, а все они должны перехватываться отдельно.
13. Измените исходный код в node_modules.
Пожалуйста, измените исходный код непосредственно в «node_modules» и сохраните эту часть модификации только на своем компьютере.
14. Пожалуйста, используйте «если еще» как можно чаще. Чем глубже уровень, тем лучше
Чем больше «если еще», тем лучше вы сможете показать свои способности, пожалуйста, сохраните эту полезную привычку.
15. Не используйте «const» и «let»
Что? Вы действительно пишете код, используя «const» и «let»? В конце концов, он все равно компилируется в «var», поэтому я рекомендую использовать «var» для написания кода.
Окончательно
Спасибо, что прочитали. Я с нетерпением ждувашей подписки и новых качественных статей.
Интервьюер: Что случилось с «npm run xxx?
Секрет, о котором не знает большинство людей.javascript.plainenglish.io»
Интервьюер: Может ли «x !== x возвращать True в JavaScript?
Пять волшебных знаний в области JavaScript, о которых вы, возможно, не знали!javascript.plainenglish.io»
Дополнительные материалы на PlainEnglish.io.
Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter, LinkedIn, YouTube и Discord .
Заинтересованы в масштабировании запуска вашего программного обеспечения? Ознакомьтесь с разделом Схема.
