مرة أخرى حول تعقيد الهندسة المعمارية وعتبة الدخول

في هذه المقالة ، سوف أتطرق إلى مسألة الحد الأدنى لدخول مشروع بهيكل معمول به وأقدم عدة خيارات للإجابة على سؤال متكرر للغاية: لماذا يكون من الصعب جدًا؟

غالبًا ما يطرح هذا السؤال بين القادمين الجدد الذين يأتون إلى المشروع. أو هناك مواقف عندما يذهب المشروع إلى الدعم والتطوير في أيد جديدة ، والمطور الجديد لديه أيضًا هذا السؤال. ونادراً ما يحاول أحدهم معرفة الأسباب الحقيقية لوجودها هنا وليس غيرها. قد يؤدي ذلك إلى عواقب وخيمة على الأعمال التجارية ، على سبيل المثال ، قد يصر مطور جديد على إعادة كتابة التطبيق بالكامل من نقطة الصفر.
لتقليل مثل هذه المخاطر ، بدلا من السؤال لماذا هو صعب جدا؟ اطرح مثل هذه الأسئلة:

• ما هي متطلبات عملية التطوير التي وضعها المهندس المعماري؟
• ما هي نتيجة عملية التطوير المطلوبة في الإخراج؟

متطلبات عملية التنمية

أولاً ، يجب على المطور الخوض في نظام عملية التطوير ، يجب عليه طرح السؤال التالي:

• ما هو النظام الذي تقوم عليه العملية؟

غالبًا ما يتم تطويره حسب الطلب ، وهو مشروع يحتوي على متطلبات لا لبس فيها ومجموعة ثابتة من الوظائف التي يتم إدخالها. كيف تطورت بشكل جيد - هذا هو موضوع مقال آخر. وغالبًا ما يتم بناء عملية التطوير في مثل هذه المشروعات وفقًا لنظام الشلال ، لأنها تتضمن ردود فعل مباشرة من مستخدمي المنتج - بعد تطوير الوظيفة الكاملة للمنتج ، بينما يمكن الحصول على التغذية المرتدة من خلال النموذج التكراري بعد التكرار الأول. لمثل هذه المشاريع ، يكون للمهندس المعماري عادة بنية معمول بها تفي بمتطلبات معينة لهذه العملية. ما هي متطلبات عملية التطوير هذه التي وضعها المهندس المعماري؟

1) يجب أن تكون عملية تطوير خط أنابيب معقدة بقدر الإمكان للمطور. وينبغي أن يحدث رفض الكود الذي يدخل مستودع المشروع إلى الحد الأقصى تلقائيًا ، وإذا لم يكن ذلك ممكنًا ، دون مشاركة المهندس المعماري نفسه.

أي يجب تكوين خط أنابيب محدد في العملية. تعتبر الشفرة التي مرت عبر هذا الخط بأكمله مرضية. هذا مهم جدا ل يحتاج المهندس المعماري الجيد إلى إنقاذ مطوريه من الصداع والمسؤولية عن عدم عمل التجميع بعد دخول الرمز إلى المستودع. إذا لم يكن هناك خط أنابيب من هذا القبيل ، فسوف يعاني مطورو البرامج لديك من الضغط المستمر. إذا دخلت الشفرة إلى المستودع وقبلها خط الأنابيب ، وكسر هذا الرمز التجميع أو أضر بوظائف العمل بالفعل - فهذه مشكلة بالفعل في خط الأنابيب نفسه.

لذلك ، في مثل هذا الخط ، يجب عليك استخدام:

• العديد من محللات الكود الثابت
• الاختبارات الآلية واختبار الامتثال الهرم
• التلقائي حساب تغطية رمز عن طريق الاختبارات
• بوابة جودة الكود (بوابات الجودة). بالنسبة لجميع أنواع المقاييس: النسبة المئوية لتغطية الشفرة مع الاختبارات ، والنسبة المئوية لتكرار الشفرة ، ورائحة الكود ، والأمن ، والأخطاء ، إلخ.
• مراجعة عبر الكود
• الخ

كل هذه النقاط مجتمعة تؤدي إلى سؤال المطور: لماذا هو صعب للغاية؟

على سبيل المثال ، حاول كتابة اختبارات هذا الرمز:

class SomeService( private val restApi: SomeApi // SomeApi -  ,   ,      ) { fun doSomething(): Single<SomeResult> = restApi.loadSomething() .map { /*-   */ } } 

سيتعين عليك إجراء مثل هذه الاختبارات على جهاز Android حقيقي ، أو على محاكي. وهذا سيؤدي على الفور إلى انخفاض كبير في الشرط الثاني لعملية التطوير:

2) يجب أن يتم تنفيذ عناصر خط الأنابيب الآلي وعملية التطوير في أسرع وقت ممكن

إذا كان على مطوري البرامج الانتظار لفترة طويلة حتى تكتمل الاختبارات - فهذه هي مشكلة خط الأنابيب الخاص بك وإذا كانت البنية لا تسمح بتسريع هذه العملية - فهذه هي مشكلة بنيانك

دعنا نعيد كتابة المثال:

 interface SomeApi { fun loadSomething(): Single<NetworkResult> } class NetworkSomeApi : SomeApi { override fun loadSomething(): Single<NetworkResult> { /*,    */ } } class SomeService( private val restApi: SomeApi // SomeApi -  ,       ) { /*CODE*/ } 

نرى أن تعقيد الكود قد زاد ، ولكن من وجهة نظر عملية التطوير - لقد جعلنا الهيكل أكثر مرونة ، والآن لا يتعين علينا إجراء اختبارات منطقية تجارية لكتلة map في المحاكي أو على الجهاز ، فقط قم بإجراءها في اختبارات سريعة. سيؤدي ذلك إلى تقليل عدد اختبارات التكامل التي يجب تشغيلها في بيئة بطيئة.

يمكن لنمط التصميم الذي اختاره المهندس المعماري أن يقلل من عدد اختبارات التكامل باهظة الثمن. لا تكن كسولًا وتعامل مع الأنماط الشائعة اليوم: MVP ، MVVM ، MVI .

دعنا نتحدث أكثر قليلاً عن الملاحة في التطبيق. نريد أيضًا أن نكون قادرين على اختباره واختباره في اختبارات سريعة. مرة أخرى ، نحصل على "تعقيد" الهندسة المعمارية ، لأنه يتعين علينا إخفاء نظام الملاحة في التطبيق الذي يكمن وراء التجريد.

ونريد أيضًا أن نكون قادرين على توصيل مكونات نظامنا باستخدام DI ، وبناء الرسوم البيانية التبعية والتحقق من صحتها في مرحلة تجميع المشروع ، وليس في وقت التشغيل. ثم تظهر خنجر 2 ومكوناتها الوحشية ومكوناتها الفرعية مع الوحدات النمطية على المسرح ، الأمر الذي يربك المبتدئين المسكين في النهاية.

وهذه اللحظات غير الواضحة من "تعقيد" الهندسة المعمارية للمبتدئين تتراكم كثيرًا. بطبيعة الحال ، دون فهم عمليات التطوير ومتطلبات هذه العمليات ، لديهم نفس السؤال - لماذا هو صعب للغاية؟

نتيجة عملية التطوير

لتقييم نجاح عملية التطوير المدمجة ، وبشكل غير مباشر ، بنية المشروع ، من الضروري تحليل نتائجه. كقاعدة عامة ، تكون النتيجة منتجًا (تطبيق إذا كنا نتحدث عن تطوير الأجهزة المحمولة). وتختلف مقاييس النجاح للمنتج بالنسبة إلى الجميع: لدى العميل نفس المقاييس ، والمطور لديه مقاييسه الخاصة ، ومستخدم المنتج لديه.

كحد أدنى ، يجب عليك ، بصفتك المهندس المعماري الذي يقوم بإنشاء خط أنابيب لعملية التطوير ، مراعاة عند تقييم فعالية عملية تطوير مقاييس شركتك ومقاييس العمل.

هذه عملية مستمرة: التطوير -> جمع المقاييس -> تحليل النتيجة -> إجراء التعديلات اللازمة لعملية التطوير.

وبالتالي ، فإن النتيجة تؤثر على تشكيل عملية التطوير وعملية التطوير تؤثر بالفعل على التغيير في بنية المشروع. أي الفكرة المهمة التي أريد أن أنقلها هي أن الهندسة المعمارية هي الثانوية ، والنتيجة الأولية وعملية التطوير .

استنتاج

في الختام ، دعنا نقول مرة أخرى:

• دون فهم عمليات التطوير ومتطلبات هذه العمليات ، يخلق المطور إحساسًا بشأن البنية المعقدة للمشروع ؛
• الهندسة المعمارية هي نتيجة ثانوية ، وعملية التطوير الأولية ؛

دون فهم هذه الأشياء ، قد يرغب المطور في أخذ كل شيء وإعادة كتابته من البداية. في رأيي ، هذا له ما يبرره فقط عندما تكون عملية التطوير والنتيجة لا ترضيان العميل تمامًا من هذا التطوير.

بالنسبة للمبتدئين ، أنصحك بالشروع في مشروع مع خط أنابيب التطوير المكرر. عتبة الدخول إلى مثل هذه المشاريع عالية ، ولكن عند تجاوزها ، سوف تتعامل بجدية مع فهم كيفية بناء عمليات التطوير.