بنية PHP نقية. كيفية قياسه والتحكم فيه؟

مقدمة


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

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

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

للراحة ، تم تقسيم المقالة إلى جزأين.

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

الجزء الثاني ، بالكامل تقريبًا ، سيتم تخصيصه لوصف الأداة التي ظهرت ، وكشف قدراتها وإرشاداتها خطوة بخطوة.

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



الجزء الأول


ما هي هندسة البرمجيات؟


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

ما هو الغرض من العمارة؟


هناك إجابة واحدة فقط:

الهدف من هندسة البرمجيات هو تقليل العمالة البشرية المطلوبة لإنشاء وصيانة النظام.

مقدمة قليلة ..

من أين تبدأ العديد من المشاريع؟


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

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

قيمتان لمنتجات البرمجيات


  1. السلوك (شيء عاجل ولكن ليس مهمًا دائمًا)
  2. العمارة (شيء مهم ، ولكن ليس دائمًا ملحًا)

غالبًا ما يغرق الكثير في الأول ، ويتجاهلون الثاني تمامًا.

النوع: "لماذا تضيع الوقت في التفكير مليًا في الهندسة المعمارية ، الشيء الرئيسي هو أنها تعمل بشكل صحيح!" .

لكنهم يفوتون نقطة واحدة مهمة: "إذا كان برنامج يعمل بشكل صحيح لا يسمح بإمكانية تغييره ، فسوف يتوقف عن العمل بشكل صحيح عندما تتغير المتطلبات ، ولن يتمكنوا من جعله يعمل بشكل صحيح. أي أن البرنامج سيصبح عديم الفائدة.

إذا لم يعمل البرنامج بشكل صحيح ، ولكن من السهل تغييره ، فسيكون قادرين على جعله يعمل بشكل صحيح والحفاظ على أدائه مع تغير المتطلبات. أي أن البرنامج سيظل مفيدًا دائمًا ".

أعجبني هذا البيان:"إذا كنت تعتقد أن العمارة الجيدة باهظة الثمن ، فجرب العمارة الضعيفة." (بريان فوت وجوزيف يودر)

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

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

لماذا توصلت إلى SOLID ولماذا لا يكفي وحده؟


ربما نعرف جميعًا مبادئ SOLID.

هدفهم هو إنشاء هياكل برمجيات متوسطة المستوى:

  • متسامح مع التغيير
  • بسيطة ومفهومة ؛
  • تشكل الأساس للمكونات التي يمكن استخدامها في العديد من أنظمة البرمجيات.

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

سوف أتطرق إلى هذه المواضيع بشكل سطحي للغاية ، ويمكن العثور على مزيد من التفاصيل في الكتاب. لنذهب!

توصيلية المكونات ومبادئها المحددة


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

المراسل: مبدأ معاداة إعادة الاستخدام / التحرير - مبدأ معادلة إعادة الاستخدام والإطلاق.

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

يجب تحرير الفئات والوحدات المدمجة في مكون معًا.

CCP: مبدأ الإغلاق المشترك - مبدأ التغيير المستمر.
هذا هو مبدأ SRP (مسؤولية واحدة) أعيدت صياغته للمكونات.

يجب تضمين الفصول التي تتغير للأسباب نفسها وفي نفس الوقت في مكون واحد. يجب أن تتضمن المكونات المختلفة فئات تتغير في أوقات مختلفة ولأسباب مختلفة.

CRP: مبدأ إعادة الاستخدام المشترك - مبدأ إعادة الاستخدام المشترك.
هذا المبدأ مشابه لـ ISP (فصل الواجهة).

لا تجبر المستخدمين على الاعتماد على ما لا يحتاجونه.

يشير المبدأ إلى أنه لا يجب تضمين الفئات التي لا ترتبط ارتباطًا وثيقًا في مكون واحد.

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

صورة

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

توافق المكونات


"تحدد المبادئ الثلاثة التالية قواعد العلاقة بين المكونات. ومرة أخرى ، نواجه تناقضات بين سهولة التنمية والتنظيم المنطقي. القوى التي تؤثر على بنية هيكل المكون هي تقنية وسياسية ومتقلبة ".

ADP: مبدأ التبعيات الحلقية - مبدأ التبعية اللا تبعية.
لا يُسمح بالحلقات في الرسم البياني لتبعية المكون!

صورة

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

صورة

في هذه الصورة ، لدينا تبعية تؤدي إلى ظهور دورة. يمكن دائمًا كسر الاعتماد الدوري الناتج.

طرق كسر التبعيات الدورية


1. بتطبيق DIP (مبدأ انعكاس التبعية)

صورة

2. إدخال المكون الجديد

صورة

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

تصميم من أعلى لأسفل ، أو بالأحرى غير عملي


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

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

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

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

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

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

مهلا ، هل ما زلت هنا؟ يا رجل ، هذا مهم ، عليك أن تقول مرحبًا بهذا على الأقل من أجل إدخال معنى الجزء التالي ، سيكون هناك برنامج تعليمي خام حول استخدام tulza.

SDP: مبدأ التبعيات المستقرة - مبدأ التبعيات المستقرة.
يجب أن تكون التبعيات موجهة نحو الاستقرار!

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

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

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

صورة

صورة

كيفية تقييم استقرار المكون؟ يقترح المؤلف حساب عدد تبعياته الواردة والصادرة وعلى أساسها يحسب مقياس استقراره.

  • Fan-in ( ): . , .
  • Fan-out ( ): . , .
  • I: : I = Fan-out ÷ (Fan-in + Fan-out). [0, 1]. I = 0 , I = 1 – .

لذلك ، يقول هذا المبدأ أن مقياس المكون I يجب أن يكون أكثر من مقاييس المكونات I التي تعتمد عليه. أي المقاييس التي يجب أن أنقصها في اتجاه التبعية.

من المهم ملاحظة أنه إذا كانت جميع مكونات النظام مستقرة قدر الإمكان ، فلن يكون من الممكن تغيير هذا النظام. لذلك ، لا يجب أن تكون جميع المكونات مستقرة.

رجل ، لا تغفو ، أنا قريب. بقي فقط قليلا!

SAP: مبدأ التجريد المستقر - مبدأ استقرار التجريد. يتناسب استقرار المكون مع تجريده.

"يجب أن تتغير بعض أجزاء أنظمة البرامج نادرًا جدًا. تمثل هذه القطع قرارات معمارية عالية المستوى وقرارات مهمة أخرى. لا أحد يريد أن تكون مثل هذه القرارات متقلبة. لذلك ، يجب أن تتواجد البرمجيات المغلفة لقواعد عالية المستوى في مكونات مستقرة (I = 0). يجب أن يحتوي المتغير (I = 1) على رمز قابل للتغيير فقط - رمز يمكن تغييره بسهولة وسرعة.

ولكن إذا وضعت قواعد عالية المستوى في مكونات مستقرة ، فسيؤدي ذلك إلى تعقيد التغيير في التعليمات البرمجية المصدر التي تنفذها. هذا يمكن أن يجعل العمارة بأكملها غير مرنة. كيفية جعل عنصر بأقصى قدر من الاستقرار (I = 0) مرنًا جدًا بحيث يظل مستقرًا أثناء التغييرات؟ يكمن الجواب في مبدأ الانفتاح / الإغلاق (OCP). ينص هذا المبدأ على أنه من الممكن والضروري إنشاء فئات مرنة بما فيه الكفاية بحيث يمكن أن تكون موروثة (ممتدة) دون تغيير. ما هي الفئات التي تمتثل لهذا المبدأ؟ نبذة مختصرة.

SAP (مبدأ استقرار التجريد) يؤسس اتصال بين الاستقرار والتجريد. من ناحية ، يقول أن المكون المستقر يجب أن يكون مجردًا أيضًا بحيث لا يعوق استقراره التوسع ، ومن ناحية أخرى ، يقول أن المكون غير المستقر يجب أن يكون ملموسًا ، لأن عدم الاستقرار يجعل من السهل تغيير رمزه.

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

تتوافق مبادئ استقرار التجريد (SAP) والتبعيات المستقرة (SDP) معًا مبدأ انعكاس التبعية (DIP) للمكونات. هذا صحيح لأن مبدأ SDP يتطلب توجيه التبعيات نحو الاستدامة ، وينص مبدأ SAP على أن الاستدامة تعني التجريد. أي أنه يجب توجيه التبعيات نحو التجريد.

ومع ذلك ، تم صياغة مبدأ DIP للفصول ، وفي حالة الطبقات لا توجد نغمات متوسطة. الفئة إما مجردة أم لا. تنطبق مبادئ SDP و SAP على المكونات وتسمح بوضع يكون فيه المكون مجردًا جزئيًا أو مستقرًا جزئيًا. "

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

  • Nc: عدد الفئات في المكون.
  • Na: عدد الفئات والواجهات المجردة في المكون.
  • ج: مجردة. A = Na ÷ Nc .

تختلف قيمة المقياس A في النطاق من 0 إلى 1. 0 يعني الغياب الكامل للعناصر المجردة في المكون ، ويعني 1 أن المكون لا يحتوي إلا على فئات وواجهات مجردة.

الاعتماد بين I و A

إذا رسمت على الرسم البياني (Y - abstraction ، X - instability) مكونات "جيدة" لكلا النوعين: مجردة مستقرة وملموسة غير مستقرة ، نحصل على هذا:

صورة

ولكن ، لأن تحتوي المكونات على درجات مختلفة من التجريد والاستقرار ، بعيدًا عن أن تقع في هاتين النقطتين (0 ، 1) أو (1 ، 0) ، وبما أنه من المستحيل اشتراط أن تكون جميع المكونات فيها ، يجب أن نفترض أنه على الرسم البياني A / أنا هناك بعض النقاط التي تحدد المواضع المثلى للمكونات.

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

صورة

منطقة الألم

فكر في المكونات الموجودة بالقرب من النقطة (0 ، 0).

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

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

منطقة عديمة الفائدة

فكر في المكونات الموجودة بالقرب من النقطة (1 ، 1).

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

كيف تتجنب الدخول إلى مناطق الاستبعاد؟

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

المسافة إلى التسلسل الرئيسي

نظرًا لأنه من المرغوب أن يكون المكون موجودًا على التسلسل الرئيسي أو بالقرب منه ، فمن الممكن تحديد مقياس يعبر عن مسافة المكون من النموذج المثالي.

  • D: المسافة. D = | A + I - 1 | . يأخذ هذا المقياس قيمًا من النطاق [0، 1]. تشير قيمة 0 إلى أن المكون موجود مباشرة في التسلسل الرئيسي. تشير القيمة 1 إلى أن المكون يقع على أقصى مسافة من التسلسل الرئيسي.

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

صورة

خاتمة المؤلف (روبرت مارتن)


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

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

ثاني يوم. أم ، أي الجزء 2


المقدمة


ماذا كنت أفرك هناك منذ فترة طويلة؟ "آه ، نعم ... نحن مثل المهندسين المعماريين ، أو نريد حقًا أن نكونهم ، أليس كذلك؟"

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

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

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

وماذا تفعل الآن ، تسأل؟ لذا ، إذا لم يكن لديك أخ كبير في المكتب ، فلا يمكنك إخوانه بدون عين ثالثة.

ملخص الجزء الأول


في الجزء الأخير من المقالة ، تحدثنا قليلاً عن المقاييس التي تمكن المهندسين المعماريين من قياس أعدادهم بالأرقام لتعكس درجة جودة بنية نظامهم.

A - استخراج عنصر
I - عدم استقرار مكون
D المسافة إلى التسلسل الرئيسي على الرسم البياني - / A I مناطق حساس جنسيا من و الألم و عدم جدوى ومناطق

كشف . توصلنا إلى استنتاج مفاده أنه ، من الناحية المثالية ، يجب أن تزيد A وتنخفض بما يتناسب مع الانخفاض ، وبالتالي زيادة في I

. يجب أن تكون المكونات المصممة جيدًا قيد التشغيل أو على الأقل قريبة من التسلسل الرئيسي ، أي يجب أن تكون D قريبة من الصفر قدر الإمكان ، ويجب أن تكون التبعيات بين المكونات غير دورية وموجهة نحو الاستقرار.

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

فماذا عن العين الثالثة؟ PHP العمارة النظيفة- أداة ظهرت نتيجة قراءة كتاب ، بفضل العم بوب (روبرت مارتن) للأفكار القيمة ، والرغبة المجنونة في تصور كل شيء ، من أجل راحة التحليل ، والأتمتة ، لإمكانية تضمين عمليات فحص مختلفة في CI / CD (على غرار PHPStan ، Phan وغيرها ، فقط لتحديد المشاكل المعمارية بدقة).

مشروع ومشروع اختبار. مقدمة للموضوع


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

لذا ، فإن المشروع نفسه يكمن هنا github.com/Chetkov/php-clean-arch architecture-example- project .

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

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

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

في المستقبل ، سوف أقوم بربط الروابط ببعض الالتزامات المحددة من أجل إصلاح النقاط الفنية الموضحة في المقالة على الفور.

الحالة الأولية

، أفترض أنك تمكنت بالفعل من التعرف على الهيكل. حتى نتمكن من المضي قدما.

نحن تشمل PHP النظيفة العمارة :
composer require v.chetkov/php-clean-architecture:0.0.3


نقوم بإنشاء وتكوين ملف التكوين

التصور للتحليل


نقوم بتنفيذ في وحدة التحكم (في جذر المشروع):

vendor/bin/phpca-build-reports
أو
vendor/bin/phpca-build-reports /path/to/phpca-config.php

وردا على ذلك نحصل على:

Report: /path/to/reports-dir/index.html

يتكون التقرير من ثلاث شاشات:

1. معلومات عامة عن النظام

صورة

تعرض هذه الشاشة:

نفس الرسم البياني A / I يوضح تشتت المكونات:

صورة

رسم بياني يوضح بعد المكونات من التسلسل الرئيسي:

صورة

ورسم بياني يوضح العلاقات بين المكونات:

صورة

تشير الأسهم إلى اتجاه التبعيات ، والأرقام عليها تشير إلى قوة الاتصال.

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

على سبيل المثال: تعرف عناصر وحدة الخدمات حوالي 12 عنصرًا من وحدة النموذج ، وعناصر البنية التحتية تعرف عنصر واحد من الخدمات . إلخ.

بالمناسبة ، ما هو * غير محدد *؟؟؟ وإخوانه السؤال المتوقع. هذه وحدة تم إنشاؤها تلقائيًا لجميع العناصر التي ، أثناء تحليل النظام ، لا يمكن أن تُنسب إلى أي من العناصر المعروفة (أي تلك المدرجة في ملف التكوين).

ومع ذلك ، إذا قمت بتصحيح التكوين بهذه الطريقة:

صورة

ثم في عملية تحليل النظام ، سيتم أيضًا أخذ الحزم المتصلة عبر الملحن في الاعتبار (لن يتم فحصها بنفسها ، ولكن الصورة ستصبح أكثر اكتمالًا).

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

بعد تمكين المودعين لقد تغير الرسم البياني ، على الرغم من أننا لم نغير تكوين الوحدات نفسها

صورة

2. معلومات تفصيلية عن المكون

صورة

هنا نرى أيضًا:

  • رسم بياني للاتصالات ، ولكن ليس للنظام بأكمله ، ولكن فقط للمكونات المعنية
  • مخطط A / I يوضح المكون الحالي فقط
  • ميزات الوحدة الرئيسية

    صورة

و
  • يوضح الرسم البياني للتبعية الصادرة عدد وقائمة الملفات في الوحدة النمطية الحالية ، اعتمادًا على ملفات الوحدات الأخرى.
  • صورة

  • و الرسم البياني الواردة التبعيات ، والتي تبين عدد وقائمة من الملفات في وحدات أخرى، اعتمادا على الوحدة النمطية الحالية.

    صورة

الرسوم البيانية الأخيرة ، في رأيي ، مثيرة للاهتمام بشكل خاص ، لأنه من السهل العثور على تبعيات غير مرغوب فيها عليهم ، ولكن المزيد عن ذلك لاحقًا.

3. معلومات تفصيلية عن عنصر المكون

صورة

هنا يمكنك أن ترى:

  • الخصائص الرئيسية لل عنصر، مثل نوع التجريد وعدم الاستقرار وبدائية، و التي ينتمي إليها عنصر و المعدل الوصول .

"تشي ، معدّل الوصول إلى الفصل الدراسي في PHP؟" - تقول ، حفر حفرة في منطقة المعبد بإصبعك ، أليس كذلك؟ خذ وقتك ، وأنا أعلم أنه لا توجد فصول خاصة في الحرارة ، ولكن سيكون من الرائع إذا كانوا؟ بشكل عام ، المزيد عن ذلك لاحقًا.

  • الرسم البياني للتبعية ، الذي يعكس تفاعل العنصر قيد النظر مع عناصر النظام الأخرى

  • و أقراص مع تبعيات الصادرة والواردة

    صورة

مع الانتهاء من وصف الشاشات ، انتقل إلى التكوينات لاختيار وكيزة كيفية تكوينها.

خيارات الإعداد


تحديد الحد الأقصى المسموح به للمسافة إلى التسلسل الرئيسي (لجميع المكونات)

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

صورة

إعادة تشغيل أمر إنشاء التقرير ورؤية الانتهاك على الصفحة الرئيسية على الفور. يتجاوز مكون النموذج المسافة المسموح بها بمقدار 0.192

صورة

تحديد الحد الأقصى للمسافة المسموح بها إلى التسلسل الرئيسي (إلى مكون معين)

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

في رأيي ، فإن الشيء الرئيسي هو إصلاح الوضع الحالي ، والعمل نحو التحسينات والسيطرة على الوضع حتى لا تتفاقم.

مرة أخرى ، انتقل إلى التكوين ، وقم بتعيين max_allowable_distance ، فقط لوحدة معينة. أصلح قيمته الحالية 0.492

صورة

ZBS ، الآن كل شيء طبيعي مرة أخرى.

صورة

ولكن إذا كان يدخن شيئًا ما مرة أخرى مع بعض ** ka Vasya ويزداد سوءًا - يقطع يديه! يقوم CI / CD الذي يتضمن تشغيل الأمر phpca check (سنتحدث عنه لاحقًا) بتوبيخه ، وربما حتى لغة بذيئة ، وبالطبع سوف يسلط الضوء على الأخطاء.

التحكم في الاعتماد على المكونات

ما الذي قد يكون لطيفًا في ترسانتنا للتعامل مع العمارة السيئة؟ بالطبع السيطرة على التبعية. من يستطيع أن يعرف عن من ، أو العكس لا ينبغي أن يعرف.

ما رأيك ، هل يمكن للجزء المركزي للغاية من النظام ، دعنا نقول المجال ، بحيث يمكن لـ DDDowski معرفة شيء عن بعض البنية التحتية ذات الرائحة الكريهة ؟
بالطبع نعم ، بالنسبة للبعض ، إنها سمة نجاح مباشرة (حسنًا ، أنا أتحدث عن أولئك الذين يجعلون HTML ممزوجًا بمنطق الأعمال). ولكن في النهاية ، مثل ، لا ينبغي لي ... أنا بالتأكيد XS ، ولكن جميع أنواع الرجال الأذكياء المختلفين في الكتب يقولون إن هذا ليس باتسانسكي.

ثم دعنا نثير مثل هذا ... كل شيء في نفس المكان ، في تكوين قيود النموذج .

صورة

هم ... حتى الآن ، كل القواعد ، لأننموذج عن البنية التحتية لا يعرف شيئًا حقًا ...

حسنًا ، فلنستمتع ... الغباء نادرًا بالتأكيد ، لكنني لم أتوصل إلى أي شيء أفضل. Krch ، في وقت إنشاء المستخدم ، سوف "نرسل" رسائل SMS ، وفي وقت إنشاء الطلب (الرسائل) "إرسال" البريد الإلكتروني. وللقيام بذلك من خلال تطبيقات محددة لمخطرين يكمن في البنية التحتية .

github.com/Chetkov/php-clean-arch architecture-example-project/commit/6bad365176b30999035967319a9c07fae69fabf9

الآن ننظر إلى التقرير ... كما نرى ، الرسوم البيانية على صفحات مختلفة من التقرير تبرز هذا الاتصال على أنه غير شرعي.

الصفحة الرئيسية.

صورة

تقرير المكونات.

صورة

على الرسوم البيانية لنموذج "التبعيات الصادرة" و "التبعيات الواردة"البنية التحتية ، نرى على الفور العناصر التي تنتهك القاعدة المقدمة

صورة

في جداول "التبعيات الصادرة" لعناصر النموذج و "التبعيات الواردة" لعناصر البنية التحتية ، بالمثل.

PHPCAEP \ Model \ User \ User

صورة

PHPCAEP \ Model \ البنية التحتية \ الإخطار \ Sms \ SmsNotifier

صورة

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

صورة

ويمكن أن يتم اتخاذ إجراءات مماثلة مع allowed_dependencies التكوين .

صورة

ستكون النتيجة معاكسة تمامًا.

من الممكن إنشاء تكوين يشير إلى الوحدة والممنوع، ومسموح (إذا كانت هناك رغبة ، سنناقش بمزيد من التفصيل في التعليقات). فإنه ليس من الممكن بعد تحديد عنصر واحد في كل من حرم و سمح ... وكانت هناك أفكار لإدخال التكوين تشير إلى الأولوية، ولكن حتى الآن لم تكن قد فعلت ذلك، ولست متأكدا ما سأقوم به. كل هذا يتوقف على ملاحظاتك. ربما يضيع كل هذا؟

فئة عامة / خاصة في PHP

حسنًا ، لقد تعلمنا كيفية تضييق نطاق المعرفة بالمكونات والتحكم فيها. بالفعل ليست سيئة. ماذا بعد؟

ثم مشكلة أخرى. العدو لا ينام ، على الرغم من أننا في معظم الحالات هذا العدو ، نحن أنفسنا ، أو رفاقنا في المكتب.

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

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

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

مثال الآن سيكون مرة أخرى من مدمني المخدرات ، ولكن ماذا تفعل.

في المشاريع الحقيقية ، بالطبع ، الحالات مليئة بالحالات ، ولكن يمكنهم إحضار زجاجة لتجفيف المعلومات ويطلب منهم الجلوس. لهذا السبب عليك التأليف.

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

صورة

ماذا يوجد لدينا الآن؟

الاعتماد على الرئيسي.

صورة

يمكنك أن ترى على الفور المكونات التي تحتاج إلى المراجعة.

نتسلق لنرى ما هو الخطأ في البنية التحتية .

صورة

في الرسم البياني لـ "التبعيات الصادرة" نرى العناصر التي تنتهك القاعدة:

صورة

في صفحة معلومات العنصر ، بالمثل.

صورة

سنحصل على النتيجة المعاكسة تمامًا إذا حددنا private_elements في التهيئة .

صورة

على سبيل المثال ، نمنع الجميع من معرفة Fio.

الآن على

صورة

الصفحة الرئيسية: في صفحة معلومات مكون الخدمات :

صورة

وعلى صفحة معلومات العنصر PHPCAEP \ Model \ User \ Fio :

صورة

مراقبة انتهاكات مبادئ ADP و SDP

مع ذلك ، ربما نحتاج إلى تسليط الضوء على إمكانية تضمين الشيكات:

  • عن انتهاكات مبدأ ADP ، أي لوجود تبعيات دورية في الرسم البياني ( check_acyclic_dependencies_principle )
  • وانتهاك مبدأ SDP ، أي للتبعيات الموجهة من وحدات أكثر ثباتًا إلى أقل ثباتًا ( check_stable_dependencies_principle )

صورة

لكن هذا يعمل فقط في phpca-check حتى الآن ولا يتم عرضه في التقرير. في المستقبل ، أعتقد أنني سأصححه.

تحكم آلي في CI / CD


كل هذا الوقت تحدثت عن الجزء الأول - التصور. والتحليل الذي يمكن إجراؤه على أساسه.

لقد حان الوقت لجعل أصدقاءنا govnokodera الشرفاء يعانون.

أطلقنا في وحدة التحكم (في جذر المشروع):

vendor/bin/phpca-check

أو

vendor/bin/phpca-check /path/to/phpca-config.php

من المفترض أن تشغيل هذا الأمر سيتم إضافته إلى عملية CI / CD لمشروعك. في هذه الحالة ، سيحظر الخطأ المزيد من التجميع.

سينتهي البرنامج النصي بخطأ ويلقي بشيء من هذا القبيل:

صورة

أعطي السن ، وستكون القائمة أطول بكثير في مشروع حقيقي.

استخلاص المعلومات

  1. انتهاك مبدأ عدم التبعية التبعيات (ADP)
  2. وبالمثل ، ولكن الدورة أقصر بقليل
  3. 2 عناصر النموذج (المدرجة) تعتمد على البنية التحتية ، وهو ما لا يسمح به التكوين
  4. انتهاك ADP مرة أخرى
  5. حلقة أخرى وانتهاك ADP
  6. انتهاك SDP بسبب يعتمد النموذج الأكثر استدامة على بنية تحتية أقل استدامة
  7. مرة أخرى الاعتماد الدوري ، سواء كان ذلك خطأ
  8. 1 عنصر خدمات (مدرج) يعتمد على المعلومات غير العامة

تقريبًا هذه النتيجة لدينا بفضل جهودنا و govnokoding الدؤوب .

الآن دعونا ندير كل شيء في المؤخرة. حسنًا ، على سبيل المثال ليس كل شيء تمامًا ، أترك التكوينات بشكل طبيعي. أنا أحكم الرمز فقط.

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

استكشاف الأخطاء وإصلاحها

أزلت إدمانًا تم اختراعه سابقًا.

github.com/Chetkov/php-clean-architecture-example-project/commit/f6bbbf713ebb4a22dfb6061f347ef007ba3b422f

إعادة تشغيل بائع / بن / phpca الاختيار

صورة

حسنا، هناك فقط التكوين المناسب، كما مثال تم اختراعه بالفعل من قبل مدمن مخدرات.

صورة

مرة أخرى بائع / بن / phpca الاختيار واصل

صورة

CI / CD!

هذا كل شئ.

خاتمة


التقط خامسًا إذا قرأته حتى النهاية ، إذا لم يكن كذلك ، فشم قدمك على الطريق (على أي حال ، لم تر هذا).

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

أعتذر مرة أخرى إذا كان هناك شيء خاطئ.

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

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

كود نظيف وعمارة مرنة بالنسبة لك!

All Articles