Давайте не будем говорить о ценах на жилье, пробках и смогах. Полем Полем Позвольте мне сначала поговорить о моем опыте использования Node.js за последние шесть месяцев. Полем Полем Все это проблемы, встречающиеся на работе и кровавые уроки. Полем
1. Точный номер версии
«Вы должны быть точны к конкретному номеру версии! Используйте *, чтобы катиться напрямую, ^ и ~ не в порядке!» Как только мы приехали в компанию утром, наш сервер был покрыт кровными глазами (вероятно, в какое время утра лезло спать) и пожаловался мне: «Черт, версия в коде Package.json, которую я написал раньше, отличается от версии, которая работает на сервере. Установите последнюю, а затем сообщила об ошибке». Здесь опущены несколько тысяч слов. Полем Полем
Все в порядке. Сначала я пощечину себя по лицу. Я использовал только *. Полем Полем В большинстве случаев нет необходимости писать номер мертвой версии, и также можно использовать ^ и ~. Сканируйте слепоту:
Семвер
Управление версией в node.js
2. Тест
Обязательно напишите тестовые примеры. Возьми меня, к примеру. Партия, за которую я отвечаю, содержит деталь фильтрации (используя текст фильтра обычной Шенмы для извлечения полезного текста). С помощью тестовых случаев после каждого изменения правил фильтрации это абсолютно верно при тесте NPM. Выберите тестовые модули для использования в соответствии с вашими личными предпочтениями, мокко, должны, лента, нажатие, супертес и т. Д.
Попробуйте запустить локально и загрузить на сервер после успеха теста. Я изменял код несколько раз (только что изменил несколько строк) и подумал, что может возникнуть проблема, но как только сервер был перезапущен, он висит трубку. Полем Черт, в нем не хватает скобок или что -то в этом роде. Полем Эта проблема также может быть обнаружена с помощью плагинов редактора, таких как JSLINT или JSHINT.
Резервное копирование кода сервера. Метод, который я использую: сначала было два идентичных проекта на сервере (библиотека GIT, разные имена файлов), один работа, а другой в качестве резервной копии. Когда произойдут изменения кода, перейдите в проект резервного копирования, чтобы Git Pull, затем остановите программу запуска и запустите программу резервного копирования. Если программа не проходит в течение определенного периода времени, это означает, что она кажется относительно стабильной, воспринимайте этот проект как основной и другой проект в качестве подготовки. Когда произойдет другое изменение, повторите вышеуказанные шаги и основной и резервный переключатель вперед и назад. Если программа выходит из строя, переключитесь на более стабильную резервную копию.
3. Используйте отладку
Отладка неизбежно при написании программ. Многим нравится и привыкли использовать универсальную консоль.log (), включая меня. Полем Лично после того, как я использую console.log (), чтобы настроить его, либо удалите, либо прокомментируйте. Это может быть использовано позже, если вы удалите его, но очень уродливо прокомментировать это. В настоящее время вы можете использовать модуль отладки. Узел-инспектор еще не использовался, поэтому оценка не проводится.
4. Держите код простым
Попытка добиться большего количества вещей с меньшим количеством кода также является улучшением и проверкой ваших собственных способностей. Включает в себя правильное отступление, соответствующие имена переменных, Организацию CLEAR CODE и т. Д. Код более тонкий и красивый. Когда что -то идет не так, быстрее проверить ошибку. Лучше, чем выяснить, что делает грязный код, и для этого занимает несколько часов.
Если команда не использует CoffeeScript, не используйте его. Во -первых, другие не могут понять ваш код, чтобы помочь вам исправить ошибки. Во -вторых, количество строк, которые появляются после ошибки, отличается от количества строк, отображаемых в коде кофе. Полем Полем Ваш собственный проект с открытым исходным кодом может быть использован.
5. Спросите больше советов и продолжайте думать самостоятельно
Когда я впервые начал работать, я также смутился, включая технические недостатки и отсутствие бизнес -логики. Я часто спрашивал больших парней в команде. Затем я постараюсь восполнить технические недостатки и прояснить бизнес -логику. Позже я хотел разработать API в соответствии с требованиями PM, который не только учитывал потребности пользователей (ситуация с несколькими клиентами), потребностями и поведением клиентов, дизайном базы данных (как сохранить меньше избыточности, меньше запросов, легко развернуть, легко модифицировать, и различные запросы) и т. Д. После рассмотрения его более чем на неделю, его почти разбивают. Полем Полем Хотя я много раз обсуждал с Tou Tou, это всегда дает мне логику и не сообщает мне метод. Позже я наконец нашел довольно хорошее решение. Полем Позже он сказал мне, что хочет, чтобы я продолжал думать самостоятельно, чтобы решить проблемы, чтобы я мог улучшить. Полем
6. Используйте существующие библиотеки
В настоящее время на NPM существует почти 9 Вт. Теоретически все, что вы хотите использовать, можно найти на NPM. Конечно, на NPM есть много отличных модулей, с комплексной документацией и очень удобным использованием, которые обычно отвечают потребностям. Если вы обнаружите, что модуль может удовлетворить большинство потребностей, он может быть функционально улучшен или имеет ошибки, вы можете перейти в GitHub, чтобы добавить PR. Если вы обнаружите, что не можете найти удовлетворительный модуль, вы можете создать и опубликовать его на NPM, чтобы поделиться с вами. Конечно, если вы обнаружите, что определенный тип модуля, который реализует определенную функцию, очень дерьмо, вы также можете опубликовать дерьмо.
7. Держите это просто
Если вы хотите отобразить круговую диаграмму, просто используйте холст HTML5 или CSS3. Нет необходимости использовать библиотеку C ++ Canvas, чтобы нарисовать картинку, «библиотека, которая зависит от 400 млн», говорится в этом.
8. Хорошая документация
Хорошая документация является наиболее важным каналом для клиентов, чтобы общаться с серверными командами. Документ четко написан. Если возникает ошибка запроса клиента, вы можете сначала проверить документ (например, что представляет каждый код ошибки), вместо того, чтобы просить сервер для обсуждения каждый раз, когда возникает проблема. PS: Некоторые примеры HTTP -запроса должны быть записаны в Curl, а не на объектах в JS и т. Д. Вы можете понять это очень хорошо, но клиент не понимает JS.
9. Файл конфигурации
Создайте файл конфигурации в каждом каталоге проекта, такой как config.js/config.json. Вместо того, чтобы писать это мертвым в коде. нравиться:
{
"Приложение": 3000,
"Монго": {
"Host": "Localhost",
«Порт»: 27017
},
"redis": {
"Host": "Localhost",
«Порт»: 6379
}
...
}
10. Используйте PM2
Использование инструментов управления процессами, таких как PM2, очень удобно, и процесс может автоматически перезапустить, если он не удастся. Не использовал вечно, без оценки. Полем Есть также грейт. Я не использовал его раньше, поэтому не буду комментировать.