العودة إلى الوراء
كان من المخطط نشر هذه الحلقة في شهر ديسمبر قبل عطلة عيد الميلاد، لذا يبدو أنني أنا المسؤول عن التأخير. لقد ظللت أؤخر النشر أسبوعًا بعد أسبوع بسبب بعض المهام ذات الأولوية القصوى التي اعترضت طريقي، ولكن اليوم هو اليوم المنتظر.
في الحلقة الماضية كنت قد أثرت التعليق على المقال الذي يتناول أهمية الفكاهة في مكان العمل، ولكن في الوقت نفسه اكتشفت أنه يستحق المزيد من التقدير لذلك سأكتب مقالة كاملة عنه قريباً (تقريباً).
الأشياء التي شغلتني خلال الأسبوعين الماضيين:
أ) بدأت قبل عيد الميلاد بحلقة أولى من سلسلة الندوات عبر الإنترنت "Bulletproof CTO" (ترقبوا الحلقة الثانية في شهر فبراير التي ستعرض برنامج SaaS CTOs، التفاصيل في وقت قريب على موقع LinkedIn الخاص بي).
ب) ضبط خطة النمو الخاصة بنا لعام 2021 بهدف تجاوز أعمالنا الأساسية في روبي وJS وتنمية ماجينتو و المنتج كفاءة التصميم في المنزل.
كفى ترويجاً للذات، اسمحوا لي أن أدعوكم إلى الحلقة الخامسة من سلسلة #heCodestReview.
مواضيعي الفريق قد أعدت لهذا الوقت:
يتم تسليم التعليقات على تطبيق الواجهة الأمامية والالتزامات التقليدية هذا الأسبوع من قبل مهندسي React لدينا بينما يتم تسليم روبي 3.0.0 من قبل فريق أحلام روبي لدينا.
اليوم الكثير من المطورين لتوفير الوقت يستخدمون مكتبات واجهة المستخدم والمكونات القابلة لإعادة الاستخدام. إنها ممارسة جيدة وتساعدنا على توفير الكثير من الوقت ولكن عندما يكون لدينا المشروع يصبح أكبر - سوف تفهم أنه لا يكفي التعامل مع الكود.
هناك نمطين جيدين من التطوير الخلفي - التطوير المدفوع بالمجال (DDD) وفصل الاهتمامات (SoC). يمكننا أيضًا استخدامها في بنية الواجهة الأمامية.
في DDD، نحاول في DDD تجميع الميزات المتشابهة وفصلها قدر الإمكان عن المجموعات الأخرى (الوحدات النمطية).
بينما مع SoC، على سبيل المثال، نفصل بين المنطق وطرق العرض ونماذج البيانات (على سبيل المثال باستخدام نمط تصميم MVC أو MVVM).
هناك الكثير من الممارسات والأنماط الجيدة لاستخدامها ولكن هذه الطريقة هي المفضلة بالنسبة لي.
عندما نستخدم هذا النمط سنحصل على هذه الصورة:
في البداية يتم إعادة توجيه المستخدم إلى الوحدة النمطية الصحيحة عن طريق توجيه التطبيق. يتم احتواء كل وحدة نمطية بالكامل. ولكن، نظرًا لأن المستخدم يتوقع استخدام تطبيق واحد، وليس بعض التطبيقات الصغيرة، فسيكون هناك بعض الاقتران. يوجد هذا الاقتران على ميزات محددة أو منطق العمل.
ولدينا هذا الهيكل:
مجلد التطبيق - طبقة التطبيق
الأصول - مجلد للصور والخطوط والأيقونات وما إلى ذلك.
المكونات - يجب أن تكون هنا مكونات لإعادة الاستخدام لا تحتوي على منطق معقد
التهيئة - هنا سنخزن الحالة العامة
lib - مجلد للوظائف المعقدة وحساب المنطق
الوحدات النمطية - إليك وحداتنا النمطية
pubs - مكان لتخزين المخططات لوصف بنية البيانات.
الأنماط - لرمز css/ssss لدينا
ستساعدنا هذه البنية على التعامل مع تطبيقنا المتنامي وتقليل الأخطاء. كما أنه سيساعدنا على جعل أجزاء العمل أكثر راحة مع وحدات منفصلة، واختبارها وجعل إعادة الهيكلة وتصحيح الأخطاء أسهل (بسبب الوحدات المنفصلة).
إذا نظرنا بشكل أعمق إلى بنية الوحدات النمطية واتصالاتها مع واجهة برمجة التطبيقات - سنحصل على شيء من هذا القبيل:
إذا كان مجلد "التطبيق" سننشئ مجلدًا آخر "api" مع رمز لمكالمات واجهة برمجة التطبيقات والبيانات التي سنحفظها في "config/store". هنا نحتفظ بالبيانات الثابتة وغير القابلة للتغيير التي نستخدمها في التطبيق بأكمله.
أيضًا في مجلد "pubs/schema" سنقوم بوصف أنواع بيانات محددة ل JavaScript الأشياء.
تحتوي جميع الوحدات النمطية على بيانات بداخلها والتي نحتاج إلى استخدامها (المستخدمين، المسارات، الجداول، الجداول، الإجراءات وغيرها). كل وحدة متصلة بطبقة التطبيق وتأخذ كل البيانات الضرورية.
الواجهة الأمامية هي نقطة الدخول الأولى لمستخدمينا. مع تزايد ميزات مشاريعنا للواجهة الأمامية، سنقدم أيضًا المزيد من الأخطاء. لكن مستخدمينا يتوقعون عدم وجود أخطاء وميزات جديدة بسرعة. وهذا أمر مستحيل. ومع ذلك، من خلال استخدام بنية جيدة يمكننا فقط محاولة تحقيق ذلك قدر الإمكان.
تخيل أنك في نقطة البداية في شركة تم تعيينك فيها للتو. جميع الأشخاص لطفاء معك وكل شيء يبدو جيداً حتى النقطة التي تتعرف فيها على قاعدة برمجة من قبل أن تكون لغة JavaScript وكان نتسكيب يقوم بتحميل صفحة تبدو وكأنها من زمن بعيد.
يبدو أن توريث الشيفرة البرمجية مشكلة كبيرة عند تقديم مطورين جدد لمشروع ما. قراءة الشيفرة شيء واحد، ولكن فهم كيف تم تطوير التطبيق ليس هو نفسه تمامًا. في كثير من الأحيان تثبت الالتزامات أنها مفيدة وتعطي سياقًا لسبب عدم التقاط هذه السجلات التي تم التقاطها بواسطة linter أو سبب وجود هذا الشرح السيئ // TODO لأبناء المطور الذي قام بعمل الشرح في البداية.
لنبدأ بالسبب الذي يجعل الالتزامات التقليدية أفضل من قواعد الالتزام غير الموحدة.
إذا قمنا بتوظيف مطورين جدد في مشروع تتكون معظم الالتزامات فيه من رسائل على غرار يجب أن يعمل أو إصلاح النائم للتذييل في أسرع وقت ممكن، فما الذي يخطر ببالك؟
أود أن أقول أن الأعلام الحمراء بسبب:
نظرًا لأن فريقك يمكن أن يكون لديه قواعد مخصصة يتم تطبيقها عند إجراء تغييرات على فريقك، فهناك مجال أقل للخطأ حيث يجب أن يكون التزامك قويًا. لم يعد الأمر مجرد وسيلة لتسجيل الخروج. إنه توقيع يخبر الآخرين أنك تعرف محتويات الالتزام. لا داعي لذكر أنه إذا لم يتم توقيع العمل الذي قمت به بشكل صحيح فمن المرجح أن يؤدي ذلك إلى حدوث خطأ ويطالبك برسالة
هناك احتمال أن يرغب فريقك في إعداد قاعدة لا تسمح باستخدام كلمات مفتاحية معينة بحيث يمكن أن تكون كلمة "ASAP" أو أي كلمات بذيئة في القائمة السوداء.
ما هو مفيد حقًا في بداية المشروع هو تعريف الجميع بكيفية فريق التطوير يرغبون في رؤية مطورين جدد يلتزمون بتغييراتهم. ثم قم بإعداد أداة تساعدهم على مواكبة ما اتفقتم عليه جميعًا.
إحدى الأدوات التي أتيحت لي فرصة العمل بها هي الالتزام وجعلت من الالتزامات التقليدية ممارستي المفضلة عند القدوم إلى مشاريع جديدة ليس لها قواعد وفريق العمل منفتح على فكرة تقديمها.
عند التعامل مع الإعدادات ونشرها عبر فريقك يمكنك ببساطة إنشاء حزمة npm ومجرد mpn i -D في كل مشروع. سيساعد ذلك بالتأكيد كل شخص في المشروع على أن يكون على نفس الصفحة في جميع الأوقات، وإذا لزم الأمر التنقل من مشروع إلى آخر لفهم ما هي التغييرات الأخيرة (ولماذا تم إجراؤها).
والآن بعد إعداد كل ذلك وفهم لماذا قد تكون فكرة جيدة للبدء في استخدام CC، فإن أفضل جزء هو البرمجة حول القواعد التي طبقتها للتو! نحن نستخدم طريقة موحدة لكيفية الالتزام، نحن نولي اهتماماً أكبر لما كان الالتزام بالفعل، فلماذا لا نقوم بإعداد خطافات تسمح لك بإجراء اختبار سريع على التدريج عند وجود علامة؟ نحن لا نريد أن نفرط في الخدمات ونخفض التكاليف عند الحاجة، وهناك بعض الأسباب التي تدفعنا للاختبار على خادم شبيه بالإنتاج بدلاً من المضيف المحلي.
لنفترض أنك تعمل على PWA وأن طبقة المقابس الآمنة (SSL) ضرورية لك لاختبار الإمكانات الكاملة ولديك طبقة المقابس الآمنة على منصة الاختبار الخاصة بك. كل ما تحتاجه الآن هو مجرد التزام جيد. شيء ما على غرار إنجاز (PWA): تحميل إعداد أيقونات البيانات، سيؤدي تحميل إعداد صندوق العمل إلى تشغيل آلية الاختبار بأكملها وتحريك العجلات المسننة. لا نحتاج إلى ذلك عند تحميل بعض البيانات الثابتة فقط مثل manifest.json، لذا نضيف علامة [TEST_SKIP] كبادئة لاحقة إلى التزامنا. يمكّن ذلك التزامنا CI من تحميل الأصول الجديدة فقط إلى بيئة الاختبار وتخطي الاختبار. يمكنك قراءة المزيد عن ذلك هنا
بعد فترة من الوقت ستتمكن من رؤية فوائد أخرى، مثل سهولة إنشاء CHANGELOG وإصدار أفضل مع الإصدار الدلالي. إذا لم يكن هذا كافيًا لإقناعك بتغيير طريقتك في كتابة رسائل الالتزام، فربما غمس أصابع قدميك في الماء البارد العذب ومحاولة استخدامها في مستودعك الخاص لفترة من الوقت سيغير رأيك.
التزام تقليدي سعيد!
لقد رأى إصدار روبي 3.0.0 الذي طال انتظاره في المجتمع روبي 3.0 ضوء النهار في عيد الميلاد حتى يتمكن جميع مطوري روبي هناك من العثور عليه تحت شجرة عيد الميلاد بمجرد استيقاظهم في الصباح. نقوم في The Codest بتعزيز ثقافة مشاركة المعرفة من خلال تنظيم اجتماعات أسبوعية للمطورين حيث يناقش مهندسونا اتجاهات التكنولوجيا واكتشافاتهم الجديدة التي تستحق الاهتمام. يمكنك العثور أدناه على رابط لشرائح من اليوم التجريبي حيث ناقش كبير مهندسي روبي لدينا بعض التغييرات المهمة في روبي 3.0.0 من وجهة نظره الشخصية:
https://drive.google.com/file/d/1rboAusV1UTWXYMVGuLHx6O90lXrgkmnO/view?usp=sharing
علاوة على ذلك، ساهم معلم روبي الخاص بنا في الإصدار الجديد بطلب السحب الخاص به والذي تم دمجه بنجاح. يمكنك الاطلاع على المزيد حول موضوع طرق التحكم في الخصوصية في المقالة القصيرة التي كتبها رئيس قسم التطوير لدينا.
https://thecodest.co/blog/ruby-3-0-ruby-and-lesser-known-privacy-control-methods
شكراً جزيلاً على القراءة، وإذا كنت قد وصلت إلى هذا الحد، فأنا أقدر وقتك وأرحب بكل تعليق على موقع LinkedIn أو على بريدي الإلكتروني.
نعود إليكم بالحلقة القادمة في نهاية شهر فبراير مع استعراض بودكاست مع CTO من Shopify، الرجل الذي يقف وراء فريق هندسي يعمل على تطبيق روبي الرائع المترابط!
أراك لاحقاً
اقرأ المزيد:
مراجعة TheCodestReview #4 - عصير هندسة البرمجيات الأسبوعي
Arabic 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Polish 
Italian 
Japanese 
Korean 
Spanish 
Dutch 
Estonian 
Greek