مقالة (أجنبية) Why I Hate Best Practices

العادات والممارسات الصحيحة (أياً كانت 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 ايضاً وغيرها من الاشياء الاساسية التي تبين ان هذا المبرمج جيد أم لأ وأن الكود جيد أم لا.