هندسة البرمجيات وأوضح: دليل بسيط على أنماط الأدوار و التكنولوجيا الدين

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

A visual diagram explaining software architecture. The center shows three system layers: User Interface, Business Logic, and Infrastructure. The left side lists architecture patterns like Microservices and team roles such as Architect and DevOps. The right side lists common causes of Tech Debt, including Legacy Code, Code Smell, and Outdated Libraries.
البصري انهيار هندسة البرمجيات تبين كيف التنمية المختلفة أدوار الأنماط الحديثة و التقنية الدين التفاعل عبر الواجهة الأمامية, الخلفية, و البنية التحتية طبقات.

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

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

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

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

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

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

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

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

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

The Difference in Roles: Who Builds What?

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

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

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

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

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

How Architects Record Decisions: The ADR

هل اتخذت من أي وقت مضى على المشروع بدا في غريب سطر من التعليمات البرمجية ، وتساءل: "لماذا على وجه الأرض لم الأخير المطور بناء هذا الطريق؟"

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

اليوم, الحديثة تستخدم فرق شيئا أكثر ذكاء يسمى ADR (العمارة القرار رقم قياسي).

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

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

  • العنوان: ما هو بالضبط القرار ؟ (على سبيل المثال ، "استخدام الشريط على موقع المدفوعات").
  • حالة: هل هذا القرار المقترح أو قبوله أو رفضه ؟
  • السياق: ما هي المشكلة ؟ لماذا نحن بحاجة إلى اتخاذ خيار اليوم ؟
  • القرار: ماذا نفعل ؟ أي أداة أو نمط نحن اختيار لحل المشكلة ؟
  • النتائج: ما هي النتيجة ؟ (على سبيل المثال ، "سيكون أسرع بكثير لبناء, ولكن سوف تضطر لدفع رسوم 3% على جميع المعاملات").

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

Specific Modern Architecture Patterns

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

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

متراصة مقابل Microservices
تخيل أنك البناء التقليدية سكين الجيش السويسري. وقد سكين, مفك, الملف, و مقص جميع جسديا انسحب معا إلى مقبض واحد.

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

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

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

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

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

Event-Driven Architecture

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

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

Serverless Architecture

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

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

Managing Technical Debt and Business Budgets

في عالم تطوير البرمجيات ، مع اختصار إلى توفير الوقت يخلق ما يعرف باسم "تقنية الدين".

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

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

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

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

قادة الأعمال وكبار المديرين التنفيذيين عموما لا يهتمون "رمز نظيفة" أو "إعادة بيع ديون واجهات برمجة التطبيقات." أنهم يهتمون الإيرادات, خطر, و سرعة. مهندس جيد يترجم الديون التقنية في الصارم الشروط التجارية.

بدلا من أن تقول: "نحن بحاجة إلى أسبوعين لإعادة كتابة متجانسة قاعدة البيانات لأن الرمز هو الفوضى."
يقولون: "الآن لدينا قاعدة بيانات امتدت إلى الحد المطلق. إذا كنا لا قضاء أسبوعين تحديد ذلك الآن, موقعنا سوف يرجح تحطم الطائرة خلال العطلة القادمة البيع ، والتي يمكن أن تكلف 50 ، 000 دولار أمريكي في العائدات المفقودة."

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

الختام

بناء البرمجيات الناجحة ليست فقط حول كتابة أسطر من التعليمات البرمجية في الكمبيوتر. هو عن تنظيم الفوضى.

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

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


الأسئلة المتداولة

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

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

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

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

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


مصادر

وهنا بعض ممتازة ، مصادر موثوقة لمعرفة المزيد عن عميق مفاهيم هندسة البرمجيات و تطوير:

انتقل إلى أعلى
×

دعونا نبدأ شيء عظيم

⚡ تلقى!

أنا بتحليل طلبك والاتصال بك قريبا.