لقد قرأت الكثير من الأشياء على الإنترنت، ومن الصعب حقًا العثور على أي شيء حول بنية برامج JAVA، ومع ذلك، فإن بنية تطوير البرامج هي نفسها في الأساس. لذلك قمت بالبحث في العديد من المقالات حول هندسة البرمجيات بلغات أخرى على الإنترنت. هنا مرة أخرى، اسمحوا لي أن أتحدث عن آرائي حول هندسة البرمجيات، وخاصة فيما يتعلق بهندسة مشروع JAVA. قد لا يكون ذلك صحيحا، ولكن هذا هو أيضا ملخصي للسنوات القليلة الماضية.
1. حاول ألا تفكر في إعادة الاستخدام خارج المشروع
يعتقد الكثير من الناس أنه من الأفضل تحسين إمكانية إعادة استخدام البرامج، ومع ذلك، فإن الوضع الفعلي لكل مشروع سيكون مختلفًا عند تصميم وحدة نمطية أو طريقة معينة في المشروع، فإن الكثير من التفكير في إعادة الاستخدام خارج المشروع سيؤدي حتمًا إلى زيادة العدد. يزيد التعقيد من وقت التطوير. قد يقول البعض أن هذا سيقلل من تكلفة المشروع القادم. ما هو المشروع القادم؟ ما هي الاحتياجات؟ ما هي العوامل المؤثرة في مختلف الجوانب؟ ومن سيعرف كل هذا في هذا الوقت. إذا كنت تريد حقًا إعادة الاستخدام، فيجب عليك استخراج الأجزاء القابلة لإعادة الاستخدام بعد اكتمال المشروع وتعديلها وتحسينها واستخدامها كأصول قابلة لإعادة الاستخدام للمؤسسة، بدلاً من التفكير بالتمني في المشروع الحالي. ضع في اعتبارك إمكانية إعادة الاستخدام خارج المشروع، وهذا خطأ شائع يرتكبه العديد من المبرمجين الجدد في مجال العمل البرمجي، وفي كثير من الأحيان، كلما فكروا في الأمر، كلما فشل البرنامج الذي يقومون بإنشائه في تحقيق تأثير التصميم وفشل في إكمال الوظائف الأساسية. العديد من العمليات المنطقية البرمجية، ووظائف البرنامج ليست مثالية، وما إلى ذلك.
2. التحقق بشكل متكرر من هيكل المشروع
عادة ما تكون بنية المشروع شيئًا يتم تحديده قبل بدء تنفيذ المشروع وهو تصميم شامل. ومع ذلك، في هذا الوقت، لا يزال فهم متطلبات المشروع وتقدير التعقيد في مرحلة أولية. إذا لم يكن من الممكن تحسين البنية مع فهم المشروع أثناء عملية تطوير المشروع، فسيقوم أعضاء المشروع حتمًا بتطوير المشروع وفقًا للهندسة المعمارية الخاطئة. ولذلك، يجب فحص بنية المشروع بشكل متكرر ويجب إجراء عمليات إعادة الهيكلة اللازمة.
3. إعادة البناء
يقول بعض الناس أنه بعد الكتابة كثيرًا، فإن المراجعة ليست مضيعة للوقت. ربما لم يكن يعتقد أن فترة ما بعد الظهيرة من إعادة البناء يمكن أن تسرع عملية التطوير في الأشهر القليلة المقبلة، فالوقت الذي تم توفيره لا يمكن تصوره. علاوة على ذلك، من خلال إعادة الهيكلة، يمكنك عادةً التفكير في طرق أكثر بساطة لاستبدال التنفيذ الحالي. يمكن لهذه التجربة أيضًا تبسيط تطوير الوحدات الأخرى.
4. تجنب الإفراط في التكامل واترك كل وحدة تقوم بعملها الخاص فقط.
أحد الأمثلة الشائعة لتطوير الوصول المفتوح هو أنه عادةً ما يكون هناك العديد من الموافقات في أنظمة الأعمال، وسيفكر الكثير من الأشخاص على الفور في تحويل الموافقات إلى وحدة نمطية عالمية. لا توجد مشكلة في هذا، ولكن المشكلة المعتادة هي أن الكثير من الأشخاص يضعون معالجة الأعمال بعد الموافقة في منطق الأعمال الخاص بوحدة الموافقة، في الواقع، هذه هي وحدات الأعمال لكل وحدة أعمال، ويجب أن تكون الموافقة فقط سيتم إكماله بمجرد اكتمال الموافقة، ومع ذلك، بالنسبة لما يجب فعله بعد اكتمال الموافقة، دع الوحدة التي تقوم بهذه العملية تتعامل معها بنفسها.
5. تجنب المبالغة في المرونة
التصميم والرمز ليسا دائمًا مرنين قدر الإمكان. من الأمثلة الشائعة أنه عند استخدام الأدوية العامة، يمكن أن تعمل الفئات أو الأساليب على كائنات مختلفة. ومع ذلك، في البنية ثلاثية الطبقات شائعة الاستخدام في JAVA، إذا كانت سلسلة من الفئات مخصصة في الأصل للعمل على كيان معين، فلا داعي لذلك. لتحديده كنوع عام، ثم تحديده لاستخدام فئة كيان محددة عند استخدامه. هذا يبدو وكأنه لا لزوم له.
6. تقليل التثليج على ميزات الكعكة
لا يعد تحديث الصفحة أو تأثيرات العرض الأكثر برودة وما إلى ذلك بمثابة تتويج لنظام الأعمال. إذا كانت واجهة الأعمال معقدة للغاية بسبب ذلك، فستؤدي إلى سلسلة من المشكلات في معالجة الأعمال. في الحالات القصوى، لا يمكن معالجة الأعمال مهما كانت الواجهة جميلة، فهي عديمة الفائدة عند المتابعة. عندما يتعلق الأمر بنصيحة واحدة، فكر في النصائح الأخرى فقط إذا كنت تريد التأكد من أن عملية الأعمال تتم بشكل صحيح. الشرط الأساسي لذلك هو التواصل الضروري مع المستخدمين. بمعنى آخر، تركز المشاريع التي تنفذها JAVA على معالجة الأعمال فقط عندما يتم تحقيق معالجة الأعمال بشكل جيد، يمكن أخذ جمال الواجهة والحس البصري للمستخدم في الاعتبار.
7. انقسم بشكل مناسب
وهذا مشابه لـ 4. حاول تقليل تعقيد كل وحدة قدر الإمكان وتحويل العمل العقلي إلى عمل بدني. من الأمثلة الشائعة أن النموذج عادةً ما يكون له وظائف الإضافة والتعديل والحذف والعرض. ومع ذلك، عادةً ما يتم تنفيذ العمليات الثلاث الأولى فقط بواسطة أشخاص في نقطة وظيفية معينة، وفي حالة معينة، وبأذونات محددة (ربما فقط في الواجهة الوحيدة في النظام). ومع ذلك، سيتم توزيع عمليات العرض في كل ركن من أركان المشروع إذا تم وضع هذه العمليات الأربع في نفس الواجهة، على الرغم من إمكانية تقليل عدد الواجهات، إلا أن ما سيزيد هو تعقيد هذه الواجهة ويجب أن تكون هناك حالات وشروط مختلفة تمت معالجتها. قم بإجراء الأحكام اللازمة لإجراء إعدادات القراءة فقط لعناصر الواجهة. ستكون الزيادة في التعقيد هائلة، وإذا قمت بتقسيم العرض، فسيكون عبء العمل خطيًا. حتى إذا كان عليك إنشاء 10 واجهات عرض، فسيكون التعقيد كذلك أعلى من السابق، من الأسهل بكثير التعامل مع تحويلها إلى 10*10، ويمكن أيضًا تقسيمها إلى مكونات.
8. الحفاظ على التواصل الجيد مع العملاء
كثير من الناس لا يهتمون بالحفاظ على التواصل مع العملاء، ويعتقد العديد من المهندسين المعماريين أن التواصل والتواصل مع العملاء مطلوب فقط خلال مرحلة الطلب في المشروع، وهذه عادة سيئة للغاية، لأن متطلبات العملاء ستتغير بمرور الوقت في البيئة فقط من خلال الحفاظ على التواصل الجيد مع العملاء على أساس منتظم يمكننا فهم التغييرات في احتياجات العملاء في أقرب وقت ممكن، وبالتالي تعديل خطة هيكل مشروعنا لتلبية احتياجات العملاء في أقصر وقت ممكن.
9. العلاقة بين بنية المشروع وبنية قاعدة البيانات
يعتقد الكثير من الناس أنه ليست هناك حاجة إلى قاعدة بيانات أثناء تطوير المشروع، طالما يتم تنفيذها في الذاكرة. أنا شخصياً أعتقد أن هذه عادة تنموية سيئة للغاية. على الرغم من أن قاعدة البيانات يتم تحديدها وفقًا للاحتياجات المحددة للمشروع. ومع ذلك، إذا لم يأخذ المشروع بنية قاعدة البيانات في الاعتبار على الإطلاق أثناء عملية الهندسة المعمارية، فمن المحتمل أن يكون من الصعب تسجيل الأشياء التي تم تنفيذها في المشروع في قاعدة البيانات أو أن تصميم قاعدة البيانات سيكون مزعجًا للغاية، مما سيزيد فعليًا من صعوبة تطوير المشروع. علاوة على ذلك، فإن عدم أخذ قاعدة البيانات في الاعتبار أثناء عملية تطوير المشروع قد يسبب مشاكل مثل الفشل في تنفيذ بعض منطق الأعمال، وفقدان البيانات، وما إلى ذلك بعد ربط المشروع بقاعدة البيانات.
وبطبيعة الحال، فإن الكثير من الناس لديهم آراء معمارية مختلفة بناءً على أنماطهم المعمارية المختلفة، ورأيي قد لا يكون صحيحاً. آمل أن يتمكن الجميع من تعلم شيء ما من أعمالي، وآمل أيضًا أن يتمكن الجميع من مشاركة آرائهم حول الهندسة المعمارية.