كيف أصبح مبرمج محترف؟ ملخص كتاب Pragmatic Programmer

[mohannad.me 8]

السلام عليكم ورحمة الله وبركاته

 

كتبت ثلاثة تدوينات كملخص لكتاب Pragmatic Programmer ، وهذا الكتاب يعتبر من الكتب التي يجب على المبرمجين قراءتها

 

أيضاً وجدت أن هذا الكتاب يجاوب فعلاً على السؤال الاكثر طرحاً وهو "كيف أصبح مبرمج محترف؟"

 

وأحببت الملخص هنا لتوسيع إنتشاره

 

--------------------------------

 

pragmatic programmer

هوأسلوب و نمط وليس مجموعة من النصائح فقط ، إنها  ليست نصائح تتعارض مع بعضها

 

 

ينصح بأنه يجب أن تكون المبرمج الذي لايكاد يسمع بأي تقنية جديدة إلا وقام بتجربتها و المبرمج السئول الذي يستمر في سؤال الاخرين  كيف عملت هذا الشيءو هذا الشيء؟ ماهي المشاكل التي واجهتكم؟ هل واجهتكم مشاكل مع تلك الواجهة البرمجية؟ وهكذا

 

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

لو حدث أن الكود الذي قمت بكتابته لمدة شهر ضاع  والسبب هي أن المشكلة أن الهاردسك ضاع أو تعطل ماذا ستقول هل ستقول على حد تعبير المؤلف “أن السورس كود أكلته القطة” أنها مشكلتك فعلاً لأنك لم تأخذ نسخة

 

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

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

 

عندما تصل إلى نقطة لايمكنك العمل بعدها أو رأيت أن هذا الشيء من الافضل أعادة بناءه فأنه من الافضل لك أن تراجع موضوع

 

Refactoring

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

 

متى يجب أن تفكر في refactoring

إذا كان هناك أحد الاسباب

-التكرار: إذا وجدت أنك قمت بإنتهاك قانون DRY وهو أنك قمت بتكرار بعض الاجزاء

- nonorthogonal: إذا وجدت أن تصميمك يمكن تصميمه بطريقة تكون أكثر من ناحية orthogonality

- إنتهاء: إذا كانت البرنامج لم يعد يلبى متطلبات العميل

- الاداء :إذا كنت تحتاج إلى إعادة بناءه لتحسين الاداء

 

 

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

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

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

إذا كان تغيير شيء في مشروعكم يؤدي إلى أخطاء أخرى فتأكد بأنه يجب عليكم النظر في مفهوم refactoring

 

 

نظرية النافذة المكسورة

الكود السيء أو التصميم السيء من الممكن أن يقودك في النهاية إلى software rot

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

 

أستثمر في نفسك:

- الاستثمار الدائم: يجب عليك الاستثمار في نفسك و التعلم ولو لفترة قصيرة لأن الفترات القصيرة مجتمعة تكون في النهاية وقت عظيم

- التنوع: لا تتوقف عند تقنية معينة لأن التقنية التي تتمكن منها اليوم لافائدة منها غداً.

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

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

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

 

و لتحقيق هذه الأمور يقترح المؤلف بعض الاقتراحات:

- تعلم لغة برمجية جديدة كل عام: فائدة هذا العمل أنه سيوسع مداركك

- إقرأ كتاب تقني شهرياً: وهنا يجب عليك أن تقرأ في التقنية التي تعمل بها الان حتى الاتقان ثم بعد ذلك يمكنك الانتقال إلى تقنيات أخرى

-إقرأ كتب غير تقنية أيضاً : أنت تكتب برامج ليستعملها الناس ، فلابد أن لا تغفل الجانب البشري من حياتك :)

- شارك في اللقائات المحلية و قم بأخذ الدورات

- قم بتغيير البيئة مثل نظام التشغيلأ و البيئة البرمجية

-أشترك في المجلات التقنية و الاخبار التقنية

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

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

 

 

لا تكرر نفسك

أحرص دائماً على وجود المعلومات مرة واحدة و عدم التكرار

هناك عبارة تقول “الكود الجيد يحتوي الكثير من التعليقات” و يعتقدان بأن “الكود الجيد لا يحتاج تعليقات و أنما يشرح نفسه” و يضيف بأنه عند تعديلك على الكود فأنه لابد من تعديلك للتعليقات أيضاً و هذه معلومات مكررة

 

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

 

orthogonality

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

إن تطبيقك لهذا المفهوم سيحفظ لك وقت وجهد كبير جداً بالاضافة إلى رفع الكفاءة ، ومن الفوائد:

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

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

إذا أردت إختبار نظامك وحتى تتأكد بأنه يطبق مفهوم orthogonality يجب عليك أن تسأل نفسك “إذا قمت بتغير وظيفة معينة ما الذي سيتأثر؟” الاجابة المفترض أن تكون بأنه إذا قمنا بتغيير زر معين فمن المفترض أن لا يتأثر تصميم قاعدة البيانات. التأثير يكون على موديول معين فقط
 

تم تعديل 4 Oct 2013 بواسطه mohannad.me

[mohannad.me 8]

لا يوجد قرار نهائي

قد تتفاجأ يوماً و قد انتهيت من 85% من المشروع بأن الادارة قد قامت بتغير رأيها و تغيير قاعدة البيانات للمشروع. أو أن العميل قام بتعديل قوانينه و أنظمته أو أي شيء من هذا القبيل. دائماً خذ في اعتبارك مثل هذه الحوادث عند البدء و هنا يمكنك الرجوع إلى  Reversibility

نحن نجتهد لجعل الكود مرن جداً ولكن ماذا عن تركيبة النظام!!! يجب الانتباه لها أيضاً

 

Tracer code  

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

    شيء لتعرضه للإدارة في الاوقات الحرجة
    توقع أفضل لمدة المشروع
    توقع أفضل للإنجاز في المشروع
    من الممكن أن تتضح لك صعوبات المشروع بشكل أكبر

prototype لنتعلم منها

قام المؤلف بذكر أسباب من الافضل عندها عدم عرض الـ prototyping لمشروعك ومنها عندما تظن أن الادارة من الممكن أن تأخذ النسخة الاولية على أن المشروع جاهز للإطلاق وهنا يمكنك إخبارهم بذلك ، وأيضاً عندما تظن أن النسخة الاولية سوف يساء فهمها من قبل الاخرين

ولكن في غالب الحالات يمكنك الاستفادة من فوائد Prototyping الكثيرة و التي ستحفظ وقتك ومالك وجهدك

 

يعرض المؤلف بعضاً من الطرق لوضع الوقت المتوقع لإنجاز مشروع و من الأفضل الرجوع لها في الكتاب.

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

Back to Basics - العودة إلى الاساسيات

يوصي المؤلف بإتقان الاساسيات و عدم الاستمرار على IDE واحدة و إنما دائماً يجب عليك الرجوع للأساسيات و يقول: لن تكون مبرمج محترفاً حتى تكون ذو مهارة عالية في اكتشاف الاخطاء debugging

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

 

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

يمكن تعلم محرر Emacs و تعلم اللغة التي يستخدمها المحرر و جعلها لغة السنة التي ستتعلمها

SCCS

تبرز أهمية SCCS - Source Code Control System عندما نريد الرجوع إلى أكوادنا التي مضى عليها أسابيع و التي كانت تعمل قبل أن ندخل عليها التعديلات

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

يقول: عدم استخدامك SCCS يعتبر عيب!!!

Debugging

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

 

يقترح في بعض الاحيان كتابة برامج من نوع Code Generators لتكتب لك بعض الاكواد و توفر عليك الجهد و الوقت.
 

[mohannad.me 8]

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

الـ Pragmatic programmer يحرص على جودة الكود و تحقيقه لمعايير عالية و عندما يشك في أي معلومة يقوم بإعادة التحقق من صحتها و لكن ما يميزهم أيضاً بأنهم أيضاً لا يثقون في أكوادهم !!

لا تترك أي إحتمال بسبب أنه مستحيل أن يحدث كأن تقول لا يمكن لهذا البرنامج أن يستخدم لمدة 20 سنة فلماذا أقوم بزيادة عدد الخانات ، دائماً ضع توقع لهذه الحالات (مثل مشكلة Y2K )

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

بكلمات أبسط :الاستثنائات وضعت للحالات الإستثنائية  
 

 

Resources Management

وبالنسبة لإدارة المصادر ينصح بنصيحة صغيرة تقول “أنتهي من الذي بدأته”  ، تأكد من التخلص من أي شيء لم تعد تستخدمه.

أيضاً ماذا سيحدث إذا حدث exception معين هل تم التخلص من الكائنات التي لم يعد الحاجة لها أم أن هذا الشيء يحدث فقط في حالة عدم وجود استثاء

bend or break

في قسمين من الكتاب أوصى بكتابة shy code كود خجول و هو مثل الشخص الخجول لا يظهر نفسه للاخرين ولا يتعامل مع الكثير من الناس.

أجعل الأكواد في موديولات modules و قلل التفاعل interaction بينهم

هناك بعض العلامات التي تدل على أن هناك مشكلة في العلاقات بين الموديولات modules  ومنها:

- إذا كانت الاختبار أكبر من برنامج إختباري test program ، يعني إذا كان كود لتجربة عمل modules أكبر من الكود الذي تنشئه بدون modules .

- إذا كان تغيير بسيط في موديول واحد يسبب مشاكل في موديولات أخرى في النظام لاعلاقة لها به

- إذا كان المبرمجين يخافون من التعديل بسبب أن لا يعلموا ماذا سيحصل لو قاموا بذلك.

عندما تكثر dependencies أي الإعتمادات بين الموديولات بشكل غير ضروري فهذا يجعل النظام صعب جداً من ناحية الصيانة

metaprogramming

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

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

كما هو معروف بأن محافظتك على مفهوم MVC يمنحك الكثير من المرونة و لا تنسى أنه يساعدك أيضاً في الحفاظ على مفهوم reversibility

programming by coincidence

- لاتبرمج كالاعمى و لاتبرمج في بيئة أنت لاتفهمها و لا تبرمج شيء أنت لا تفهمه بشكل كامل

- إنطلق من خلال خطة سواء كانت مكتوبة في ورقة أو في عقلك

- أعتمد على أشياء يمكن الاعتماد عليها فقط ، لا تعتمد على توقعات أو تخمينات

- ضع أولويات لعملك ، أعط الاعمال المهمة المزيد من الوقت

- لاتكن عبداً للتاريخ ، لا تجعل الكود القديم يجبرك في طريقة كتابتك للكود الجديد ، تذكر بأن كل شيء يمكن إعادة كتابته (يقول بأنه يعرف مبرمج قام بإعادة كتابة كل السورس كود لأجل التسميات فقط!!)

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

عند أختبار الوحدة يمكنك أختبار الحدود و إختبار قيمة بينهما  

مثلاً عندنا حقل نصي يقبل من 1 إلى 100 ، عند إختباره يمكننا أن نختبر الحدود الحد الاعلى 99،100،101  و الحد الادنى 1،0،-1  و من ثم نقوم بإختبار قيمة بينهما 76 ، 55 ، 32

في wizards أو code generation لا تستخدمها إذا كنت لا تعرف الكود الذي ستقوم هي بإخراجه لك

Before the project

لن تصل إلى الكمال عندما لا تجد شيء لتضيفه ، بل عندما لا تجد شيء لتتخلص منه

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

في الـ UML لا تكن عبداً لرموز معينة ، إستخدم الرسوم التي تستطيع فهمها أنت وعميلك

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

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

أحرص على وجود قاموس للمصطلحات في مشروعكم

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

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

Pragmatic projects

الجودة تأتي من الاشخاص و ليس وجود شخص مسؤول عنها هو الذي سيجلبها ،

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

غالب المبرمجين يكرهون الـ testing و كـ pragmatic programmer يجب أن تكتشف bugs مبكراً حتى لا تخجل لاحقاً عندما يخبرك الآخرون بأنها خطأك

الفشل في تحقيق معايير usability سهولة الاستخدام ، هو bug كبير كالقسمة على صفر

إكتشف bug مره واحده فقط ، وفي المرات الاخرى التي تقوم فيها بعمل test يجب أن يفحصها النظام أوتوماتيكياً

التعليقات الكثيرة جداً في الأكواد سيئة كالقليل منها ، لأنها ستكلفك أيضاً تعديلها ووقت قراءتها.
 

 

 

-----------------------------------------

 

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

 

عذراً على سوء التنسيق ، لأنه نقل على عجل ;)

 

لكن هنا في المدونة يمكن أن يكون تم تنسيقه بشكل أفضل

 

 

شكراً لكم ..

[أحمد أبو عبد البر 441]

كلام رائع 

بجد هو مفيد لكل مبرمج وقد أعجبتني هذه الكلمة

 

 

لن تصل إلى الكمال عندما لا تجد شيء لتضيفه ، بل عندما لا تجد شيء لتتخلص منه

[محمد حمود 23]

من الجمل التي أعجبتني، وأتفق معها:

"لا تذهب إلى مديرك لتخبره أن الشيء الذي يريده لا يمكن تنفيذه و لكن أجلس قبل أن تذهب له و أسال نفسك هل هناك شيء أستطيع أن أفعله ، هل هناك شيء أستطيع إقتراحه كن إيجابياً أجلب معك الحل"

[empror9 4]

معلومات قيمه، اشكرك عليها

[Mathew Hany 0]

رائع جدًا، الكتاب عجبني جدًا و استفدت منه جدًا و عجبتني انا ايضا عبارة "لن تصل إلى الكمال عندما لا تجد شيء لتضيفه ، بل عندما لا تجد شيء لتتخلص منه" :)

[عدي 15]

موضوع جميل