تطوير هندسة المشروع والسفن وجافا سكريبت

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

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



تستند المقالة على تقرير أعده أليكسي بوغاشوك (مهندس حلول EPAM) من مؤتمر HolyJS 2018 Piter . تحت مشهد - فيديو ونسخة من التقرير.

مناهج بناء العمارة ودور مهندس المشروع

سبح - نحن نعلم

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



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

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

• يجب أن تكون السفينة هي الأكبر في أسطول بحر البلطيق: بطول 70 متر وعرض 10.
  
• أنت بحاجة إلى ثلاث طوابق تتسع لـ 300 جندي ؛
  
• يجب أن يكون لديه 64 بندقية على متن صفين ؛
  
• يتم منح 3 سنوات للبناء.
  

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

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

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

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

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

أصدقاء أقوياء

كم عدد التطبيقات ذات البنية الخاطئة التي ماتت قبل كتابة السطر الأول من التعليمات البرمجية؟
دورة تأثير العمارة على المشروع هي كما يلي:



من اليسار الى اليمين:

1. هناك أطراف معنية ، أو أصحاب مصلحة (في حالة السفينة ، هذا هو الملك والخزينة).
   
2. لديهم أهدافهم الخاصة (أول سفينة في أوروبا).
   
3. تحدد الأهداف المتطلبات (الخصائص المحددة للسفينة المستقبلية).
   
4. بعد ذلك ، يتم عمل الرسومات والرسوم البيانية والتصاميم.
   
5. البناء على المشروع.
   

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

كتيب مهندس الحلول

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

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

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

قصة تصورها جيمي

متطلبات العملاء

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

ما تم القيام به

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



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

ما هو الخطأ؟ في المرحلة الأولى من تحديد العمارة ، تم تحديد أصحاب المصلحة بشكل غير صحيح.

الخلاصة

تبدأ أي بنية بتحديد أصحاب المصلحة. من أجل تحديدها ، هناك العديد من الأساليب ، سننظر في أحدها - سنقوم ببناء مصفوفة RACI.

راسي

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



بعد بناء هذه المصفوفة ، يمكننا أن نفهم من هم أصحاب المصلحة.

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

بصل

نهج البصل يختلف إلى حد ما عن مصفوفات RACI.



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

لذا ، نكتب في دليل المهندس المعماري لدينا أن المرحلة الأولى والضرورية هي تحديد أصحاب المصلحة.

التاريخ: ليس بالسرعة الكافية

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

متطلبات العملاء

• كن أسرع من المنافسين
  

• من الضروري إجراء المعاملة في مدة لا تزيد عن 0.5 ثانية.
  

ماذا فعل

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

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



الخلاصة

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

يمكنك العثور على توصيات مفيدة في كتاب "متطلبات الاكتشاف" ، المؤلفون - إيان ألكسندر ، لييركا بيوس-دوكيتش.

قصة كيف تحلم رواد الحصان

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

متطلبات العملاء

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

ماذا فعل

بناءً على المتطلبات ، تقرر الكتابة في React Native. بدأ التطوير. خلال المكالمة الأولى ، تم تلقي التحسينات والإضافات على المتطلبات:

• تصدر الشركة هواتف للموظفين ، ويعملون جميعًا على Android.
  
• العميل مهتم فقط بوضع عدم الاتصال.
  
• الموعد النهائي - شهرين.
  

من الواضح أن مهمة فرز منتج جاهز من جهة خارجية مع منطق تجاري معقد وكتابة منتج جديد في شهرين لا تتناسب مع هذا الإطار الزمني. تقرر استخدام PWA (تطبيقات الويب التقدمية).

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



لذا ، كانت المشاكل مع المتطلبات ، التي ليست بهذه البساطة. فكر في مثال على ما هي المتطلبات:



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



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

الخلاصة

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

قصة الغراب الأبيض

متطلبات العملاء

• تطوير خدمة منفصلة تقوم بتحويل وتخزين البيانات في تنسيق xml.
  
• يجب أن يفعل ذلك من نظام إرث طرف ثالث.
  

ماذا فعل

قمنا بتطوير خدمة عمل جيدة ، فعلنا ذلك على Node.js. هذه هي الطريقة التي بدأ بها النظام ككل في الظهور بشكل تخطيطي مع الخدمة الجديدة المقدمة.



من الواضح أن Node.js هي خروف أسود هنا ، على الرغم من حقيقة أن كل شيء يعمل بشكل جيد.

تم اكتشاف الخطأ أثناء نقل الخدمة للعملاء الذين لم يكونوا على دراية بـ Node.js. يوضح هذا الموقف بشكل مثالي دور تحديد القيود للمشروع. ما هي القيود؟

• تقني
  
• الوقت والميزانية
  
• مكدس مطور العملاء
  

الخلاصة

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

بعد ذلك ، ننتقل إلى سمات الجودة ، لدينا اهتمام خاص بها.

سمات الجودة

مكتبة آمنة للغاية

هناك الكثير من سمات الجودة ، ما عليك سوى إلقاء نظرة على القائمة التي تقدمها لنا ويكيبيديا.



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

الهاتف في الغابة

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



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

• تحسين تجربة المستخدم بحيث يبدو للشخص أن الإنتاجية أعلى.
  
• تحسين الموارد (JS و CSS والصور والخطوط وما إلى ذلك).
  
• تنفيذ التخزين المؤقت.
  
• إضافة عمال الخدمة ، المسار الحرج.
  
• تطبيق الضغط.
  
• HTTP / 2.
  

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

دعونا نحاول استخدام نمط CQRS (فصل مسؤولية استعلام الأمر). يؤثر استخدام هذا النمط كتكتيك حتى على عدة طبقات من التطبيق: كلا من الواجهة الخلفية والواجهة الأمامية.



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



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

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

جندي من الصفيح الصامد

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

لكي يعمل التطبيق بشكل مستقر ، يمكن تطبيق مبدأ الفشل السريع:

• تحقق دائمًا من نقاط التكامل مقدمًا.
  
• تجنب الاتصالات البطيئة.
  
• تحقق من إدخالاتك.
  

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



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

غواصة

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

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

دلو متسرب

يتم استخدام استراتيجية مشابهة لتلك الموضحة أعلاه في نمط Leaky Bucket.



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

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



ماذا تعني السهام الخضراء؟ تتفاعل الخدمات المختلفة مع بعضها البعض من خلال بروتوكولات وقواعد بيانات متنوعة وخدمات أخرى.

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



نوصي أيضًا بكتاب "هندسة البرمجيات في الممارسة" للكاتب لين باس ، بول كليمنتس ، ريك كازمان. ستتعلم فيه سمات أخرى للجودة وتكتيكات اتباعها.

مثال الحلوى

الحالة

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

افترض أنه يمكنك استخدام الأطر التالية لحل هذه المشاكل:



لقد وجدنا بالفعل الأطراف المهتمة. تحتاج إلى تحديد الأهداف.

الهدف الأكثر عالمية هو إرضاء العميل.

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

ثم يتم اكتشاف القيود التالية:

• تحتاج إلى الكتابة في Drupal ، حيث اشترى العميل ترخيصًا ودعمًا لبعض الوقت.
  
• يستخدم المشروع ReactJS و VueJS ، ويريد العميل أن يستمر ، الشركة ليست مستعدة للنظر في إطار آخر.
  

بعد تحديد سمات الجودة ، اكتشفنا:

• من المهم ترك القدرة على دعم جميع المواقع الـ 400 (قابلية الصيانة).
  
• , (testability).
  
• (re-usability).
  
• (performance).
  
• (accessibility).
  

عندما نبني العمارة ، نحتاج إلى اتباع نموذج معين. خذ بعين الاعتبار نموذج C4. تم بناء العديد من الرسوم البيانية.

مخطط السياق:



تحديد أدوار الأشخاص الذين سيعملون مع النظام الأساسي. في هذا المثال ، هؤلاء هم الزوار والمطورين ومديري المحتوى.

ننتقل إلى مخطط الحاوية:



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

مخطط مكون يبدو كما يلي:



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

كيفية تسريع سير عمل إدارة المحتوى؟ من الضروري توفير الفرصة لمديري المحتوى للعمل مباشرة مع وحدة إنشاء الموقع. مع تذكر جميع الممارسات السابقة ، نضيف الأساليب الضرورية إلى وحدة خدمة Template Service. لاحظ أن دروبال يستخدم فقط في محور المحتوى. نستنتج أنه بالنسبة للجيل الثابت ، فإن أطر NuxtJS أو Next.js ، المكتوبة في Vue.js و React.js ، على التوالي ، مناسبة. كبديل لنقاط التكامل ، من المفيد استخدام GitHub والفروع ، لذلك نأتي إلى نهج JAM. تم فك تشفيره مثل JavaScript و API و Markdown.



يمكن ملاحظة أن المكدس الذي تقرر استخدامه يختلف عن الأصل. من ناحية ، استخدمنا Node.js ونوع من الإطار الحديث. سنترك Drupal لإدارة المحتوى ، ولكن من خلال تنظيمه من نظامنا ، سنتمكن من الاندماج مع نظام إدارة المحتوى الجديد في المستقبل ، والذي قد يكون أكثر ملاءمة وأسرع. وهكذا توصل إلى فهم نهج جافا سكريبت و API و Markdown.

خاتمة

تحتاج إلى اختيار مجموعة التكنولوجيا النهائية بعناية. هذا ما نكتبه في كتابنا المعماري.

القصة النهائية

حددت شركة Case Architect جميع أصحاب المصلحة والمتطلبات والأهداف والقيود. ثم تم عمل مشروع معين. كان تطوير التطبيق طبيعيًا ، لكن في النهاية فشل المشروع.

لماذا حدث هذا؟

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

خاتمة

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

الملخص

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

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

إذا أعجبك التقرير ، انتبه: في 24-25 نوفمبر ، سيعقد HolyJS جديد في موسكو ، وسيكون هناك أيضًا الكثير من الأشياء المثيرة للاهتمام هناك. توجد معلومات معروفة بالفعل عن البرنامج على الموقع ، ويمكن شراء التذاكر هناك.