أسئلة المعلم رفاعي الدسوقي في البرمجة: (2) المراهقة في البرمجة

المقالة اللي فاتت اتكلمنا عن الفرق في المهارات الشخصية اللي بيكتسبها المبرمج كل ما خبرته بتزيد. (الرابط في أول تعليق) خلونا بقى نتكلم المرة دي كفنيين :)

قبل ما أبدأ عاوز أقول إن فيه مبرمجين بزعل عليهم جدا. أكتر من مرة تقابلني حالة واحد خبرة أكتر من 8 أو 10 سنين و آجي أسأله مثلا عمرك استخدمت الpolymorphism؟ اللي يقولي لأ! و اللي يقولي ما احتجتهاش!!! طبعا ده مؤشر إنهم وقع منهم أساسيات كتير في البرمجة ومحتاجين يشتغلوا عليها. و المقالة دي مش للمبرمجين دول. المقالة دي للمبرمجين اللي ماشيين في المسار الطبيعي و اللي بيشتغلوا على نفسهم عشان يتطوروا.

في المقالة دي - إن شاء الله - هانتكلم عن حاجات المبرمجين بيقعوا فيها وهما صغيرين و كل ما بيكبروا و بتزداد خبرتهم الحاجات دي بتقل. أنا سميت الحاجات دي "مظاهر المراهقة البرمجية". و بما إني واحد من المبرمجين دول فالحاجات دي أنا وقعت - وبقع فيها - بصفة شخصية، فحبيت ألخصها من باب النصيحة لنفسي و لزملائي المبرمجين، يمكن تختصر الطريق على حد.

1- ثقة المبتدئين
فيه ناس في طبعها حدة في النقاش واعتداد بالرأي مهما كانت خبرتهم، بس بصفة عامة لما باجي أدخل في نقاش تقني مع حد، لما بلاقيه متواضع و بيسمع وبيتفهم وجهة النظر المختلفة بعرف إنه عنده خبرة غالبا. على العكس من ده بلاحظ كتير من الناس اللي خبرتهم قليلة بيكون عندهم ثقة عالية جدا في إطلاقهم للأحكام على آراء و أكود غيرهم وتقييمهم للمبرمجين والتكنولوجيا، وغالبا بيعانوا من مشكلة البعد الواحد: هو شاف حل واحد لمشكلة ما وفاكر إن هو ده الحل الوحيد الصحيح لكل المشاكل اللي في الدنيا!
فربما تسمع بقى منهم كلام من نوعية:
المبرمج ده كبر و خرف
اللي اشتغلوا في البرنامج دول بقالين
التكنولوجيا س أحسن من ص قولا واحدا
..إلخ.
فيه مقولة جميلة عجبتني بتقول: "العلْمُ ثلاثةُ أَشبارٍ ، مَن دَخَلَ في الشبْرِ الأَوَّلِ ؛ تَكَبَّرَ ؛ وَمَنْ دَخَلَ في الشبْرِ الثاني ؛ تَواضَعَ ، ومَن دَخَلَ في الشبْرِ الثالثِ ؛ عَلِمَ أنه ما يَعْلَمُ". فالله يكرمك بلاش تكون أبو شبر :)

و طبعا صاحبنا المبتديء لما بيشوف برنامج مش عاجبه فيه بعض الحاجات بيقع في الظاهرة التانية:
2- إعادة اختراع العجلة
أي حاجة ما تعجبوش بيبقى عاوز يهدها ويبنيها من أول وجديد، بغض النظر عن الحاجة دي اتعملت كده ليه وعن خبرات الناس اللي اشتغلوا فيها. اتكلمت عن النقطة دي في مقالة مستقلة فمفيش داعي لإعادة الكلام عليها هنا تاني، يمكن الاطلاع عليها من الرابط في أول تعليق.

لما بيكبر شوية بقى ويبدأ يتعلم أنماط التصميم Design Patterns بيعاني من ظاهرة غريبة جدا، وهي:
3- متلازمة أنماط التصميم Design Patterns Syndrome
و دي بتحصل كالآتي: كل مشكلة بيشوفها بيقى عاوز يحلها بdesign pattern وبيتعسف عشان يطبقها، حتى لو الحل ممكن يكون أبسط من كده بكتير!
الdesign patterns حاجة عبقرية، و هي من المهارات الأساسية اللي لازم أي مبرمج يكون ملم بيها، بس تطبيقها بالطريقة دي غلط. لو المشكلة واضحة وأنت عارف الpattern اللي بيحلها على طول توكل على الله وطبقه، لكن لو مش واضحة حلها بأي طريقة و بعدين لو اكتشفت بعد كده إن فيه pattern بيحل نفس المشكلة، عدل الكود للpattern ده. والطريقة دي بيسموها refactoring to patterns.
إن شاء الله هانتكلم في سلسلة منفصلة عن الdesign patterns و إمتى نطبقها، بس يكفينا في السياق ده اللي قلته.

4- لو المبرمج مش شغال مع فريق محترفين بيراجعوا على شغله، هاتلاقيه بيعاني من ظاهرة الفهلوة في البرمجة، و دي ليها كذا اسم عند المبرمجين. فمثلا بيسموها البرمجة بطريقة القص و اللصق Copy/Paste Driven Development
و طبعا أشهر مكان بيتعمل منه كوبي بيست دلوقتي هو stackoverflow عشان كده فيه ناس بيسموها Stackoverflow-Driven Development :)
الفكرة إن الحلول السريعة اللي بتكون موجودة على المواقع دي أحيانا كتيرة بتكون مبسطة عشان تحل المشكلة مباشرة، و أحيانا بتكون فيها مشاكل ربما مش هاتاخد بالك منها. و لو فضلت كل ما تقابلك مشكلة تحلها بطريقة النسخ و اللصق هاتلاقي البرنامج بتاعك في النهاية مش متماسك خالص و بعد فترة هاتلاقيه عبارة عن مكرونة اسباجيتي، أو كرة طين كبيرة Big Ball of Mud، و دي اتكلمنا عنها في مقالة سابقة، الرابط بتاعها في أول تعليق. و عشان البرنامج في الحالة دي بيكون مبني كله بحلول مش متماسكة فبيسموا الطريقة دي Hack-Driven Development :)
المشكلة دي بتبقى وحشة قوي لو المبرمج كبر و اتعود على الطريقة دي في البرمجة، عشان لما بيكبر مسؤولياته بتكبر، و ممكن يكون قائد فريق فينقل لهم طرق سيئة في البرمجة و المشكلة تتفاقم في الأجيال اللي بعد كده :(
طبعا stackoverflow موقع جامد تنين، و مفيش حد اعرفه مش بيستفيد منه، بس المطلوب منك بس تفكر في الكود شوية قبل ما تلطعه في البرنامج بتاعك.
كان فيه واحد جميل اشتغلت معاه، وهو م. عصام عبد العال Essam، قال لي حكمة لسه فاكرها من ربما من أكتر من 12 سنة، قال: فيه كوبي بيست بتصرف و فيه كوبي بيست بتسرع :)
بلاش التسرع ده، و تصرف شوية في اللي بتنقشه الله يكرمك :)

5- بعد شوية المبرمج ده عاوز يغير الشركة، و بالتالي عاوز يظبط السي في بتاعه عشان يعرف يقدم في الشركات، فيبتدي يستخدم تقنيات في البرامج عشان يحطها في السي في بتاعه! ودي بيسموها Resume-Driven Development
طبعا المشكلة الأساسية هنا إنه بيستخدم التكنولوجيا لغرض استخدامها فقط، بغض النظر هل هي أحسن حل للمشكلة اللي بيواجهها و لا لأ، و هل هي تقنية ناضجة بما فيه الكفاية و لا لأ. و اللي بيحصل بعد كده إنه بيلبس في الحيطة و ربما ده بيتسبب إن المشروع بتاعه يفشل!

فيه نوع تاني من الظواهر مرتبط بالظاهرة اللي فاتت، بس لاحظت إنه بيحصل أكتر لما المبرمج بيكبر شوية كمان، و ربما لما بياخد مناصب إدارية أو فنية عالية بدون التدرج الوظيفي:
6- البرمجة حسب الموضة Hype-Driven Development و في رواية Design By Fad
فتلاقيه عاوز يطبق الagile و DevOps و يشتغل المبرمجين TDD و يستخدم DDD و microservices وCQRS، وعاوز يعمل CI/CD وعاوز يطلع على الكلاود،….إلخ. و العجيب إنه ممكن يكون عاوز يعمل كل ده و هو ذات نفسه ما جربهاش قبل كده، و ولا هو و لا المبرمجين اللي معاه طبقوا أكثر الحاجات دي! لقد هرمنا يا جماعة، اعقلوا شوية!

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

يا ريت تنشروا المقالة لو حسيتوا إنها ممكن تفيد حد 

أسئلة المعلم رفاعي الدسوقي في البرمجة: (1) خبرة السنين

إلا قل لي ياض يا عصام، هو إيه الفرق بين المبرمج الخبرة 5 سنين و المبرمج الخبرة 7 أو 8 سنين غير الفرق اللي كل الناس عارفاه؟
-- المعلم رفاعي الدسوقي لما عمل كارير شيفت واشتغل مبرمج

دي سلسلة جديدة هاتكلم فيها إن شاء الله عن بعض الفروق اللي المبرمج بيتعرض لها أو بيحتاج ياخد قرار فيها. السلسة التانية بتاعت "حبة Software Engineering بالهجايص" لازالت مستمرة - إن شاء الله - بس السلسلة دي هاكتب فيها من حين لآخر - إن شاء الله حسب التساهيل - .

أول سؤال معانا في المقالة دي اللي سأله المعلم رفاعي الدسوقي عن الفرق اللي بيبان في سنين خبرة المبرمج.
الحقيقة مش ناوي أكتب المبرمج حديث التخرج fresh graduate المفروض يعرف كذا وكذا، و المبرمج الjunior المفروض يعرف كذا وكذا، والمبرمج الأول الsenior المفروض يعرف كذا وكذا. الحاجات دي مهمة جدا الحقيقة بس مش ناوي اتكلم فيها عشان سهل الوصول ليها، إنما ناوي اتكلم عن حاجات تانية ناس كتير مش بتاخد بالها منها.

- بنسبة كبيرة، أي مبرمج عنده 5 سنين خبرة يقدر يعمل أي حاجة فنية يقدر المبرمج اللي عنده 7 أو 8 سنين خبرة يعملها، بس الفرق بينهم الحقيقي بيبان في مهاراتهم في "تخليص الشغل"، يعني إزاي بيخلوا الناس التانية تشتغل؟ إمتى يرخموا؟ و إمتى يزنّوا؟ و إمتى يهزروا؟ و إمتى يسايسوا؟ و إمتى يرازوا؟ إلخ. اللي علمني الحتة دي صديقي العزيز م محمد عاطف  (وهو مهندس اتصالات بالمناسبة مش مبرمج :)
- إيه بقى الفرق بين المبرمج الخبرة 7 سنين و المبرمج الخبرة 10 سنين؟ نفس الكلام، فنيا الفرق قليل قوي، بس المبرمج الخبرة 10 سنين بيبتدي يغير طريقة تفكيره من البرمجة المعتمدة على المنطق و تسلسل الأسباب و النتائج و الحلول المباشرة للمشكلات إلخ، إلى طريقة التفكير الإدارية - حتى لو فضل مبرمج - إزي يدير مديره؟ إزاي يحقق نجاحات في بيئات عمل سيئة؟ إزاي يواجه الهجوم عليه؟ إزاي يقنع ناس مش فنية بأمور فنية؟ إزاي يوصل لحلول وسط؟ إزاي يخطط بطريقة استراتيجية؟ إمتى يتنازل عن رأيه وإمتى يصر عليه؟ إلخ. أكتر واحد استفدت منه في الحتة دي وعلى طول بينصحني فيها هو مديري م أحمد عبد الحميد، ربنا يصبره عليّ :)

- الحقيقة فيه فروق تانية - غير اللي الناس عارفاها - :) أنا بسميها "النضج الفني"، أو بعبارة أخرى: بيبطل يعمل حاجات أنا بعتبرها من المراهقة البرمجية. ودي هاتكون موضوع المقالة اللي جاية إن شاء الله، فابقوا معنا 

هندسة البرمجيات بالهجايص (4): مبدأ لسكوف للاستبدال

[مش عارف مصدر الصورة إيه، بس هي منتشرة على النت، عموما أنا جبتها من هنا]

أصل المقالة دي كانت بوست كتبته على الفيسبوك، فحبيت أعيد نشرها هنا لتعم الفائدة...

أَبَا هِنْـدٍ فَلاَ تَعْجَـلْ عَلَيْنَـا *** وَأَنْظِـرْنَا نُخَبِّـرْكَ اليَقِيْنَــا
بِأَنَّا نُـوْرِدُ الـرَّايَاتِ بِيْضـاً *** وَنُصْـدِرُهُنَّ حُمْراً قَدْ رُوِيْنَـا
وَرِثْنَـا المَجْدَ قَدْ عَلِمَتْ مَعَـدٌّ *** نُطَـاعِنُ دُوْنَهُ حَـتَّى يَبِيْنَـا
-- عمرو بن كلثوم

اتكلمنا المقالة اللي فاتت عن تفكيك التعلق أو الاعتمادية في حالة الوراثة inheritance و قلنا الأفضل ما نروحش لسكة الوراثة - بقدر المستطاع - لكن لو لقينا إن الوراثة فعلا مفيدة عشان نعمل polymorphism على سبيل المثال، فعاوزين نقلل من آثارها الجانبية بقدر المستطاع، و ده موضوعنا في المقالة دي.

بالمناسبة...بما إننا اخترنا إننا نكمل في الوراثة، فالأبيات اللي في مقدمة المقالة بتتكلم عن الفخر، و هي من معلقات العرب اللي خدناها في إعدادي باين - على ما أذكر - :)

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

- أول مبدأ معانا في المقالة دي هو مبدأ البرمجة بالاتفاق Design By Contract
سنة 1986 في واحد برنس اسمه برتراند ماير Bertrand Meyer كان بيتكلم على طريقة في البرمجة سماها "البرمجة بالاتفاق" Design By Contract، المهم يعني كان بيقول عشان أجزاء البرنامج تتكلم مع بعضها لازم يحطوا اتفاق فيما بينهم، الاتفاق ده بيتكون من 3 بنود:
1- الشروط المسبقة preconditions: يعني مثلا عشان تنده method اسمها ConvertDocToPdf فالشروط المسبقة في الحالة دي ممكن تكون إن لازم يتبعت لها ملف doc سليم (يعني بيتبع التنسيق format القياسي standard المعتمد من مايكروسوفت) و الملف يكون موجود بالفعل مش null. تمام؟
2- الشروط اللاحقة postconditions: يعني مثلا في المثال السابق بتاع ConvertDocToPdf لازم نتيجة تنفيذ الmethod دي إن يكون عندي ملف Pdf سليم (يعني بالتنسيق format القياسي standard المعتمد من شركة أدوبي) يرجع من الmethod و يكون موجود بالفعل مش null. حلو؟
3- آخر حاجة بقى هي إن الثوابت invariants اللي في الclass ما ينفعش تتغير لكل الinstances بتاعت الclass اللي احنا شغالين عليها. مثال: لو عندنا class بتسهل لنا عمليات على التواريخ، و ليكن اسمها DateUtils. الحاجات اللي عمرها ما هاتتغير هاتكون مثلا إن الأيام هاتكون أي رقم ما بين 1 و 31، و الشهور هاتكون أي رقم ما بين 1 و 12،..إلخ. مثال تاني، لو عندي list: من الحاجات اللي عمرها ما هاتتغير فيها إن عدد العناصر فيها لازم يكون أكبر أو يساوي صفر...إلخ. الشاهد إن دي حاجة بتتحدد في كل class على حدة حسب هي بتعمل إيه، و مش شرط تكون موجودة في كل الclasses.

طيب هانعمل إيه بالمبدأ ده؟
ولا حاجة، ده بس مقدمة عشان نعرف نفهم المبدأ الرخم اللي جاي :

P

- المبدأ اللي بعد كده هو مبدأ لسكوف للاستبدال Liskov Substitution Principle (لسكوف دي واحدة ست بالمناسبة، واسمها بالكامل باربارا لسكوف Barbara Liskov)
ركز معايا بقى الله يكرمك عشان تفهم…

لو عندك class فيها virtual method و خليت class تانية تورث منها و تعمل override للvirtual method اللي في الbase class دي (يعني هاتعمل polymorphism) انتبه بقى لل3 حاجات اللي جايين دول:
1- الشروط المسبقة preconditions ما ينفعش تزيد في الderived class. خلونا ناخد نفس مثال ConvertDocToPdf اللي ذكرناه في المبدأ السابق، زي ما ضربنا أمثلة على الشروط المسبقة بإن الملف يكون doc سليم و مش null، لو جيت أعمل لها override في derived class ما ينفعش أقول إن حجم الملف ما يزيدش عن 3 ميجا مثلا، كده أنا زودت الشروط المسبقة. و ده هايزعل مدام لسكوف مننا. إنما لو غيرت طريقة التحويل، خليتها أسرع مثلا، أو حتى قبلت إن تنسيق الملف format ما يكونش قياسي standard فكده أنا قللت الشروط المسبقة وما خالفتش المبدأ.
2- الشروط اللاحقة postconditions ما ينفعش تقل في الderived class. خلونا ناخد نفس مثال ConvertDocToPdf اللي ذكرناه في المبدأ السابق، زي ما ضربنا أمثلة على الشروط اللاحقة بإن نتيجة تنفيذ الmethod إن يكون عندي ملف Pdf سليم (يعني بالformat القياسي المعتمد من شركة أدوبي) و مش null، لو حبيت أعمل لها override في derived class ما ينفعش أخلي الmethod تتساهل في الformat بتاع الملف الpdf اللي راجع بحيث يتكتب فيه حاجات مش قياسية مثلا، كده أنا قللت الشروط اللاحقة، و ده هايخلي مدام لسكوف تعيط. إنما لو غيرت في طريقة التنفيذ بحيث إني خليت التحويل أسرع أو قللت حجم الملف اللي راجع فكده أنا زودت الشروط اللاحقة وما خالفتش المبدأ.
3- الثوابت invariants اللي في الbase class - لو موجودة - ما ينفعش تتغير في الderived classes أبدا.خلونا ناخد نفس المثال بتاع DateUtils اللي ذكرناه في المبدأ اللي فات، الثوابت invariants اللي كانت عندنا إن مثلا الأيام لازم تكون رقم بين 1 و 31، لو عملت class بترث من الDateUtils دي لازم أحافظ على نفس الثوابت، ماينفعش بقى آجي ألاقي الأيام رقم بالسالب أو أكتر من 31، لأني بكده هاكون غيرت في الثوابت و أنت عارف الستات بتزعل قوي من الحاجات دي، ومدام لسكوف كده ممكن تنكد علينا.

لو وصلت مدام لسكوف للنقطة دي و جيت تسألها عن فايدة الكلام ده هاتقولك: لو كنت مهتم كنت عرفت لواحدك :

P

تعالوا نتكلم جد... بص يا سيدي، إنت كده تقدر تستخدم الobjects بتاعت الderived classes مكان الobjects بتاعت الbase classes و أنت مغمض عينك عشان هاتكون مطمئن إن سلوك البرنامج program behavior مش هايتغير. و عمرك ما هاتحتاج تعمل casting أو type checking عشان تعرف نوع الobject اللي أنت شغال عليه.
خد بالك إن مجرد إني أغير طريقة التنفيذ في الderived classes هذا لا يعد مخالفة لمبدأ لسكوف، طالما أنا ملتزم بال3 شروط بتوع البرمجة حسب الاتفاق. وفي الحالة دي أنا الحقيقة شايف إن المبدأ ده قريب جدا من مبدأ Open/Closed Principle الشهير، و ده هانتكلم عنه بالتفصيل في حلقة لاحقة - إن شاء الله -

عند النقطة دي بقى فيه هري و هري مضاد كتيير قوي هل دي تعتبر فايدة حقيقية و لا تنظير على الفاضي؟ وهل المبدأ ده أصلا يعتبر من مباديء الObject Oriented Design و لا لأ؟ والهري ده وراه شوية فلسفة على حبة تنظير رياضي زالفل.

المهم، إزاي أنا بستفيد من المبدأ ده - على المستوى الشخصي-؟
1- وأنا بكتب المقالة دي فكرت شوية لقيت إني بقالي كتير قوي بستخدم الوراثة inheritance في أضيق الحدود، و بعتمد بصورة كبيرة على الinterfaces لتحقيق الpolymorphism أو بطبق مبدأ تفضيل التركيب على الوراثة favor composition over inheritance - اللي اتكلمنا عنه في مقالة سابقة - وفي الحالات دي المبدأ ده مالوش لازمة.
2- روح المبدأ ده بتتكلم عن إنك لما تيجي تعمل وراثة تعملها صح، و الحقيقة فكرة إنك تسأل نفسك عن العلاقة بين الclasses هل يمكن اعتبارها is-a؟ بلاقيها أسهل كتير في تحديد القرار الصحيح. خلونا ناخد المثال العبيط اللي دايما بيستخدموه عشان يشرحوا مبدأ لسكوف، وهو مثال المربع و المستطيل: هل ينفع المربع يورث من المستطيل؟ بتطبيق مباديء البرمجة بالاتفاق - اللي اتكلمنا عليها فوق - هاتلاقي نفسك محتاج تراجع ال3 حاجات (الشروط السابقة، و الشروط اللاحقة، و الثوابت) عشان في الآخر تلاقيها ما تنفعش عشان هاتلاقي إنك محتاج في المربع تغير الطول مع العرض دايما، و ده بيخالف الشروط اللاحقة و/أو الثوابت للclass بتاعت المستطيل. سكة طويلة عشان تفكر فيها كده، خاصة لو المشكلة أعقد شوية من المثال العبيط اللي أنا ذكرته، صح؟ لكن لو سألت نفسك ببساطة: هل المربع يعتبر (=is-a) مستطيل؟ ولا هما الاتنين ممكن نعتبرهم (=is-a) شكل Shape، و يبقى هما الاتنين ليهم base class واحدة؟ أظن السؤال كده أسهل والإجابة واضحة.
3- آخر حاجة، الصراحة لو خالفت المبدأ ده مش بزعل ولا بحس بأي تأنيب ضمير عشان أنا غالبا مش بعمل inheritance إلا لما بكون مضطر ليها، و في الحالة دي بضحي بالمبدأ عشان البرنامج يعيش 

:D

معلش طولت عليكم في المقالة دي عشان أصلا موضوعها رخم و كنت عاوز أشرحه بالتفصيل الممل، فلو فيه حاجة مش واضحة يا ريت تكتبوا في التعليقات.

شير في الخير بقى...سلام.

شوية مقالات بقى استفدت منهم

https://hackernoon.com/liskov-substitution-principle-a982551d584a

http://wiki.c2.com/?LiskovSubstitutionPrinciple

هندسة البرمجيات بالهجايص -- (3) تفكيك التعلق/الاعتمادية

دي المقالة الثالثة في السلسلة، و أصلها كان بوست كتبته على الفيسبوك فحبيت أعيد نشره لتعم الفائدة...

إِذا اِكتَحَلَت عَيني بِعَينِكِ لَم تَزَل *** بِخَيرٍ وَجَلَّت غَمرَةٌ عَن فُؤادِيا
فَأَنتِ الَّتي إِن شِئتِ أَشقَيتِ عِيشَتي *** وَأَنتِ الَّتي إِن شِئتِ أَنعَمتِ بالِيا
وَأَنتِ الَّتي ما مِن صَديقٍ وَلا عِداً *** يَرى نِضوَ ما أَبقَيتِ إِلّا رَثى لِيا
-- قيس بن الملوح (مجنون ليلى)
في الأبيات اللي فاتت دي بيصف قيس شدة تعلقه بليلى، و لأن التعلق ده (أو الاعتمادية) هو موضوع المقالة دي، فقلت أبدأها بشعر غزل، زي ما كان العرب بيعلموا في قصائدهم، حتى لو كانت لأغراض تانية غير الغزل:) بالمناسبة، القصيدة جميلة قوي ابقوا بصوا عليها:)

نخش بقى في الموضوع… يعني إيه تعلق أو اعتمادية dependency؟

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

صدق أو لا تصدق: أغلس تعلق أو اعتمادية بيكون في الوراثة inheritance! 

لأن أي تعديل في الbase class غالبا بيأثر على كل الderived classes، وهو ده التعلق أو الاعتمادية اللي بنتكلم عنها! مش بس كده، الclass الوارثة بتكون عارفة كل حاجة تقريبا عن الbase class. مش عارف أجيبهالكم إزاي… بس ده معناه إني ببوظ الencapsulation اللي هي أحد الأعمدة الرئيسية في الObject Oriented Programming!
وده مش كلامي - عشان محدش يقول إني بهذي - ده كلام عصابة الأربعة Gang of Four (GoF) قالوا بالنص في كتابهم عن الDesign Patterns:
“Because inheritance exposes a subclass to details of its parent’s implementation, it’s often said that ‘inheritance breaks encapsulation’”

* طيب نعمل إيه؟ 

- أول مبدأ معانا هو تفضيل التجميع أو التركيب على الوراثة favor composition over inheritance يعني بالبلدي ما تعملش وراثة inheritance واعمل تجميع/تركيب compostion.

يعني إيه تركيب composition؟ بتبسيط مخل: يعني اعمل class منفصلة و خد منها reference في الclass الأولى.
مثال: لو عندك class اسمها أسد الغابة وناوي تخليها ترث inherits من class تانية اسمها الأسد، فكر تاني، يمكن يكون هو هو نفس الأسد بس شغال في الغابة بدوام كامل fulltime و خليها attribute/field/property للأسد، فلما يجيبلك أسد السيرك هاتلاقيها هاتسد معاك من غير ما تحتاج تعمل class جديدة ترث من الأولى. طبعا الclass الجديدة بتاعت الوظيفة دي ممكن تزود فيها بيانات مفصلة عن طبيعة العمل، وأوقات الدوام، و مكان الغابة...إلخ.

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

عندي ملاحظتين على المبدأ ده:
1- الوراثة ميزة قوية جدا في البرمجة، و أنا عن نفسي بستفيد منها كتير جدا، المقصود من المبدأ ده إنك ما تفكرش فيها كأول حل للمشكلة، مش المقصود إنك ما تفكرش فيها خالص.
2- لما بنفضل التركيب composition على الوراثة inheritance احنا كده مش بنلغي الاعتمادية، احنا بنروح لدرجة تانية من الاعتمادية. ودي هانتكلم عنها في المقالات اللاحقة - إن شاء الله-

- هاتقول لي: بس أنا عندي كود مشترك كتير، و محتاج أطبق الوراثة عشان أستفيد من القابلية لإعادة الاستخدام reusability اللي بتتيحها الObject Oriented Programming.أقولك صح كلامك (مؤقتا)، فيه عندنا قاعدة فعلا بتقول: امنع تكرار الكود Don't Repeat Yourself(DRY)
و البرنس أونكل بوب بيقول -بتصرف- إن تكرار الكود ربما يكون مصدر كل الشرور في البرمجيات!
وحيث إننا ما عرفناش نتخلص من الوراثة، فتعالوا نقلل من آثارها الجانبية.

- المبدأ اللي بعد كده بيقول: الوراثة على قدر الحاجة Interface Segregation Principle.(الترجمة متصرفة جدا أنا عارف عشان Segregation معناها الفصل). بس المعنى المقصود هو إنك ما تعملش base class أو Interface فيها كل حاجة و بالتالي كل اللي هايورثها أو هاينفذها هاياخدها بسلاطاتها ببابا غنوجها، وده هايزود الاعتمادية جدا و هايؤدي لكسر المبدأ التالي:

- مبدأ تقليل المفاجآت Principle of least surprise!

لو خالفت المبدأ اللي فات هاتلاقي فيه كود كتير أنت مش محتاجه من الbase class متاح للاستخدام عن طريق الinherited classes، وبالتالي سهل جدا يساء استخدامه من قبل المبرمجين، وهاتلاقي برضو abstract methods أنت مش محتاجها بس مضطر تكتب لها implementation عشان هي abstract فهاترمي exceptions أو تحط أي كود مالوش أي لازمة، وكل ده هايؤدي لمفاجآت غير سارة للمبرمجين اللي هايكون من سوء حظهم إنهم يتعاملوا مع الكود بتاعك، و مفاجآت غير سارة برضو للمستخدمين اللي هايستخدموا البرنامج بتاعك!
المبدأ ده مهم و هانرجع له تاني - إن شاء الله - كتير.

سامع واحد مركز معايا بيقول الاعتراضات التالية:
- أول حاجة: أنا ليه قلت على الكلام على القابلية لإعادة الاستخدام reusability إنها صح (مؤقتا)؟
- تاني حاجة: لو ما عملتش inheritance إزاي هاستفيد من الpolymorphism؟
- تالت حاجة: أونكل بوب (روبرت مارتن) مأكد لي إن الوراثة حلوة مفيش كلام، ده حتى عامل مبدأ في الObject Oriented Design اسمه Open/Closed Principle! إيه الكلام بقى؟

والإجابة هاتكون معانا - إن شاء الله - في الحلقات القادمة، فابقوا معنا 

هندسة البرمجيات بالهجايص -- (2) أحط الحاجة فين؟

أصل المقالة دي كانت بوست كتبته على الفيسبوك، فحبيت أعيد نشره لتعم الفائدة...

وده رابط الحلقة الأولى في السلسلة لمن أراد..

"جيت ألم البنطلون الجاكتة ضربت...جيت ألم الجاكتة البنطلون ضرب!" -- سمير غانم :

)

- الحقيقة احنا بنشوف المرار في البرمجة، تيجي تعدل في حتة في البرنامج ولا تحل bug تلاقي جحيم اتفتح عليك و عمال تعدل في حتة تانية ورا حتة تالتة ورا حتة رابعة. وبيبقى فيه حتت كده في كل برنامج عبارة عن كهف مظلم محدش يجرؤ يقرب له بسبب موضوع تسلسل التعديلات ده. النوع ده من البرامج بيبقى مقاوم للتغيير، بيبقى عامل زي الزجاج كده فيه صلابة rigidity بس فيه هشاشة في نفس الوقت fragility. الوضع ده لما بيكون صفة ملازمة للبرنامج غالبا هاتفكر تهده وتبنيه من أول وجديد، إوعى، وراجع مقالة "إعادة اختراع العجلة في البرمجيات" 

- فيه برامج تانية بتبقى حلوة وظريفة وشغالة لكن لما بنحب نعيد استخدام الكود ده - حتى لو بعمله copy/paste بلاقيه مش بيشتغل. ممكن يكون لأنه مش مصمم إنه يعاد استخدامه - وده مش عيب بالمناسبة - وممكن يكون بسبب اعتماد أجزاء الكود على بعضها dependencies. برضو فكرة الاعتمادية في حد ذاتها مش مشكلة، المشكلة في كثرة عدد الحاجات اللي معتمدة على بعضها وعمق درجة الاعتمادية دي يعني بتعتمد على حاجات كتير اللي هي بدورها بتعتمد على حاجات كتير برضو..وهكذا. النوعية دي من التصميمات البرمجية بتتسم بصفة الجمود immobility.

- فيه نوعية تالتة من البرامج لما تحب تعدل فيها أو تحل مشكلة تلاقي الطريقة الصحيحة لعمل ده صعبة بسبب اعتمادية أجزاء الكود على بعضها، و تلاقيك بتكتب hacks و workarounds أكتر ما بتكتب كود كويس. الكود اللي من النوعية دي بيتصف باللزوجة viscosity يعني بيبقى ملزق كده زي الزيت لما يكون في الطاسة، لما تيجي تنظفه تلاقيه مش راضي يطلع.

البرامج اللي بيجتمع فيها البلاوي اللي فوق دي فيه مصطلح ظريف بيعبر عنها اسمه Big Ball Of Mud يعني كرة الطين الكبيرة!

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

- أول مبدأ معانا هو مبدأ الفصل بين المسئوليات Separation of Concerns [الترجمة متصرفة أنا عارف].

تعالوا نضرب أمثلة توضح المقصود على طول:
= لما بيكون المشروع بتاعك مقسم لطبقات layers ما تخليش مسئوليات الطبقات تدخل في بعضها، يعني مثلا الطبقة بتاعت الواجهة front-end/presentation layer تكون مسئولة بس عن واجهة المستخدم user interface ومافيهاش قرارات ليها علاقة بقواعد النظام business rules و طبعا مش بتوصل لقاعدة البيانات! ده على مستوى بنية النظام application architecture.
= في كل طبقة layer ما تجيش تخلط برضو بين المسئوليات في أجزاء الطبقة دي، يعني مثلا يفضل إنك ما تكتبش html و css و javascript في نفس الملف لأن كل حاجة من دول مسئولة عن حاجة مختلفة. و نفس الكلام لما يكون عندك مثلا class مسئولة عن إدارة حسابات المستخدمين ما تحطش فيها كود له علاقة بإدارة الكتب (لو أنت عامل برنامج لمكتبة مثلا).
= نفس الكلام في قاعدة البيانات، ما تجيش تحط حقول columns مالهاش ارتباط الprimary key (و دي اسمها database normalization بس مش هانتكلم عنها عشان دي قصة لوحدها)
...وهكذا في كل مناحي البرنامج.

- المبدأ ده يقودنا لمبدأ تاني هو التخصص الدقيق Single Responsibility Principle [الترجمة متصرفة جدا المرة دي أنا عارف].

المبدأ بيقولك أي جزء برمجي لازم يكون بيعمل حاجة واحدة بس، و بيعملها كويس. و تقدر تقيس الموضوع ده بإن ما يكونش عندك أكتر من سبب لتغييرالجزء البرمجي ده. تعالوا نخش في الأمثلة:
= عندي method اسمها ParseAndCalculate لاحظ وجود الAnd في الاسم ده دليل على إن الmethod بتعمل حاجتين. طبعا الاسم مش دليل كافي، ممكن يكون مسميها بلحة وبتعمل 5 حاجات. الشاهد إن لما أحب أغير في الParse هاعدل في الmethod ولما أحب أغير في الcalculate هاغير فيها برضو، و ده يتنافى مع مبدأ التخصص الدقيق.
= شفت كود الmethod فيت تتجاوز ال3000 سطر بدون أي مبالغة، بس الحقيقة المبرمج حاطط comments كتير وعامل regions جوه الmethod مبين فيها كل حتة بتعمل إيه. ده مؤشر ظريف إن ممكن الregions دي تتقسم لmethods منفصلة.
= الكلام ده لا يسري على الmethods بس، طبقه بقى على كل حاجة من أول بنية النظام و طبقاته، مرورا بالclasses و الmethods و وصولا لقاعدة البيانات.

- فيه مبدأ تالت مرتبط بالمباديء اللي فاتت دي، ألا و هو مبدأ الاقتران Coupling و التماسك Cohesion [بتتنطق كده كوهيجن، بتعطيش الجيم]. يعني إيه الكلام ده؟

= الاقتران coupling معناه قد إيه الحاجات اللي أصلا مالهاش علاقة ببعض في اعتمادية بينها، و دي قصة الdependencies اللي عمالين نهري فيها فوق، فده بيتكلم عن علاقة الحاجات ببعضها من بره.
= أما التماسك cohesion فبيتكلم عن علاقة الحاجات ببعضها من جوة، يعني لما تشوف حاجة في الclass كده و تقول: "إيه اللي جاب القلعة جنب البحر؟" تعرف إن الclass مش متماسكة و بتعمل حاجات مش بتاعتها.
المبدأ ده تقدر تعتبره معيار لقياس هل تغيير الكود بتاعي سهل و لا صعب، إزاي؟
= الحاجات اللي مقترنة ببعضها tightly coupled بتبقى صعبة التعديل، يعني فيه اعتمادية بينها بحيث لو عدلت في جزء محتاج أعدل في جزء تاني. و أنا مش عاوز كده أنا عاوز الارتباط بينها يكون في حده الأدنى loosely coupled.
= الحاجات اللي مش بتطبق مبدأ التخصص الدقيق بتكون غير متماسكة loosely cohesive ودي برضو بتبقى صعبة في التعديل، يعني فيه أكتر من سبب لتعديل الجزء البرمجي ده. و أنا مش عاوز كده برضو، أنا عاوز التماسك يكون عالي جدا tightly cohesive.
= طيب تعالوا نعيد صياغة المبدأ تاني: حاول توصل لأعلى تماسك و أقل ارتبط strive for tight cohesion and loose coupling عشان الكود بتاعك مايبقاش big ball of mud.

سامعك و شايفك و هاجيبك يا اللي بتقول: أنت بتضحك علينا، ماهو لازم يكون فيه اعتمادية بين أجزاء البرنامج على بعضها، أمال هايشتغل إزاي؟!! و برضو عمري ما هاقدر أحقق التماسك و قلة الارتباط مع بعض و دايما هايكون فيه تعارض!!!

و ده هايكون موضوع الحلقات القادمة إن شاء الله...فابقوا معنا :)

شير في الخير بقى 

إعادة اختراع العجلة في البرمجيات

أصل المقالة دي كانت بوست  كتبته على الفيسبوك، بس حبيت أعيد نشره لتعم الفائدة...

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

- في سبعينيات القرن الماضي، واحد من رواد صناعة البرمجيات اسمه فريدريك بروكس، عمل كتاب اسمه The Mythical Man-Month بيتكلم فيه عن مشكل صناعة البرمجيات وقتها، و الكتاب ده يعتبر من كلاسيكيات الصناعة بتاعتنا وظريف جدا، أنصحكم تقرأوه. المهم الراجل حذر في الكتاب ده من حاجة غريبة جدا، ألا وهي تأثير النظام الثاني The second system effect، و خلاصة الكلام اللي قاله إنه لما يكون عندك برنامج فيه مشاكل و تيجي تعمله من أول وجديد غالبا البرنامج ده هايكون فاشل لأنك هاتحاول تعالج فيه كل المشاكل اللي قابلتك في المشروع الأول و المشاكل اللي متوقع تقابلك مستقبلا و بالتالي هاتهندسه بزيادة over-engineered!
الحقيقة لما قرأت الكلام ده أول مرة استوعبته كويس المرة دي عشان كنت مريت بتجارب عملية على مشروعات فشلت بتأثير النظام الثاني!

- طيب ليه المبرمجين بيحبوا يهدوا اللي معمول و يبنوه من أول وجديد على نظافة -زعموا-؟

فيه مثل عندنا بيقولك: مفيش صنايعي بيعجبه شغل صنايعي تاني. والكلام ده في صناعة البرمجيات له وجه للأسباب التالية:
1- غالبا كل برنامج اتعمل كان له سياق ومشاكل بيحاول يحلها و مبرمجين بخبرات معينة بيشتعلوا عليه ومش شرط أنت تكون ملم بالظروف و السياق ده، و لا عندك نفس الخبرة اللي كانت عند الناس اللي عملوا البرنامج، ربما خبرتك أكتر فتستحقر شغلهم، وربما أقل فتحس إنه خيال علمي.
2- البرنامج مش بيتوقف بعد أول طلعة، و بيفضل يتضاف فيه خصائص و حلول لمشكلات bug fixes و تعديلات بشكل مستمر. مع ضغط الوقت و قلة الخبرة و تغير مطاليب العملاء بتلاقي الدنيا بتعك منهم.
3- فيه خاصية من طبائع البرمجيات، أشار ليها جول سبولسكي - أحد مؤسسي موقع stackoverflow الشهير، و هي أن كتابة الكود أسهل من قراءته، والطبيعة دي بتسري حتى لو أنت بذات نفسك اللي كاتب الكود اللي مش عارف تقرأه ده!
4- فيه مشكلة بقى عند المبرمجين نفسهم لما بييجوا يقيموا برنامج مش هما اللي عاملينه، و هي معايير التقييم: فمثلا ما بيحطوش وزن للسياق اللي اتعمل فيه البرنامج - اللي اتكلمنا عنه في النقطة 1، أو بيقيموه حسب التقنيات الحديثة اللي هما بيعرفوها، و اللي ربما ما كانتش موجودة لما البرنامج اتعمل أول مرة، أو حسب أساليب التصميم الحديثة اللي ما كانتش موجودة برضو لما البرنامج اتعمل أول مرة.
4- في بقى مشكلة تانية عند بعض المبرمجين المطلعين، إنهم بيحبوا يعملوا الحاجة من أول وجديد عشان يجربوا كل حاجة جديدة عشان يكتبوها في سيرهم الذاتية، و على الرغم إن تجربة كل شيء جديد أحد أساليب التعلم اللي فادتني كتير على المستوى الشخصي، بس كانت مكلفة، لأني فشلت كتير بسبب الاعتماد على تقنيات غير ناضجة، أو تجربة حل برمجي للمشكلة الغلط! وكل ما بتزداد خبرتي الموضوع ده كان بيقل معايا.

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

- فيه برنامج كنت شغال على النسخة التانية منه، زمايلي كانوا بيقولولي إنهم اكتشفوا في النسخة الأولى منه إن الفيجوال بيسك ما بيقبلش أكتر من 128 بارامتر في الفانكشن (لاحظ اكتشفوا، يعني فضلوا يجربوا لغاية لما فشلوا). و مشروع تاني مش كبير كان بياخد 160 جيجا رامات، و لما حسنوه وصل ل70 جيجا!!
طبعا النوعية دي من البرامج لازم تولع فيها و تنسى كل الهري اللي أنا قلته فوق ده، بس لو عرفت تظبطه بالتدريج يبقى أحسن :)

يللا شير في الخير بقى 

هندسة البرمجيات بالهجايص: (1) أسمي الحاجة إيه؟

أصل المقالة دي كانت بوست كتبته على الفيسبوك، فحبيت أعيد نشره لتعم الفائدة...

* مقدمة:

بقالي كتير عاوز أكتب سلسلة مقالات أو أعمل سيشنز عن بعض المفاهيم المهمة في تصميم البرمجيات، و بالذات المفاهيم المتعلقة بال Object Oriented Design و ما يتبعها من Design Patterns، بس كالعادة الوقت ما بيبقاش متاح، فقلت أعمل سلسلة على الفيسبوك أتكلم فيها عن المفاهيم دي بالهجايص كده، و أهو أحسن من مفيش.

* مين هايستفيد من الهري ده؟

عشان يكون الكلام مفيد لازم اللي هايقراه يكون عنده خلفية جيدة عن الObject Oriented Programming و إلا هايحس في معظم الأحيان إننا بنتكلم هيروغليفي.

* أول قاعدة:

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

من أهم الحاجات اللي محتاجين ناخد بالنا منها لما نعوز نكتب كود نظيف:
1- نسمي الحاجة إيه؟
2- نحط الحاجة دي فين؟

[الحقيقية اللي اتعلمت منه القاعدة دي واحد ابن حلال اسمه أمير جعفر عامل سلسلة يتيمة على اليوتيوب عن الTest Driven Development (ابقوا بصوا عليها)]

نرجع لشرح المفهوم...

*** نسمي الحاجة إيه؟

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

تعالوا نهري شوية مع الأسماء عشان مهمة جدا، و للأسف الواحد بيشوف مآسي في الكود.

* إزاي بقى تختار اسم مناسب؟

- الاسم لازم يعبرعن الحاجة اللي بيمثلها، يعني مثلا لو بتختار اسم لclass فالمفروض تفهم من اسمها الكلاس دي بتهبب إيه بالضبط، لو اسم method فالمفروض الاسم يعرفك هي بتعمل إيه بالضبط من غير ما تبص على الكود اللي جواها...إلخ. و خدها قاعدة كده، لو الاسم اللي اخترته محتاج تكتب جنبه comment عشان يشرح معناه إيه، فده مؤشر إن الاسم اللي أنت مختاره وحش.
- بلاش الأسماء المضللة عشان بتتعبنا و الله، يعني مثلا ماتجيش تسمي variable: productList و هو مش list مش جايين نحل فوازير احنا...لقد هرمنا :(
- الفرق بين المفاهيم لازم ينعكس في الأسماء، يعني مثلا لو بنعمل method بتنقل ملف من source إلى destination، ما تسميش الvariables:
a1 & a2
لأ سميهم source & destination
- تجنب التلوث البصري في اختيار الأسماء، يعني مثلا لو عندك class اسمها company، ما تجيش بقى في كل الfields اللي فيها و تلزق في اسمها company، فماتقولش companyName، companyId، companyAddress..إلخ. قل لي إيه الإضافة اللي ضفتها لما عملت كده؟ و الأنيل بقى لما تلاقي واحد كاتب لك nameString كأن الاسم ممكن يكون float مثلا.....لقد هرمنا بجد :(
- الاسم اللي هاتختاره لازم تكون هاتعرف تقراه، و بالتالي لما تيجي تدور عليه تعرف تلاقيه. بلاش اختصارات في الأسماء، و استخدام الأسماء الطويلة مش عيب و لا حرام على فكرة.
- استخدام الفرانكو في الفيسبوك وحش قوي، و أوحش في الكود. دونت يوز فرانكو إن يور كود بلييييييزززز.
- بلاش أرقام سحرية في الكود، أرقام مستخدمة في كل الكود كده محدش عارف معناها إيه. في اختراعات ظريفة في لغات البرمجة دلوقتي زي الenums و الconstants، المبرمجين الكويسين بيستخدموها...كن مبرمجا كويسا زيهم.
- ما تستخدمش variables من حرف واحد إلا في الloops، عشان دي من الحالات القليلة اللي المبرمجين تلقوها بالقبول.
- أسماء الclasses و الobjects تكون أسماء مش أفعال، مثال: company، account، FileParse. و أسماء الmethods تكون أفعال و أسئلة مش أسماء، مثال: DoSomething، IsValid، HasChildren..إلخ.
- بلاش استظراف في الكود، ما تجيش مثلا تستخدم قفشات من فيلم بتحبه في أسماء الvariables عشان أنت أكيد عارف إن مش كل الناس بتلقط قفشات الأفلام.
- حاول تكون متسق مع ذاتك و تستخدم نفس الاسم للتعبير عن نفس المفهوم في كل حتة، يعني مثلا لو بتحب اسم get لما تعوز تجيب حاجة، افضل استخدمه في كل حته، مش مرة تستخدم get ومرة retrieve و مرة fetch... كمان مرة، خليك متسق مع ذاتك.
- لو مطبق design pattern معين حاول تستخدم اسمه كجزء من اسم الclass أو الmethod بتاعتك، و نفس الكلام لو فيه algorithm أو أي مصطلح يفهمه بتوع البرمجة برضو استخدم اسمه برضو. تذكر إن اللي بيقروا الكود مبرمجين فارفق بهم و ساعدهم يفهوا الكود عشان يدعولك.
- لو ما لقيتش اسم برمجي مناسب بس كان فيه اسم في البزنس اللي أنت شغال عليه ممكن تستخدمه، توكل على الله و استخدم اسم البزنس.
- و لو ما لقيتش اسم مناسب لا للمبرمجين و لا في البزنس، هاتضطر تطلع مهارات الفتي اللي جواك، بس حاول تقلل من استخدام الأسماء المستهلكة زي Manager، Controller، Data، Info بقدر المستطاع عشان كتر استخدامها عمال على بطال بقى مضلل شوية.
- لو اخترت اسم وبعد كده حسيت إنه مش مناسب غيره عادي خالص، مش عيب و الله، خاصة إن التولز دلوقتي بتسهل لك التعديل في كل الأماكن مرة واحدة. و لو غيرته 10 مرات و لسه مش مناسب افضل غير فيه ولا يهمك.

- حاول تقرأ كتاب clean code، أنا نقشت منه حاجات كتير في البوست ده. و دايما بقول لو المبرمج مش هايقرأ غير كتاب واحد في حياته في البرمجة فليكن الكتاب ده.

-------
طيب بقية المفهوم الأول: أحط الحاجة فين؟
مش هاجيب صورة عادل إمام الشهيرة للإجابة على السؤال ده عشان هي قبيحة، بس هاقول لكم نخليها المرة الجاية إن شاء الله :

)

و لا تنسونا من لايكاتكم و شيراتكم و نصائحكم