بالنسبة لذوي الخبرة ، قد تبدو نصيحتنا واضحة. لكن بالنسبة للمبتدئين ، نوصي بشدة بالقراءة. خذ الوقت الكافي لترجمة هذه الأفكار إلى مشاريعك حتى لا تنفق المزيد على إعادة البناء اللانهائي لاحقًا.
يمكن التعبير عن أفكار مماثلة في أي مجال من مجالات التطوير تقريبًا ، لكننا سنتحدث عنها باستخدام مثال المشاريع في React.
عند بدء المشاريع من الصفر ، تفكر في أفضل السبل لتنظيم كل شيء حتى لا يكون الأمر مؤلمًا بشكل مؤلم في وقت لاحق بسبب إعادة العمل التي لا تنتهي. في مشاريع الحيوانات الأليفة الشخصية ، يمكنك وضع سياج على أي شيء تريده - ثم العيش معه بنفسك. ولكن في العمل الجماعي ، تحتاج إلى التصرف بطريقة تسهل على الزملاء فهم الجوهر والخوض في التفاصيل. أولئك. لا تعيد ابتكار مناهج التطوير - من الأفضل الالتزام بالممارسات الراسخة والمعترف بها في الصناعة.
فكر في الكتابة
بغض النظر عن الحريات في تطوير اللغات ، فإن الكتابة الثابتة مفيدة جدًا في المشاريع الكبيرة طويلة المدى. إذا كان من المستحيل استخدام الكتابة الثابتة في مثل هذا المشروع لسبب ما ، فحتى JSDoc سيساعد بشكل كبير في الحفاظ على جودة الكود.
لكننا لن ننصحك بشدة باستخدام الكتابة دائمًا. لم يكن عبثًا أن تم إجراء حجز أعلاه حول المشاريع الكبيرة ، لأن الكتابة تساعد الفريق أولاً وقبل كل شيء. لكن تنظيمها وصيانتها (نفس النوع يتغير وفقًا للتغييرات في الواجهة الخلفية) يتطلب موارد معينة. في مشروع قصير المدى حيث يعمل شخصان أو شخصان ، فإن هذا الاستثمار لا طائل من ورائه. لكنها ضرورية عندما يكون الفريق كبيرًا وسيتوسع.
إذا كان استخدام الكتابة له ما يبرره ، فإننا نوصي بإنشاء أنواع من البداية ، وإلا فسيتعين عليك قضاء المزيد من الوقت في هذا العمل. حتى إذا لم يكن لديك أي واجهة برمجة تطبيقات جاهزة ولا تعرف نموذج البيانات ، فقم على الأقل بعمل بذرة بحيث لا يظهر النوع العام في أي مكان.
مع تطور المشروع ، يجب الالتزام بالكتابة ، حتى لو تم إنهاء جميع المواعيد النهائية لفترة طويلة. ثم سوف تشكر نفسك على هذا الكمال.
قسّم الكود إلى كتل ، قم بتمييز المنطق
لا يجب تجميع الكود معًا. يجدر النظر في التسلسل الهرمي في هيكل المشروع - تقسيم الكود إلى وحدات وكتل ، وتقسيم المكونات إلى ذكية وغبية. من الأنسب الحفاظ على مثل هذا الهيكل وتطويره من البحث عن جسيمات هذا المنطق في كومة واحدة كبيرة ، خاصةً إذا كانت هذه الجسيمات مترابطة. ربما لا تنطبق هذه النصيحة على الواجهة الأمامية فقط.
كانت فائدة هذا المبدأ واضحة جدًا في المشروع بأشكال كبيرة ، والتي كتبنا عنها مؤخرًا ( https://habr.com/ru/company/maxilect/blog/511322/ ). في هذا المشروع ، تم ربط عمليات فحص الكتلة وإمكانية رؤية تلك الكتل في البداية. ولكن عندما جمعنا كل اتصالات الحقول في مكان واحد ، أصبح من الأسهل بكثير تتبع التغييرات في المنطق. والأهم من ذلك ، تمكنا من إعادة استخدام الكود في مشروع جديد مماثل.
لا يوجد معيار واحد لهيكل المشروع - هنا عليك الاعتماد على معرفتك. هناك طريقتان قد تعملان مع العديد من المشاريع: نوع الملف أولاً والميزة أولاً.
للعثور على نقطة بداية للعثور على بنية مناسبة لك ، نوصي بالرجوع إلى الوثائق. عادة ما يتم وصف أفضل الممارسات هناك. على سبيل المثال ، تقدم React و Redux في وثائقهما معايير لتنظيم المنطق وبنية الملف للمشروع. مع بعض الخبرة ، يمكنك التجربة والابتعاد عن المعايير إذا كان يسمح لك بالتغلب على بعض القيود الخاصة بمشروع معين ، ولكن هذا ليس ضروريًا في معظم الحالات. وبالطبع ، لا تنسى المبادئ "الأساسية" مثل SOLID. مقالة لطيفة حول كيفية تطبيق هذه المبادئ في React:https://habr.com/ru/company/ruvds/blog/428079/ . مقالة جيدة عن العمارة النظيفة: https://habr.com/ru/post/499078/ .
فيما يتعلق بتنظيم قاعدة الكود في React والقضايا ذات الصلة ، هناك مجموعة جيدة من المواد ، وإن لم يتم تحديثها لفترة طويلة: https://github.com/markerikson/react-redux-links/blob/master/project-structure.md .
صياغة اتفاقية الترميز
المهندس المعماري الذي يخطط للمشروع في البداية بناءً على المسار الذي سيطور من خلاله التطبيق لديه قوالب معينة في الاعتبار. يجدر التعبير عنها صراحةً في شكل جواز سفر مشروع ، مع استكماله بقواعد كتابة الكود ، على سبيل المثال ، ما يمكن وما لا يمكن إدراجه في وحدة منفصلة (بشكل عام ، هذا سؤال فلسفي إلى حد ما). سيساعد مثل هذا "جواز السفر" المطورين على تحديد كيفية الكتابة مسبقًا ، بحيث لا يتم إعادة كتابتها لاحقًا. يمكن أن يؤدي ذلك إلى تقليل وقت المراجعة والمساعدة في توحيد مناهج الترميز ، وهو أمر مفيد بشكل خاص عندما يتم العمل على المشروع بواسطة عمال عن بُعد أو فرق موزعة.
التمسك بالنموذج المختار
إذا قررت في البداية الالتزام بنهج ما ، على سبيل المثال ، تصميم الويب الذري ، فلا يجب عليك التخلي عنه بمجرد أن تبدأ المواعيد النهائية في النفاد. في بعض الأحيان يكون الدعم المبدئي والمتخلى عن النموذج أسوأ من غيابه الكامل. إذا "أعطيت العنان للفوضى" قليلاً ، فسيكون من الصعب للغاية استعادة النظام - سيكون عليك قضاء بعض الوقت في العودة إلى النموذج. ولن تكون قادرًا على "القفز" سريعًا إلى مشروع آخر ، لأن فوضى عديمة الشكل ستتشكل بالفعل في المشروع.
إن رفض النموذج من أجل التوقيت أو لعوامل أخرى مثل تغيير الخيول عند العبور. إنه مؤلم ولا ينصح به. ولكن إذا لم يكن هناك مخرج ، فأنت بحاجة إلى تغطية معظم طلبك بالاختبارات. وهنا ننتقل إلى النصيحة التالية ...
تذكر الاختبارات
لا يجب أن تكون الاختبارات في المشروع كذلك. عليهم العمل. ومن الضروري تضمينهم في المشروع في المرحلة الأولى - بمجرد بدء التطوير. خلاف ذلك ، في مرحلة معينة ، يمكنك تغيير شيء ما في التطبيق ، ثم الخروج من المواعيد النهائية للإصدار ، واستعادة أداء أجزاء مختلفة من المشروع ، والتي لا يغطيها سوى الاختبار اليدوي.
اجعل الاختبارات صغيرة في البداية ولا تتحقق من أي شيء على الإطلاق. ولكن من الأفضل تطويرها مع نمو الوظائف ، بدلاً من قضاء أسبوع بعد ذلك في سداد هذا "الدين الفني". من حيث مقدار الوقت الذي يقضيه ، فإن النهج الأول أكثر فعالية. بالمناسبة ، يدرك الكثيرون ذلك جيدًا ، لكنهم ما زالوا يتركون الاختبارات لوقت لاحق.
أود أيضًا أن أذكر اختبارات التكامل والاختبارات الشاملة.
يجب إجراء اختبارات التكامل في كل مرة تقوم فيها بإصلاح الأخطاء أو إضافة ميزات جديدة للتأكد من أن التعديلات لم تؤثر على أي شيء. نحاول في مشاريعنا إطلاقها تلقائيًا عندما نقوم بتحميل نتائج عملنا (قمنا بتنفيذ ذلك من خلال خطاف). لم تنجح الاختبارات - لا يجب تحميل التغييرات على المشروع. أولا تحتاج إلى إصلاح كل شيء.
لكن اختبارات التكامل تتعلق فقط بالواجهة الأمامية. تكون الاختبارات الشاملة أبطأ وتختبر تفاعل التطبيق مع جميع العناصر التابعة. تحاكي هذه الاختبارات إجراءات المستخدم. نحن هنا لا نسخر من أي شيء ، ولكننا ننتظر حقًا ردود الواجهة الخلفية ونتحقق من التفاعلات داخل النظام البيئي بأكمله للمشروع باستخدام Cypress (يمكننا أيضًا أن نوصي Puppeteer كنظير)
فكر قبل الترقية ، لكن لا تستسلم
في عالم الواجهة الأمامية ، يتغير كل شيء بسرعة كبيرة - تحل إصدارات إطار العمل محل بعضها البعض ، وتظهر مكتبات أكثر نجاحًا. يجدر إبقائها محدثة ، ولكن ليست متعصبة.
مثل الكتابة ، التي تحدثنا عنها أعلاه ، فإن أي تحديث يكلف الموارد (أي المال بشكل غير مباشر). ولكن هناك بعض الأشياء التي تجعل من المستحيل إلغاء الاشتراك تمامًا في التحديثات.
أولاً ، ينتهي أحيانًا دعم أكثر المكتبات نجاحًا. في هذه الحالة ، سيكون عليك البحث عن نظائرها الواعدة.
ثانيًا ، نادرًا ما يلهم العمل مع مجموعة التكنولوجيا القديمة المطورين. إذا أدركت أنه لا يمكن الاحتفاظ بالفريق في عمود فقري مليء بالغبار ، أو لاحظت أن مكدسًا قديمًا يؤثر بشكل كبير على تدفق المطورين الجدد ، فسيتعين عليك التحديث.
يجب أن تؤخذ المرطبات كجزء من الترتيب الطبيعي للأشياء. ولكن قبل تغيير مكتبة أو تحديث إطار عمل ، يجب عليك دائمًا إجراء بعض الأبحاث.
هل الإصدار الجديد مناسب لك؟ كيف تنظم الانتقال بشكل عام؟ وبالطبع ، تحتاج إلى تخطيط كل شيء مسبقًا.
التحديثات صعبة للغاية إذا لم تكن هناك اختبارات على المشروع. حتى مكتبة التاريخ الصغيرة يمكن أن تغطي العديد من أجزاء المشروع المختلفة ، وتحديثها يؤدي إلى اختبار الانحدار الكامل. مع نمو المشروع ، لن يكون من الممكن القيام بذلك بكفاءة ، مع وجود اختبارات يدوية فقط في الترسانة.
هل أنت بخير الآن؟
يمكن أن يكون مقياس مدى كفاءة تطوير مشروعك هو نسبة الوقت المستغرق في تطوير ميزات جديدة مقابل الوقت الذي تقضيه في الأخطاء. اعتمادًا على النهج ، يمكن أن يكون هذا المؤشر أكثر أو أقل ، لذلك لن نتعهد بتعيين مستويات "الهدف". يمكنك أنت بنفسك مقارنة الوضع قبل وبعد أي تحولات.
بالإضافة إلى الخصائص غير العددية ، مثل "رضا المطور عن المشروع" ، هناك مؤشر مثل الوقت الذي ينضم فيه شخص جديد إلى المشروع. هذه سمة من سمات مدى جودة وصف المشروع بوضوح من خلال التوثيق والاختبارات واتفاقية الترميز.
وتذكر أنه من الأفضل ترك شفرة أفضل مما كانت عليه من قبل. لا تولد دينًا فنيًا ، وإلا فسوف يعيق تطوير المشروع لاحقًا.
ربما لديك نصائح خاصة بك؟ اترك في التعليقات!
ملاحظة: ننشر مقالاتنا على عدة مواقع على Runet. الاشتراك في صفحاتنا على VK ، FB ، إينستاجرام أو قناة برقية للتعرف على جميع منشوراتنا والأخبار الأخرى من Maxilect.
PPS صورة العنوان من مسابقة Playhouse التي أقيمت مؤخرًا.