نصائح بسيطة في تصميم البرمجيات

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

ثلاثة أهداف للتصميم:
هـناك ثلاثة أهداف للتصميم ينبغي عليك أن تضعها في اعتبارك عند تصميم برنامج ما:
1) حاول حفظ الوقت.
2) حاول حفظ الذاكرة.
3) حاول حفظ الواجهـة.

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

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

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

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

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

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

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

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

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

المبدأ الرابع: “ليس الكود العام هو الكـود الأكثر استخداماً” ، بالرغم من أنك قد لا تقبل هذا المبدأ إلا أن الكـود العام وبسبب معالجته للعديد من الحالات فإن عليه أن يكون ذا حجم كبير وغير فعال أيضاً ، لذلك قد لا تعيد استخدامه في تطبيقات تالية بسبب قضية الفعالية ، وهذه المشكلة تعاني منها الكثير من المكتبات التجارية.

المبدأ الخامس: “اتبع قاعدة 80-20 “ ، في الكثير من البرمجيات فإنه تقريباً 80% من وقت التنفيذ ينفق في 20% من الكـود ، لذلك اجعل تصميمك أكثر جودة على الجزء الذي تعتقد أنه سيتم استعماله بكثرة من الكود ، أما بقية الكـود أي 80% فليست قضية الأداء مهمـة هـنا ، المهم هـنا إعطاء المستخدم النتيجـة الصحيحـة وعدم التسبب في إنهاء البرنامج كلياً .

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

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