خلال مسيرتي المهنية ، عملت مع العديد من المشاريع التراثية ، والتي يعاني كل منها من عيوب مختلفة.

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

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

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

تشارك شركتك بأكملها قاعدة البيانات الخاصة بك

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

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

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

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

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

نظامك مرتبط بالبرنامج المستخدم في الشركة

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

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

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

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

الربط القوي بين التطبيقات المتعددة

تذكر أوائل العقد الأول من القرن الحادي والعشرين: كم كان من الممتع استخدام Enterprise Java Beans (EJB) للتعامل مع المكالمات عن بُعد بين التطبيقات في نظام المعلومات الخاص بك. في ذلك الوقت ، قد تبدو هذه فكرة جيدة. كما أن مشاركة الرمز الخاص بك مع فرق أخرى لتجنب التكرار تبدو جيدة أيضًا. نعم ، تم إجبار جميع الفرق على طرح تطبيقاتهم في نفس الوقت للتأكد من أن التبعيات الثنائية لم تنكسر ، ولكنها كانت أمسيات ممتعة - تناول البيتزا مع الزملاء أثناء انتظار تسليم الطلب لمدة ساعتين ، أليس كذلك؟

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

بمجرد أن تدرك مدى الخلط بين هذه القرارات المبكرة ، فإن الجهد المطلوب لفصل تطبيقك عن بقية العالم ضخم. كما ترى ، بالمعنى الحرفي ، سيستغرق الأمر سنوات لتقطيع مشروعك إلى مكونات مختلفة بحيث لا يمكن للتطبيقات الأخرى استخدام جوهر مجال الموضوع الخاص بك أو عميلك أو آلية التخزين المؤقت ؛ لإزالة جميع المكالمات إلى الفصول الخارجية التي تؤدي إلى ارتباط قوي بمشاريع أخرى ؛ لاستبدال جميع مكالمات EJB بواجهة برمجة تطبيقات REST ... ومع ذلك ، لكل هذه الجهود ، سيتم مكافأة كل موظف مرتبط بالمشروع: سيتم تبسيط التطوير والاختبار ، وستسرع عملية التسليم ، حيث لم تعد هناك حاجة الآن لمزامنة عملك مع شخص آخر ؛ المفاهيم في الكود الخاص بك ستصبح منفصلة بشكل أفضل ؛ سيتم تبسيط إدارة التبعية ، وستختفي المشكلات المتعلقة بالتبعيات متعدية عندما تقوم باستيراد مجموعة من تبعيات التطبيقات الأخرى إلى مسار الفصل الدراسي الخاص بك ... كل هذه التغييرات المكلفة سوف تنقذ حياة الفريق وستكون أسهل في التنفيذ إذا قمت بها في فجر المشروع!

تقوم ببناء مشروعك على أساس مشروع شخص آخر

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

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

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

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

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

يتم تخزين كل منطق عملك داخل نظام إدارة القواعد

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

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

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

إذا كان هذا يبدو بالفعل مشكلة ، فإليك شيء آخر: لم يكن هناك أي دليل على الإطلاق عن غرضه في أي قاعدة. تم تسمية القواعد مثل Rule1 و Rule2 وما إلى ذلك ، بإجمالي يزيد عن 100! وبشكل أساسي ، تتكون كل قاعدة من عمليات فحص وتعيين قيم مشفرة بدون أي مصطلحات المجال. حتى اسم المشروع لم يوضح الغرض من ETL بأكمله ككل.

الخلاصة

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

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

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