♈️ 🔅 🚂 كيفية قراءة وإصلاح 100000 سطر من التعليمات البرمجية أسبوعيًا 🐖 🛸 👌🏼

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

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

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

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

النهج في شركتنا

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

هناك نوعان من تقييم الهندسة المعمارية.

داخليًا - نقوم بذلك عادةً للمشاريع داخل الشركة. يمكن لأي مشروع طلب تقييم معماري لعدة أسباب:

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

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

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

تقييم بنية مشروع المؤسسة

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

المشاكل التي يمكن للعميل أن يشتكي منها وقد يعرف عنها:

قضايا الأداء
قضايا الاستخدام
نشر طويل
عدم وجود وحدة واختبارات أخرى

المشاكل التي لا يعرفها العميل على الأرجح ، ولكنها قد تكون موجودة في المشروع:

مشاكل السلامة
مواضيع تصميمية
عمارة غير صحيحة
أخطاء حسابية
تكنولوجيا غير مناسبة
الدين الفني
عملية تطوير غير صالحة

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

هذه عملية رسمية نلتزم بها في الشركة ، ولكن يمكنك تعديلها بنفسك اعتمادًا على شركتك ومشروعك.

طلب العميل

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

مهندس الحلول هو الشخص الرئيسي المسؤول عن التقييم والتنسيق (وغالبا ما يكون الشخص الوحيد).
يمكن تكديس خبراء معينين من Stack - .Net و Java و Python وغيرهم من الخبراء التقنيين اعتمادًا على المشروع وتقنيات
خبراء السحابة - وهم مهندسو السحابة Azure أو GCP أو AWS.
البنية التحتية - DevOps ، مسؤول النظام ، إلخ.
الخبراء الآخرون هم البيانات الضخمة ، التعلم الآلي ، مهندس الأداء ، خبير الأمن ، قائد ضمان الجودة.

جمع معلومات المشروع

يجب عليك جمع أكبر قدر ممكن من المعلومات حول المشروع. يمكنك استخدام تقنيات مختلفة حسب الموقف:

الاستبيانات ووسائل الاتصال الأخرى عبر البريد. الطريقة الأكثر كفاءة.
اجتماعات عبر الإنترنت.
أدوات خاصة لتبادل المعلومات مثل: مستندات Google و Confluence والمستودعات وما إلى ذلك.
اجتماعات "حية" في المكان. الطريقة الأكثر فعالية والأغلى.

ما الذي يجب استلامه من العميل؟

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

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

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

juskeys الأساسية وتدفق البيانات.

الوصول إلى كود المصدر . اهم جزء! يجب عليك بالتأكيد الوصول إلى المستودعات والوثائق حول كيفية تجميع المشروع.

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

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

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

كيف إذن معالجة مثل هذه الكمية الكبيرة من المعلومات في مثل هذا الوقت القصير؟ بادئ ذي بدء ، موازاة العمل.

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

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

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

أدوات مفيدة لأتمتة تقييم المشروع

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

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

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

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

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

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

New Relic - أداة تقييم أداء التطبيقات
Datadog - خدمة مراقبة الأخت القائمة على السحابة

هناك العديد من الأدوات لاختبار الأمان. هذه المرة سأوصيك بأداة مسح النظام المجانية.

OWASP ZAP هي أداة لفحص تطبيقات الويب للامتثال لمعايير الأمان.

ضع كل شيء معا.

نحن نعد تقريرا

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

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

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

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

ننتهي من تقييم الهندسة المعمارية ونزود العميل بتقرير

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

كموجز لمسيرة الخاص بك ، أرسل تقريرك إلى العميل.

أخيرا

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

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

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

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

مقالات أخرى من قسم الهندسة المعمارية في وقت فراغك.

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

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

كيفية قراءة وإصلاح 100000 سطر من التعليمات البرمجية أسبوعيًا