السلام عليكم ورحمة الله وبركاته
كتبت ثلاثة تدوينات كملخص لكتاب Pragmatic Programmer ، وهذا الكتاب يعتبر من الكتب التي يجب على المبرمجين قراءتها
أيضاً وجدت أن هذا الكتاب يجاوب فعلاً على السؤال الاكثر طرحاً وهو "كيف أصبح مبرمج محترف؟"
وأحببت الملخص هنا لتوسيع إنتشاره
--------------------------------
pragmatic programmer
هوأسلوب و نمط وليس مجموعة من النصائح فقط ، إنها ليست نصائح تتعارض مع بعضها
ينصح بأنه يجب أن تكون المبرمج الذي لايكاد يسمع بأي تقنية جديدة إلا وقام بتجربتها و المبرمج السئول الذي يستمر في سؤال الاخرين كيف عملت هذا الشيءو هذا الشيء؟ ماهي المشاكل التي واجهتكم؟ هل واجهتكم مشاكل مع تلك الواجهة البرمجية؟ وهكذا
إذا واجهتك مشكلة فكن صريح مع نفسك ، إذا كنت أنت سبب المشكلة فلا تلقي التهمة على زملائك أو نظام التشغيل أو اللغة البرمجية و إنما كن صريحاً.
لو حدث أن الكود الذي قمت بكتابته لمدة شهر ضاع والسبب هي أن المشكلة أن الهاردسك ضاع أو تعطل ماذا ستقول هل ستقول على حد تعبير المؤلف “أن السورس كود أكلته القطة” أنها مشكلتك فعلاً لأنك لم تأخذ نسخة
لا تذهب إلى مديرك لتخبره أن الشيء الذي يريده لا يمكن تنفيذه و لكن أجلس قبل أن تذهب له و أسال نفسك هل هناك شيء أستطيع أن أفعله ، هل هناك شيء أستطيع إقتراحه كن إيجابياً أجلب معك الحل
وأيضاً أصنع حوار في عقلك هل ستقول للمدير إن هذا الشيء لا يمكن عمله ، وماذا إذا قال لك هل جربت هذه الطريقة أو هل تحدثت مع فلان. قم بتجربة الحلول قبل محادثة مديرك
عندما تصل إلى نقطة لايمكنك العمل بعدها أو رأيت أن هذا الشيء من الافضل أعادة بناءه فأنه من الافضل لك أن تراجع موضوع
Refactoring
يرى أن إطلاقنا لكلمة بناء البرامج software construction هو تشبيه خاطىء وهو خطأ و الافضل أن نشببها بالزراعة لأن البرامج تحتاج إلى مراجعة و صيانة دورية بالضبط كالزراعة
متى يجب أن تفكر في refactoring
إذا كان هناك أحد الاسباب
-التكرار: إذا وجدت أنك قمت بإنتهاك قانون DRY وهو أنك قمت بتكرار بعض الاجزاء
- nonorthogonal: إذا وجدت أن تصميمك يمكن تصميمه بطريقة تكون أكثر من ناحية orthogonality
- إنتهاء: إذا كانت البرنامج لم يعد يلبى متطلبات العميل
- الاداء :إذا كنت تحتاج إلى إعادة بناءه لتحسين الاداء
عندما تخبر مديرك بأن هذا الكود يعمل و لامشكلة فيه ولكنك تريد منه مهلة لأنك تريد إعادة كتابة الكود من جديد ، حتماً سيكون رده بأنك تضيع وقتنا الذي نحتاجه وهنا يجب عليك أن توضح له فوائد refactoring وبمكن أن تشرحها له كطبيب تخيل لو أن هناك مريض و فيه مرض يحتاج عملية في الحال
هل ستقوم بإجراء العملية أم تنتظر حتى تملك الوقت و ينتشر المرض و عندها ربما تكون أمتلك الوقت وخسرت المريض
الامراض محاربتها في البداية أسهل و كذلك في الانظمة أحياناً لابد أن تقوم بإعادة البناء لأن هذه الاجزاء من النظام يعتمدعليها أجزاء أخرى و تعديلها لاحقاً سيكلفكم وقت و مال أكثر بكثير مما لو قمت بإعادة بناءه حالياً
إذا كان تغيير شيء في مشروعكم يؤدي إلى أخطاء أخرى فتأكد بأنه يجب عليكم النظر في مفهوم refactoring
نظرية النافذة المكسورة
الكود السيء أو التصميم السيء من الممكن أن يقودك في النهاية إلى software rot
جودة البرنامج يجب أن تكون متطلب يقوم بتقييمة المستخدم ، دائماً كلما أعطيت مستخدميك نسخة مبكرة لتجربتها كلما أستطعت الوصول إلى نتيجة أفضل
أستثمر في نفسك:
- الاستثمار الدائم: يجب عليك الاستثمار في نفسك و التعلم ولو لفترة قصيرة لأن الفترات القصيرة مجتمعة تكون في النهاية وقت عظيم
- التنوع: لا تتوقف عند تقنية معينة لأن التقنية التي تتمكن منها اليوم لافائدة منها غداً.
- إدارة المخاطر: لا تضع كل بيضك التقني في سلة واحدة، تخيل بأنك متخصص فقط في تقنية معينة و فجأة أعلنت الشركة بإن هذه التقنية تم التخلي عنها. ماهي المخاطر التي تواجهك هل أستعديت لمثل هذا الموقف
-أدفع أقل، أكسب أكثر: إن تعلم التقنيات الجديدة يشبه صعوبة الحصول على أسهم رخيصة لشركات ذات قيمة عالية. ببساطة تخيل أنك من أوائل من قامو بتعلم لغة الجافا ؟
-راجع و أعد حساباتك: عالم التقنية عالم متغير و لذا يجب عليك دائماً مراجعة التقنيات التي تستخدمها. أحياناً تكون هناك فرصة أفضل عندما نقوم بإستخدام تقنية أخرى.
و لتحقيق هذه الأمور يقترح المؤلف بعض الاقتراحات:
- تعلم لغة برمجية جديدة كل عام: فائدة هذا العمل أنه سيوسع مداركك
- إقرأ كتاب تقني شهرياً: وهنا يجب عليك أن تقرأ في التقنية التي تعمل بها الان حتى الاتقان ثم بعد ذلك يمكنك الانتقال إلى تقنيات أخرى
-إقرأ كتب غير تقنية أيضاً : أنت تكتب برامج ليستعملها الناس ، فلابد أن لا تغفل الجانب البشري من حياتك :)
- شارك في اللقائات المحلية و قم بأخذ الدورات
- قم بتغيير البيئة مثل نظام التشغيلأ و البيئة البرمجية
-أشترك في المجلات التقنية و الاخبار التقنية
ضع هذه الجملة دائماً نصب عينيك “أفضل إستثمار هو أن تستثمر في نفسك وتعليمها!!!” ، لايهم إن كانت هذه التقنية ستستخدمها في مشروع أم ستضعها في سيرتك الذاتية و لكن المهم أن هو أن تعلم بأنه هذه العملية جداً ستساعد على توسيع مداركك.
قام المؤلف بالتأكيد على الاهتمام بمهارات التواصل للحاجة إليها وأيضاً كيف تتواصل بشكل إحترافي ، ومنها الاستماع الجيد و الاهتمام بمظهر رسائلك والوضوح في التواصل
لا تكرر نفسك
أحرص دائماً على وجود المعلومات مرة واحدة و عدم التكرار
هناك عبارة تقول “الكود الجيد يحتوي الكثير من التعليقات” و يعتقدان بأن “الكود الجيد لا يحتاج تعليقات و أنما يشرح نفسه” و يضيف بأنه عند تعديلك على الكود فأنه لابد من تعديلك للتعليقات أيضاً و هذه معلومات مكررة
لاتكرر نفسك أيضاً في الكود ، أذا كان هناك متغير تخزن فيه قيمة يمكنك أن تقوم بإخراجها حسابياً فأفضل أن تقوم بذلك على سبيل المثال / العمر و تاريخ الميلاد يمكنك حذف العمر و إستخراجه من تاريخ الميلاد
orthogonality
مفهوم يطلق على التوازن في الانظمة ، من الامثلة على هذه الانظمة نظام يمكنك من خلاله تغيير واجهة المستخدم بدون أن تتأثر قاعدة البيانات و العكس صحيح
إن تطبيقك لهذا المفهوم سيحفظ لك وقت وجهد كبير جداً بالاضافة إلى رفع الكفاءة ، ومن الفوائد:
سترفع من إنتاجيتك لأنك ستوفر وقت إختبار النظام و التطوير ، أيضاً ستتمكن من إعادة إستخدام بعض أجزاء المشروع في مشاريع أخرى.
سيقل الخطر الذي سينتج عن التغيير لأن تأثيره سيكون محصور في منطقة معينة ، كما أن إختباره و تطويره سيكون أسهل.
إذا أردت إختبار نظامك وحتى تتأكد بأنه يطبق مفهوم orthogonality يجب عليك أن تسأل نفسك “إذا قمت بتغير وظيفة معينة ما الذي سيتأثر؟” الاجابة المفترض أن تكون بأنه إذا قمنا بتغيير زر معين فمن المفترض أن لا يتأثر تصميم قاعدة البيانات. التأثير يكون على موديول معين فقط
