مقالة (أجنبية) Why I Hate Best Practices
بعد فترة من دراسة افضل الممارسات ومحاولة تطبيق بعضاً منها، سألت نفسي هذا السؤال، هل يجب علينا تطبيق كل هذه المبادئ الموصى بها، أم أن التعمق فيها له مضار.
لا شك أن افضل الممارسات مهمة لأي مشروع كبير وهي تعني نجاحه أو فشله، وتقبله للتغير والتطوير والتوسع أو عدمها.
لكن تبقى هُناك مشكلتان:
هل كل هذه الممارسات صحيحة، هل هي قوانين، أم أن بعضها يصلح لبعض البرامج وبعضها لا يصلح. مثلاً لا يمكننا تطبيق نفس المبدأ مع برنامج ويب وبرنامج لدائرة مدمجة بلغة سي مثلاً التي ليس فيها OOP، ربما نحتاج لمبادئ مختلفة لكل نوع من الأنظمة.
ماهي تكلفة التعمق في تطبيق تلك الممارسات. مثلاً يمكننا تطبيق 2 من أصل 5 قوانين لمشروع ما وتنجح الفكرة، لكن إن حاولنا تطبيقها الخمسة ربما يتأخر الوقت ويتعقد البرنامج، فمن سوف يدفع ثمن هذه التكلفة الزمنية؟
الترجمة الحرفية للعنوان "لماذا أنا أكره أفضل الممارسات" وقد فهمت منها أن على المبرمج أن لا يلزم نفسه بانتهاج كل ما هو مثالي في عالم وهندسة وفلسفة البرمجة، لأنها قد تكون ضارة أكثر مما تفيد.
لعله يوجد من هو متمكن لترجمتها بشكل جيد.
العادات والممارسات الصحيحة (أياً كانت patterns, principles, practices) لم توضع حتى يتم تطبيقها بشكل أعمى، وانما هي امور وحلول عامة ولكنها قد لا تفى بمشكلتك لذلك من الخطأ فعلاً ان تقوم بتطبيق كل الممارسات بدون وجود مبرر فعلاً.
حتى في العادات البرمجية كما تجد اشياء قد تغير طريقة كودك وقد ترى انها تضيف تعقيداً فهناك مفاهيم تحثك على البساطة مثلاً مفهوم Keep it Simple Stupid (اختصاراً KISS) أو مثلاً You ain’t gonna need it (اختصاراً YAGNI) وغيرها ايضاً.
لذلك أرى معرفة العادات امر مهم وخصوصاً الفكرة الأصلية من الفكرة وكيف تطورت ومعرفة الفائدة الحقيقي حتى بعدها تعرف متى هو الوقت المناسب لكسر هذه العادة مثلاً.
الذي يحصل بعد أن يتعلم المبرمج فكرة معينة هو أنه يذهب بعيداً ويقوم بعمل شيء over-engineering وربما ينتهي الوقت وتنتهي الميزانية ولم ينتهي (بسبب أنه لم ينظر لطبيعة المشروع نفسه والقيود التي فيه)، أو انه يتجاهل كل شيء ويكتب كود ومعمارية سيئة (كل شيء داخل دالة واحدة مثلاً) ويقع فيما بعد في مشكلة الصيانة (ونفس المشكلة لم يضع في الاعتبار ان ال business سوف يستمر ويحتاج ان يتطور مع الوقت)
لذلك لحل هذه الأمور، يجب أن ينظر لل business وطبيعة المشروع أولاً، مثلاً مشروع صغير، ميزانية صغيرة مرصودة، وقت تسليم محدد hard deadline، ولا توجد خطط تطويرية مستقبليةفما الداعي لكتابة n tier architecture وكتابة الكثير من الunit testing فبكل تأكيد سوف ينتهي الوقت ولن تستطيع ان تسلم العمل.
لكن مثلاً مشروع كبير او سوف يكون نواه لbusiness معين وخلفه ميزانية جيدة، فمن الخطأ ان تكتب الكود بدون مراعاه الصيانة المستقبلية لأنك قللت حفظت المال والوقت الان، ولكن الجهد سوف يتضاعف مستقبلاً وبالتالي اضعت المال والوقت ايضاً.
على مستوى الكود فهناك اساسيات في design مهمة ارى انه يجب على جميع المبرمجين ان يتبعوها، مثلاً فصل الاهتمامات وكتابة كل شيء متعلق بفكرة معينة في مكان مختلف عن الاشياء المتعلقة بفكرة اخرى، سواء كنت تعمل ب OOL او Structure Language فالمفهوم نفسه ينطبق عليهم. مثلاً ال code convention ايضاً وغيرها من الاشياء الاساسية التي تبين ان هذا المبرمج جيد أم لأ وأن الكود جيد أم لا.
متفق مع الكاتب فى بعض الجوانب,
ليس لأحد ان يقيم الاكواد بحسب الممارسات المعتادة او التى ينصح بها دون ادراك للظروف و الاحتياجات التى أدت الى كتابة هذه الاكواد.
كثيرا ما اكون متعجلا, أو مضغوطا, فأقوم بكتابة الاكواد بسرعة لكى تعمل بشكل أساسى, متجاهلا الbest practices, على أساس ان اعود اليها بعد وقت لتنقيحها و هو ما لا يحدث أبدا لأنك تنشغل بأشياء جديدة! فتبقى الاكواد على حالها دون تغيير و معظمها, ياللعجب يعمل بكفاءة.
لكن الBest Practices صحيحة فى معظم الاحيان, عليك فقط ان تكتشف هذا بنفسك, الخبرة سوف تكشف لك ذلك.
عندما بدأت ببرمجة السى, كنت قادما من خلفية البيسك, و فى البيسك القديم فان عبارة goto لها أهمية كبيرة, فى اى برنامج بيسك قديم هناك ما لا يقل عن 50 تعليمة goto لا تعرف من أين تأتى و أين تذهب, لكنها تسهل الامور تماما (لم يكن هناك Procedures و عبارة goto توفر مرونة اكثر من gosub!)
عندما بدأت الانتقال الى السى, قرأت مرارا و تكرارا ألا أستخدم عبارة goto, كل كتب السى تمتلىء بالتحذيرات حتى أنك لتعتقد ان حاسوبك سوف ينفجر لو استخدمتها.
قررت أن هذا هراء, كيف يمكن لمبرمج الاستغناء عن عبارة goto؟ كيف يمكن لبرنامج ان يعمل بغيرها؟
قررت أننى لن أتخلى عن عبارة goto, و سوف أستخدمها متى احتاج اليها الكود!
و المفاجأة, و بعد سنوات, لم احتج الى عبارة goto و لا مرة؟!كل شىء يمكن حله بالstructured programming,
رغم ذلك, أنتظر اليوم الذى سوف أستخدم فيه goto مرة أخرى, حالما أجد الكود الذى يحتاج لها! ليس لشىء, الا نوع من الوفاء و العرفان بالجميل و نوع من الحنين للماضى!
التعليقات