مقدمة
أول شيء لازم تعرف إنه ليس هناك إجماع على تعريف الـsolution architect و ما هي الوظائف التي من المفروض أنه يقوم بها، والتي غالبا يتم تحديدها حسب المكان الذي يعمل فيه.
كل كلامي الذي سيأتي على افتراض إن
software architecture = solutions architecture
2- هناك مدرستين في المعمارية، مدرسة الأبراج العاجية، و هؤلاء ناس يضعوا حلول high level وأنت تنفذها بمعرفتك، و هناك مدرسة المعماريين
"hands-on experience " الذين عملوا بصعوبة شديدة ويعرفوا على الأقل تنفيذ الحلول التي بيقترحوها.
3- لكي نحدد الحاجات التي نحتاجها، محتاجين نعرف تعريف الـarchitecture أصلا.
هناك مقولة لـSimon Brown سمعتها منه في بودكاست:
software architecture is all about structure and vision
وبناء على التعريف هذا أنت محتاج نوعين من المعرفة:
أ- بنية النظام application structure = كيف برنامجك مُقسم
ب- رؤية النظام application vision = كيف برنامجك سيستجيب للتغيرات المستقبلية.
بنية النظام application structure
- لكي تعرف تبني نظام كبير لازم تستطيع أن تبني المكونات الصغيرة من البرنامج،
وأقصد هنا إن هناك معارف معينة سابقة تحتاج تعرفها مثل:
كيف تعرف تقفل برنامج من الألف للياء، كيف تعرف توازن بين الحلول الممتازة و الحلول السيئة، إنك تكون عارف مثلا design patterns، إلخ.
- غالبا أنت لست أول واحد يعمل معمارية لنظام نفس الذي أنت تعمل عليه،
و غالبا هناك شخص قبلك عمل حاجة مشابهة، و غالبا كتب أو اتكلم كيف عملها ايضاً.
فمثلا: تريد تعمل enterprise application ؟ عم المعماريين Martin Fowler عمل كتاب يتكلم عن الموضوع هذا بالتفصيل.
تريد برنامجك يتكلم مع برنامج تاني؟ هناك حد اتكلم عن الintegration patterns.
تريد تعمل على برنامج فيه معالجة بيانات كتير؟ هناك حد اتكلم عن الdata intensive applications.
وهكذا.
المقصود هنا: لا تقوم بإختراع العجلة من جديد وأنظر الى الناس الذين قبلك كيف استطاعوا حل الشبيهة .
- الدنيا لاتقف على حالها، وكل يوم تظهر تقنيات جديدة و أساليب جديدة لحل نفس المشاكل القديمة.
فمثلا في الـ web applications كان سابقاً معماريته تتقسم ل3 طبقات: Presentation Layer - Business Logic Layer
Data Access Layer، و لاحقاً ظهر تعديل على المعمارية هذه جعلتها أقل اعتمادية أسموها Onion Architecture وظهر ايضاً تعديل ثاني أضاف طبقة اسمها service layer، وبعدين المعمارية هذه تطورت مرة أخرى وبقى عندنا microservices وظهرت معمارية جديدة لمعالجة الـ scalability, وهكذا.
المقصود هنا: إنك لازم تكون عارف ماذا يحصل حولك لكي تختار أحسن حل للمشكلة التي تواجهك.
الرؤية Application Vision
- هناك تعريف آخر للمعمارية
القرارات المكلفة التي يصعب تغييرها.
Architecture is about significant decisions that are hard to change
وبناء على التعريف هذا، فأي قرار سيكلف وقت ومجهود كبير لتغييره (يقاس بالأسابيع و الأشهر)، فهذا يقع تحت مسئولية المعماري.
و بناء عليه مهمتك أنت كمعماري إنك تقلل من تكلفة التغييرات المستقبلية هذه بإنك تجعل الحاجات اللي ممكن تتغير سهلة التغيير.
How to make significant decisions insignificant
يخضع للنقطة هذه أيضاً حاجة أخرى يهتم بها المعماري وغالبا المبرمجين يرتعبوا منها ، وهي الـ non-functional requirements نفس الsecurity الscalability إلخ...
من أين أبدأ؟- على افتراض إنك مبرمج تنين مجنح و تريد تتنقل للمعمارية، فهناك كتابين أنا أنصح بهم كمدخل للموضوع هذا:
Software Architecture for Developer - Simon Brown
والكتاب التاني مجاني من مايكروسوفت (هو قديم قليلاً وفيه حاجات ليس لها سياق الآن، لكن سيقوم بربط مواضيع المعمارية لك بشكل جيد)
Microsoft Application Architecture Guide, 2nd Edition
منقول من صفحة المهندس سامح دعبس هنا بعد التعديل قليلاً في اللغة المستخدمة .
المشاركات
ليست هناك تعليقات:
إرسال تعليق