كتاب "العمارة التطورية. دعم التغيير المستمر "

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

العمارة التطورية: الفخاخ والمضادون

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

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

العمارة التقنية

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

أنتيباتيرن: بائع الملك

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

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

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

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

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

لا تربط بنيتك مع ملك المورد.

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

فخ: تجريد هولي

جميع التجريدات غير التافهة ممتلئة إلى حد ما بالثقوب.
- جويل سبولسكي

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

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

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

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


كما يتبين من الشكل. 7.2 ، توسع كل جزء من النظام البيئي للبرنامج وأصبح أكثر تعقيدًا. كلما أصبحت المشاكل التي يواجهها المطورون أكثر تعقيدًا ، أصبحت حلولهم كذلك.

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

حاول أن تفهم تمامًا مستوى تجريد واحد على الأقل دون المستوى الذي تعمل فيه عادةً.
- برنامج حكماء

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

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

»يمكن العثور على مزيد من المعلومات حول الكتاب على موقع الناشر على الويب

للحصول على خصم 20٪ على habrozhitelami على القسيمة - العمارة التطورية