دعونا لا نتحدث عن أسعار المساكن والاختناقات المرورية والضباب الدخاني. . . اسمحوا لي أولاً أن أتحدث عن تجربتي باستخدام Node.js في الأشهر الستة الماضية. . . كلها مشكلات واجهتها في العمل ودروس دموية. .
1. رقم الإصدار الدقيق
"يجب أن تكون دقيقًا لرقم الإصدار المحدد! استخدم * للفة مباشرة ، ^ و ~ ليسوا على ما يرام!" بمجرد وصولنا إلى الشركة في الصباح ، كان خادمنا مغطى بعيون دموية (ربما كان وقتًا من الصباح للذهاب إلى الفراش) واشتكى لي: "اللعنة ، الإصدار في Package.Json Code الذي كتبته من قبل يختلف عن الإصدار الذي يعمل على الخادم. تثبيت آخر واحد ثم الإبلاغ عن خطأ." تم حذف بضعة آلاف من الكلمات هنا. . .
حسنًا. سأصفع نفسي في وجهه أولاً. اعتدت على استخدام *. . . معظم الوقت ، ليست هناك حاجة لكتابة رقم إصدار ميت ، ومن الممكن أيضًا استخدام ^ و ~. مسح العمى:
Semver
إدارة الإصدار في node.js
2. اختبار
تأكد من كتابة حالات الاختبار. خذني على سبيل المثال. تحتوي القطعة التي أتحملها على جزء التصفية (باستخدام نص مرشح Shenma العادي لاستخراج نص مفيد). مع حالات الاختبار ، بعد كل تغيير لقواعد التصفية ، يكون هذا صحيحًا تمامًا في إطار اختبار NPM. اختر وحدات الاختبار لاستخدامها وفقًا لتفضيلاتك الشخصية ، يجب أن يكون Mocha ، الشريط ، النقر ، الاختبار ، إلخ.
حاول التشغيل محليًا وتحميل الخادم بعد نجاح الاختبار. لقد قمت بتعديل الكود عدة مرات (قمت فقط بتغيير بضعة أسطر) واعتقدت أنه قد تكون هناك مشكلة ، ولكن بمجرد إعادة تشغيل الخادم ، يتم تعليقه. . لعنة أنها تفتقر إلى قوسين أو شيء من هذا القبيل. . يمكن أيضًا اكتشاف هذه المشكلة باستخدام مكونات المحرر مثل JSLINT أو JSHINT.
رمز الخادم النسخ الاحتياطي. الطريقة التي أستخدمها: في البداية ، كان هناك مشروعان متطابقان على الخادم (مكتبة GIT ، وأسماء الملفات المختلفة) ، والآخر ، والآخر كنسخة احتياطية. عندما تكون هناك تغييرات رمز ، انتقل إلى مشروع النسخ الاحتياطي لسحب GIT ، ثم أوقف برنامج التشغيل وابدأ برنامج النسخ الاحتياطي. إذا لم يفشل البرنامج لفترة من الزمن ، فهذا يعني أنه يبدو مستقرًا نسبيًا ، فاحرص على هذا المشروع كمشروع رئيسي ومشروع آخر. عندما يكون هناك تغيير آخر ، كرر الخطوات المذكورة أعلاه والمفتاح الرئيسي والنسخ الاحتياطي ذهابًا وإيابًا. إذا فشل البرنامج ، فقم بالرجوع إلى نسخة احتياطية أكثر استقرارًا.
3. استخدام التصحيح
تصحيح الأخطاء أمر لا مفر منه عند كتابة البرامج. كثير من الناس يحبون ويستخدمون لاستخدام Universal Console.log () ، بما في ذلك أنا. . شخصيا ، بعد استخدام console.log () لضبطه ، إما حذفه أو التعليق عليه. يمكن استخدامه لاحقًا إذا قمت بحذفه ، لكن من القبيح للغاية التعليق عليها. يمكنك أيضًا استخدام وحدة التصحيح في هذا الوقت. لم يتم استخدام أي عقدة-حتى الآن ، لذلك لم يتم إجراء تقييم.
4. حافظ على الكود بسيط
إن محاولة إنجاز المزيد من الأشياء باستخدام كود أقل هي أيضًا تحسين واختبار قدراتك الخاصة. يتضمن المسافة البادئة الصحيح ، أسماء متغيرة مناسبة ، تنظيم رمز واضح ، إلخ. الرمز أرق وجميلة. عندما يحدث خطأ ما ، يكون من الأسرع التحقق من الخطأ. إنه أفضل من معرفة ما يفعله رمز فوضوي ويستغرق القيام بذلك عدة ساعات.
إذا كان الفريق لا يستخدم Coachescript ، فلا تستخدمه. أولاً ، لا يمكن للآخرين فهم الكود الخاص بك لمساعدتك على تصحيح الأخطاء. ثانياً ، يختلف عدد الخطوط التي تظهر بعد خطأ عن عدد الخطوط التي يتم عرضها في رمز القهوة. . . يمكن استخدام مشروعك مفتوح المصدر.
5. اطلب المزيد من النصائح واستمر في التفكير بشكل مستقل
عندما بدأت العمل لأول مرة ، كنت في حيرة من أمري ، بما في ذلك أوجه القصور الفنية ونقص منطق الأعمال. غالبًا ما سألت اللاعبين الكبار في الفريق. ثم سأحاول تعويض أوجه القصور الفنية وتوضيح منطق العمل. في وقت لاحق ، أردت تصميم واجهة برمجة تطبيقات وفقًا لمتطلبات PM ، والتي لم تأخذ في الاعتبار احتياجات المستخدمين فقط (حالة العديد من العملاء) ، واحتياجات وسلوك العملاء ، وتصميم قاعدة البيانات (كيفية تخزين أقل التكرار ، أو استفسارات أقل ، وسهلة التوسع ، وسهل التعديل ، والاستعلامات المختلفة) ، وما إلى ذلك. بعد النظر فيها لأكثر من أسبوع ، تصطدم تقريبًا. . . على الرغم من أنني ناقشت مع Tou Tou عدة مرات ، إلا أنه يعطيني دائمًا المنطق ولا يخبرني بهذه الطريقة. في وقت لاحق ، وجدت أخيرًا حلًا جيدًا. . أخبرني لاحقًا أنه يريدني أن أستمر في التفكير بشكل مستقل لحل المشكلات حتى أتمكن من التحسن. .
6. استخدم المكتبات الحالية
حاليا ، هناك ما يقرب من 9W وحدات الطرف الثالث على NPM. من الناحية النظرية ، يمكن العثور على كل ما تريد استخدامه على NPM. بالطبع ، هناك العديد من الوحدات الممتازة على NPM ، مع وثائق شاملة واستخدام مريح للغاية ، والتي تلبي عادة الاحتياجات. إذا وجدت أن الوحدة النمطية يمكن أن تلبي معظم الاحتياجات ، فيمكن تحسينها وظيفيًا أو تحتوي على أخطاء ، فيمكنك الذهاب إلى Github لإضافة العلاقات العامة. إذا وجدت أنه لا يمكنك العثور على وحدة مرضية ، فيمكنك إنشاءها ونشرها على NPM لمشاركتها معك. بالطبع ، إذا وجدت أن نوعًا معينًا من الوحدة النمطية التي تنفذ وظيفة معينة هي القرف للغاية ، فيمكنك أيضًا نشر القرف.
7. اجعل الأمر بسيطًا
إذا كنت ترغب في عرض مخطط فطيرة ، فما عليك سوى استخدام قماش HTML5 أو CSS3. ليست هناك حاجة لاستخدام مكتبة C ++ Canvas لرسم صورة ، "المكتبة التي تعتمد على 400+ ميغابايت" ، قال هذا.
8. وثائق جيدة
الوثائق الجيدة هي أهم قناة للعملاء للتواصل مع فرق الخادم. الوثيقة مكتوبة بوضوح. في حالة حدوث خطأ في طلب العميل ، يمكنك أولاً التحقق من المستند (مثل ما يمثله كل رمز خطأ) ، بدلاً من مطالبة الخادم بالمناقشة في كل مرة توجد فيها مشكلة. ملاحظة: يجب كتابة بعض أمثلة طلب HTTP في حليقة ، بدلاً من الكائنات في JS ، وما إلى ذلك. قد تفهمها جيدًا ، لكن العميل لا يفهم JS.
9. ملف التكوين
قم بإنشاء ملف تكوين في كل دليل مشروع ، مثل config.js/config.json. بدلا من كتابتها ميتة في الكود. يحب:
{
"التطبيق": 3000 ،
"مونغو": {
"المضيف": "LocalHost" ،
"الميناء": 27017
} ،
"redis": {
"المضيف": "LocalHost" ،
"الميناء": 6379
}
...
}
10. استخدم PM2
يعد استخدام أدوات إدارة العمليات مثل PM2 مريحة للغاية ، ويمكن إعادة تشغيل العملية تلقائيًا إذا فشلت. لم تستخدم إلى الأبد ، لا تقييم. . هناك أيضا نخر. لم أستخدمها من قبل ، لذلك لن أعلق.