Может быть, вы никогда не писали ошибок. Но вы слышали об ошибках других людей и хотите принять участие в этом процессе. Именно для вас я собрал эту коллекцию полезных советов, которые помогут вам в кратчайшие сроки написать ошибки уровня ниндзя.
Правила созданы для того, чтобы их нарушали.
Стандарт говорит, что я не могу поместить ‹div› в ‹span›.
Пффф.
<span> <div>Like hell I can't</div> </span>
Протестировано в Chrome, работает нормально.
Теперь вы можете подумать, что я собираюсь дать вам конкретный пример ошибки, которую создает это конкретное поведение, но это неправильный образ мышления.
Потому что тогда вы будете знать конкретный пример ошибки, и знать, где именно возникнет проблема, - не лучший способ писать ошибки. Чтобы быть по-настоящему отличным создателем ошибок, вам нужно игнорировать такие правила, как «помещайте только фразовое содержимое в промежутки» и извлекайте код, который , вероятно, будет работать в большинстве мест большую часть времени.
ASI готов помочь
Ничто так не портит красивый фрагмент кода, как точка с запятой в конце каждого оператора;
Фу;
Я должен поставить под сомнение здравомыслие разработчика, который чувствует необходимость ставить самые уродливые из всех знаков препинания по всему магазину, когда они даже не требуются.
Классические автомобили кода
Может быть, вам не нравятся классические автомобили, а может, вам больше подойдет хороший винтажный шкаф. Возможно, вы предпочитаете винил mp3 или золотые дни кино.
Тем не менее, большинство людей понимают, что мы что-то потеряли в современном обществе, и то же самое с устаревшими методами. Мне нравится Node util.debug (), я не хочу использовать Johnny-Come-Lately console.error (), это просто кажется настолько клиническим.
Если вы используете метод, который какой-то владелец библиотеки решил исключить, просто не обновляйте эту библиотеку больше, вы знаете, что используете классическую версию, стоимость которой будет только расти.
Сократите код вдвое
Отвратительный факт: почти половина всего кода, написанного так называемыми «программистами», даже не попадает в производство. Я говорю о модульных тестах.
Глупые юнит-тесты.
Подумайте об этом: вы пишете функцию, которая складывает некоторые числа, а затем пишете тест, чтобы проверить, что функция складывает некоторые числа вместе?
Это безумие. Вы знаете, что ваш код работает, вы можете видеть, как он работает. Продолжайте продвигать, переходите к следующему заданию и продолжайте отгрузку!
Копировать вставить
Stackoverflow: профессиональная библиотека сниппетов для профессионалов.
Хотите написать ajax-запрос?
- Google "как выполнить ajax-запрос".
- Щелкните первый результат переполнения стека.
- Скопируйте / вставьте первый ответ.
Я слышал, что есть люди, которые изменяют код после его копирования / вставки или даже сами набирают его, чтобы лучше понять !! Кто эти чудаки? Взаимодействуя с фрагментом кода stackoverflow, вы ошибаетесь с огнем.
Совет от профессионала: когда нет результатов переполнения стека, w3schools - отличный ресурс.
Мыслить глобально
Я слышал, что есть люди, говорящие о глобальных переменных в JavaScript. Эти люди шуты.
Если у вас есть переменная, которая должна быть доступна повсюду в вашем коде, бросьте ее в окно, мой друг. Вот для чего это нужно.
Очевидно, что если это обычное слово, такое как «обещание», «экран» или «статус», поставьте после него «2» или что-то в этом роде.
Но если это что-то особенное для вашего приложения, например «динамик» или «конфигурация», ничего не стоит. Как и все, проверьте, что он работает в Chrome (и Firefox, если у вас есть время), прежде чем нажимать на prod.
Для некодеров
Даже если вы не пишете код самостоятельно, вы все равно можете вносить свой вклад в создание ошибок. Предположим, например, что вы работаете в отделе продаж и рассказываете об отличном программном обеспечении вашей компании. Не забудьте рассказать об этой новой функции, которая скоро выйдет. Вы обнаружите, что большинство новых клиентов гораздо более готовы платить, если у них есть устная гарантия, что определенная функция появится в ближайшие несколько месяцев.
Вам нужно будет создать ситуацию, при которой, если разработчики не создадут определенную функцию к определенной дате, компания потеряет определенную и значительную сумму денег. Мне, наверное, не нужно об этом говорить, но пожалуйста не пугайте команду разработчиков насчет реалистичных сроков реализации этой горячей новой функции, они скорее будут писать код, чем говорить вам о сроках. Если срок приближается к сроку, и все выглядит мрачно, они могут просто работать быстрее.
Никогда не забывайте, что все разработчики всегда могут просто работать быстрее.
