يمكنك التحدث كثيرًا حول بنية التطبيق ، ومبادئ SOLID ، و OOP ، والأنماط المعمارية مثل الطبقات أو البصل ، إلخ. أنماط التصميم. خلال تجربتي ، أدركت شيئًا واحدًا هو عدد الأشخاص الذين لديهم آراء كثيرة. عندما تكون مبرمجًا مبتدئًا لديك الكثير من الطموحات ، فإنك تزداد قليلاً في التأهيل ، لديك شعور بأنك تعرف كل شيء ، وكل شيء تم فعله لك هو "سيئ" ، وستكون بالتأكيد أفضل ... لكن السنوات تمر وتدل التجربة المكتسبة على عكس ذلك. تحت القص ، سأحاول باختصار ، والأهم من ذلك ، بكلمات بسيطة ، أن أخبركم عن مدى جودة الهندسة المعمارية. على الأقل قابلة للتوسيع والدعم ، للحصول على تفاصيل ، أطلب قطة ...
أولاً وقبل كل شيء ، لإنشاء بنية جيدة للمشروع ، تحتاج إلى تحديد ميزاته:
- يجب دعم البنية.
- نظام التمدد دون عكازات.
- مرونة الإعدادات ، يجب حل العديد من المهام دون تغيير رمز البرنامج.
- موثوقية الهندسة المعمارية.
النقطة الأولى هي أن سهولة الدعم يتم حلها باتباع مبادئ SOLID ، وبشكل أساسي ، بطبيعة الحال ، مبدأ "تفرد المسؤولية" ، لذلك تحتاج إلى اختيار بنية قائمة على الخدمات الصغيرة أو بنية نمطية لنظام أساسي متجانسة. لا يوجد فرق جوهري بين هذه الأساليب. بالنسبة للمشروع الذي أعمل عليه ، اخترت المنهج الثاني ، الوحدات النمطية.
يمكن حل النقطة الثانية باستخدام نمط برمجة الأحداث - المراقب أو المرسل ، فهي تشبه بعضها البعض ، لذلك لن نركز على هذا. جوهر عملهم هو إلقاء بعض الرسائل من الوحدة النمطية التي يتم تنفيذها حاليًا ، وإذا لزم الأمر ، استمع إلى الوحدة التي تحتاج إلى العمل مع هذا الكائن.
يتم أيضًا حل الفقرة الثالثة بكل بساطة ، الجزء الوصفي للكيان ، أي سمات الكيانات المخزّنة بشكل منفصل عن الكيان نفسه. هذا مرجع إلى EAV (قيمة سمة الكيان). لا يتعين عليك معالجة جميع حقول كيان لمنطق الأعمال ، وبعض السمات تحمل عبءًا إعلاميًا ، بينما يُستخدم البعض الآخر للفرز والتصفية ، وجزء فقط لبناء منطق العمل. لذلك ، إذا تم تخزين الكيان كـ EAV ، فيمكننا في أي وقت إضافة أو إزالة سمة لا نحتاج إليها.
النقطة الرابعة من متطلباتنا هي الموثوقية ، مما يعني الحد الأدنى من "العكازات" والمزيد من الأتمتة. تتكون معظم تطبيقات الويب من واجهات عرض البيانات ، والجداول ، والمرشحات ، والفرز ، وبطاقات الكيان. واجهات إدخال البيانات والنماذج. لذلك ، يجدر استخدام المصانع للنماذج ، والمصانع للجداول ، والمصانع للبطاقات. المزيد من الأتمتة ، في النهاية يمكننا أن نستخلص من مجال العرض ، ونركز على منطق الأعمال والمهام الفنية ...
وهكذا توحي الخاتمة نفسها بأنه من أجل بناء بنية جيدة ، من الضروري أن يتم التجريد ، وأن نقرر التقنيات وأنماط البرمجة وأن نبني الأساس لبدء التطوير ...
الآن قمنا بتطوير خطة ، قررنا المتطلبات ، ثم نحتاج إلى تحديد كيفية بناء الهيكل. في الواقع ، أنا لا أفهم كل هذه البنى الطبقات أو البصل. أخذت شيئًا منهم واخترعت شيئًا بنفسي ، ولا أرى شيئًا فيه إذا فهم الناس ما يعنيه. في الواقع ، فإن الهيكل كله يأتي إلى خطوات بسيطة:
- الأساس هو التجريد (فئات مجردة وواجهات تحدد عقد مكونات مختلفة من النظام مدمجة في وحدات)
- بعد ذلك ، لدي طبقة kernel تدير الوحدات وتديرها.
- تحميل نظام التخطيط
- بعد بدء تشغيل الوحدة النمطية ، كل وحدة نمطية مثل microservice منفصلة
ولكن ما الذي يجعل العمارة جيدة؟ السؤال ليس بسيطًا ، لكن إذا تم تبسيط كل شيء وفقًا لمستوى التفكير الفلسفي ، فسيتم الرد على هذا السؤال. بعد بدء التطبيق. لدينا أجزاء معزولة ، وحدات. كل وحدة مسؤولة عن وظيفة نظام واحد فقط. نذهب إلى أسفل كل وحدة ، صممت كتطبيق mvc ولها وجهة نظر ، وحدة تحكم ، نموذج. وكل جزء من الوحدة النمطية مسؤول أيضًا عن كل إجراء من أعماله. نحن نذهب لأسفل بشكل أعمق وسنرى أن طريقة العرض تحتوي أيضًا على أجزاء معينة ، وهي فئات المصنع ، وملحقات المخطط. في الواقع ، تعد المخططات أيضًا وحدة نمطية ، يتم تحميلها أولاً وقبل كل شيء ، وتكملها جميع الوحدات الأخرى ، وبناء واجهة (أو نظام إخراج). ولكن كيف تجعل كل هذا أقل اعتمادا تسأل؟ وستكون الإجابة واضحة للمراقبين ، فكل تجسيد لكل كتلة تخطيط يلقون بها حدثهم ، تحتاج فقط إلى الاستماع إلى هذا الحدث ، والمراقب في التطبيق الخاص بك ، وإضافة تحديث الكتلة الضروري في الطبقات ، والحصول على الإخراج المناسب. تحتوي العديد من الوحدات النمطية أيضًا على الأحداث الخاصة بها ، والتي تشترك فيها الوحدات النمطية الأخرى وتكون قادرة على إضافة / أو تحديث البيانات في المجموعة المنقولة. كل هذا يؤدي إلى حقيقة أنه في التطبيق ، ترتبط الوحدات قليلاً مع بعضها البعض ويمكن أن تعيش دون بعضها البعض.
في ضوء ما سبق ، يطرح سؤال معقول: إذا كانت وحدة واحدة تستمع إلى وحدة أخرى ، فمن الضروري وجود نوع من نظام إدارة التبعية لهذه الوحدات. وهذا هو ، الوحدة التي تعتمد عليها وحدة أخرى ، يجب أن نبدأ في المقام الأول ، والوحدة التي تعتمد ، يجب أن نعمل بعد. وهكذا وُلد تنفيذ بسيط للاعتماد ، نقوم بإنشاء قائمة انتظار لإطلاق الوحدات وننظمها ببساطة بحيث يتم تحميل الوحدات التي يعتمد عليها أي شخص آخر أولاً ، بعد تحميل النواة ، بالطبع.
في الختام ، أستطيع أن أقول ما يلي. العمارة الجيدة ليست مهمة صعبة وطويلة الأجل لحفظها. وفي النهاية ، يساعد على إنفاق الموارد والوقت بشكل أكثر كفاءة. بعد كل شيء ، تغيير الإعداد في لوحة التحكم هو شأن مدته خمس دقائق. لكتابة سطرين للإضافة ليس الكثير من الوقت أيضًا. لكن التوصل إلى نتيجة ، عكس كل واحدة ، وتصحيح كميات كبيرة من البيانات هو بالفعل وقت أطول بكثير من الوقت لتطوير استراتيجية إنشاء الهندسة المعمارية.