وكما قال الكاتب الأسطوري جول فيرن عن حق: "الحد الأدنى المستخدم جيدًا يكفي تمامًا". في عصرنا ، ينطبق مفهوم الحد الأدنى المستخدم جيدًا على الكود. محزن ولكنه حقيقي: في عالم الكود الحديث يوجد الكثير. لكي نكون أكثر دقة ، يوجد الكثير من التعليمات البرمجية غير الضرورية ، من بينها التعليمة البرمجية المفيدة تختنق ببساطة.
بالنظر إلى ما سبق ، فإن الكود غير الضروري هو الشر افتراضيًا. تتدهور مع الوقت. يتطلب الدعم المستمر. أنه يحتوي على الأخطاء التي تحتاج إلى البحث عنها. عند ظهور وظائف جديدة ، يجب تكييف الرمز القديم مع هذه الرموز. لمزيد من التعليمات البرمجية لديك ، والمزيد من الأخطاء التي قد تكون في ذلك. كلما استغرقت عملية التحقق أو التجميع وقتًا أطول ، كلما زاد فهم الموظف الجديد لنظامك.
وفوق كل هذا القفز ، يتم كتابة التعليمات البرمجية بواسطة المبرمجين. وكلما زاد عدد المبرمجين. مع زيادة عدد المبرمجين ، تزداد تكلفة الاتصال بينهم ، مما يساهم في زيادة تكلفة تطوير التعليمات البرمجية والحفاظ عليها.
لكل هذه المشكلات ، يوجد حل واحد: كتابة كود أقل. هذا النهج لديه الكثير من المزايا:
- كود أقل لتطوير = تكاليف تطوير أقل
- كود أقل في التطوير = تكاليف صيانة أقل
- رمز أقل في التنمية = أخطاء أقل
- رمز أقل لتطوير = اختبار أكثر كفاءة
والأهم من ذلك: كلما قل عدد الرموز التي تجبر الناس على قراءتها ، زاد احتمال قراءتها على الإطلاق.
فيما يلي بعض الطرق التي يمكنك بها خفض التعليمات البرمجية.
مبدأ YAGNI ("أنت لست بحاجة إليه")
مبدأ "أنت لست بحاجة إليها" (يشار إليه غالبًا باسم YAGNI - You Aint 'Gonna Need It) يعني قاعدة البرمجة المتطرفة التالية: "لا تدرك هذه الفرصة أو تلك الفرصة إلا عندما تكون هناك حاجة إليها بالفعل ، وليس عندما تفترض أنها ستكون هناك حاجة قريبا. " حتى لو كنت متأكدًا بنسبة مائة بالمائة من عدم إمكانية تنفيذ هذه الوظيفة في المستقبل ، فلا تبدأ تنفيذها الآن.
هناك سببان لهذه الممارسة:
- يمكنك توفير الوقت من خلال رفض كتابة التعليمات البرمجية غير المطلوبة حاليا.
- تتحسن جودة الشفرة - لا تلوثها بشظايا تستند إلى تخمينات صحيحة أو أكثر ، وتظل في قاعدة الشفرة ، حتى لو لم يتم تأكيد هذه التخمينات.
مفهوم YAGNI معقول تمامًا بغض النظر عن منهجية إدارة المشروع التي تلتزم بها. العمارة الجيدة تتطلب توازنا جيدا من الاحتمالات. تتكون البنية السيئة من مجموعة من الوظائف المرسومة التي تولد قاعدة أكواد تعذبها لدعمها.
القاعدة الأساسية هنا هي: التركيز على ما هو مطلوب بشكل واضح ، وعدم التفكير فيما قد يحدث.
لا تكتب رمزًا غير محمي
الكود غير القابل للتصرف هو الكود المثالي ، الكود الذي سيعمل تحت أي بيانات إدخال وأي شروط. فكرة إنشاء شيء مشابه لها جاذبيتها الخاصة ، خاصة للمطورين الطموحين الذين يرون الفشل في بعض السيناريوهات كإهانة شخصية. ومع ذلك ، تعد الكتابة (أو محاولة الكتابة) رمزًا خاطئًا فكرة فارغة ، لأن كل شيء في العالم له حده الخاص ، والرمز ليس استثناءً.
عند محاولة تطبيق الوحدة النمطية المثالية ، ستصف شروطًا إضافية ، مما يؤدي إلى زيادة التعقيد في قاعدة الشفرة ، وهو ما يتعارض مع الغرض من الكود. ستصبح الوحدة أكثر وأكثر شمولاً بمرور الوقت ، وستستهلك المزيد من الموارد وتصبح مرشحًا للصيانة المتهورة.
هذا هو السبب ، إذا كنت تهدف إلى كتابة رمز أقل ، يجب عليك السعي من أجل أبسط تنفيذ ممكن ، من فئة "إذا كان يعمل فقط".
يذكر دليل البرمجة المتطرفة قاعدتين ذهبيتين لكتابة رمز بسيط:
- أولاً ، قم بتنفيذ الوظيفة الجديدة بأكثر الطرق بدائية والتي يمكن أن تعمل فقط. لا تقم ببناء الهياكل الفوقية لالتقاط الأنفاس ، لا تنقح نفسك - فقط تأكد من أن كل شيء يبدأ. تأكد من أن الكود يجتاز اختبارات الوحدة للحصول على وظائف جديدة (وللقديم أيضًا ، كما هو الحال دائمًا).
- بعد ذلك - وهذا جزء مهم من القاعدة - أعيد تشكيل النظام واعمل على تبسيط الكود قدر الإمكان لجميع الوظائف الموجودة حاليًا في المنتج. اتبع مبدأ DRY والمبادئ الأخرى التي تساعد على جعل النظام أكثر نظافة.
لا تنسى: نحن لا نسعى جاهدين لأقصر طريق ، ولكن لتحقيق أبسط نتيجة.
وفقًا لذلك ، نبدأ بتقسيم الطريقة الحالية إلى عدة أجزاء. في هذه الحالة ، ستعمل خيارات الاختبار دون فشل. بعد ذلك ، نقوم بتغيير (في اتجاه التبسيط) إحدى الطرق الصغيرة الناتجة مع التركيز على خيار الاختبار التالي وما إلى ذلك.
تذكر أن البساطة تكمن في قلب الأناقة. القدرة على التحكم والقضاء على التعقيد غير الضرورية هي البرمجة الرائعة.
لا تجعل الشفرة أسوأ
يمكن اعتبار هذه القاعدة قسم أبقراط للمطورين. يسمع المشاركون في البرمجة باستمرار نصائح بعدم قطع الزوايا وعدم البحث عن حلول يمكن أن تلحق الضرر بالكود وتؤدي إلى تدهوره.
غالبًا ما تتضمن إجراءات تطوير البرامج ، مثل الإجراءات الطبية ، تدخلًا فادحًا وإجراءات مدمرة. بالإضافة إلى ذلك ، الأدوات والتقنيات التي نستخدمها غالبًا ما تكون جديدة ولا يتم التحقق منها (أو لا يتم التحقق منها بشكل كافٍ). علاوة على ذلك ، لا يوجد لدينا مثيل من مجلس الترخيص الطبي أو مكتب مراقبة المنتج الذي يحكم الممارسات وأدوات التطوير التي نختارها. وبالتالي ، فإننا نعرض أحيانًا المريض ، أي البرامج ، على الإجراءات المرتبطة بالمخاطر غير الضرورية ، ولا نفهم تمامًا ماهية هذه المخاطر.
في بعض الأحيان ، في عملية إصلاح المشكلة ، نضر أكثر مما نفع. في كتابه "Perfect Code" ، الذي يعد جزءًا من الأدب الذهبي للمبرمجين ، يكتب ستيف مكونيل أنه إذا كنت لا تعمل من أجل جذر المشكلة ، ولكن في أعراضها ، أنت تزيد الموقف سوءًا - أنت تخدع نفسك ، وتخلق الوهم بأن المشكلة قد تم حلها .
ولكن في بعض الأحيان مراقبة هذه القاعدة قد تكون صعبة للغاية. في بعض الأحيان تكون التعليمات البرمجية القديمة في مثل هذه الحالة بحيث يكون من المستحيل عملياً تنفيذ وظائف جديدة بشكل صحيح دون الإضرار بها. لذلك ، لكي تكون أكثر واقعية ، تحتاج إلى إعادة صياغة القاعدة قليلاً: من "لا تجعل الشفرة أسوأ" إلى "إذا قمت بتقليل جودة الشفرة ، فيجب أن تكون على دراية بما تفعله."
هذا صحيح. إذا كنت لا ترى طريقة لتنفيذ الميزات الضرورية وعدم إفساد الشفرة ، فقم بتحذير أعضاء الفريق الآخرين قبل إجراء التغييرات. خلاصة القول هي أنه في هذه الحالة يمكنك تدهور جودة الكود عمداً.
بالطبع ، هذا لن يجعل الكود السيئ أفضل ، لكن بهذه الطريقة سيكون لديك الوقت للتفكير في الموقف. تُظهر التجربة أن الأشخاص في كثير من الأحيان لا يصلون إلى الحل الأمثل لمجرد أنهم مستعدون لقبول الفكرة الأولى التي تتبادر إلى ذهنهم. لاحظ أننا لا نطلب منك طلب الإذن أو المساعدة في إيجاد أفضل الحلول.
ميزة أخرى لهذه الطريقة هي أنها تقلل من احتمال حدوث مفاجآت غير سارة في الأوقات السيئة - يعرف الفريق بأكمله المشكلات التي يجب توقعها. بفضل هذا ، يمكنك العمل في فريق بالمعنى الكامل للكلمة والتعامل مع هذا الموقف في الوقت المناسب.
تجنب التزامن الزائد
التزامن هو سيف ذو حدين. لا ينبغي اللجوء إليها إلا إذا كنت لا تستطيع الاستغناء عنها.
عندما يتم تنفيذ التعليمات البرمجية بالتسلسل ، يكون من الأسهل فهم الأخطاء والبحث عنها. عند استخدام التزامن ، يتم تنفيذ العمليات إما في وقت واحد أو بترتيب مشوه. هذا التطبيق المحدد يخلق الكثير من المشاكل في تحديد الأخطاء وإصلاحها. من الواضح ، أنه يعقد بنية وتنفيذ الوظائف في وقت واحد على عدة مستويات. فيما يلي بعض المشكلات التي يمكن أن يؤدي تزامن تنفيذها بشكل سيئ:
- حالة السباق: تبدأ العمليات في الحدوث بشكل غير متوقع
- الحظر المتبادل: حظر الكائنات المتداخلة أثناء انتظار اكتمال العمليات المتزامنة
- قلة الموارد: العملية بثبات لا تستطيع الوصول إلى المورد الضروري الذي تتوقعه
أحد أكثر الكوارث البارزة المرتبطة بتطوير البرمجيات كان سببها بالتحديد ظروف مترابطة محددة بشكل غير صحيح. خطأ في البرمجة مع Therac-25 ، جهاز العلاج الإشعاعي ، أدى إلى وفاة أربعة أشخاص.
تجدر الإشارة إلى أن معظم لغات وأطر البرمجة الحديثة توفر أدوات خاصة لتصحيح التزامن. لكن ، في النهاية ، كل هذا يتوقف على المطور - هو الذي يقرر متى وأين وكيف سيتم تطبيقها من أجل تحقيق أفضل نتيجة.
لا تصطدم في اكتناز
اكتناز مرضي هو نوع من السلوك الذي يتميز به جمع عدد كبير من الأشياء غير الضرورية وعدم الرغبة في التخلص منها ؛ ومع ذلك ، يمكن أن تحتل الأشياء معظم مساحة المعيشة ، مما قد يؤدي إلى إصابات وتوتر.
عندما تظهر أعراض التراكم بين المطورين ، فإنهم يبدأون في التشبث بأي جزء من التعليمات البرمجية ، حتى لو كان قديمًا أو يعج بالأخطاء. هؤلاء المطورين لا يحذفون الكود بأنفسهم ويعارضون هذه الممارسة بشكل عام. إذا أخبرتهم بذلك مباشرة ، فاستعن بالإجابات بروح: "قد يحتاج إليه يومًا ما" أو "بدون هذا ، لا يمكنني إجراء العملية X" وما إلى ذلك.
هل هاجمتك متلازمة بليوشكين؟ ربما تخلت عن فكرة ترتيب الأمور لأنك تفهم أنه ليس لديك الوقت الكافي لاكتشاف كل هذه الفوضى؟ إذا كان الأمر كذلك ، فأنت لا تزال تعاني من اكتناز وفوضى كاملة تسود في حياتك العملية.
الادخار غير عقلاني. إذا بدا لك أن وجود جزء من الكود له ما يبرره ، لكنك لست متأكدًا تمامًا منه ، قم بتمييزه وفقًا لذلك بحيث يمكنك الرجوع إليه لاحقًا. لذلك لن تسقط من ذاكرتك. أما بالنسبة للرمز ، الذي لا يفي بالغرض المحدد وغير الحيوي ، فيجب حذفه والنقطة.
يعمل مبرمج جيد على تحسين الكود يومًا بعد يوم ، ومع مرور الوقت ، تتزايد جودة الكود باستمرار. دائمًا ما تبرز الشفرة القديمة المكتوبة بواسطة مبرمج جيد للتأكد من دقتها - لا يترك المحترفون أي فوضى بعدهم ؛ بعد كل شيء ، الرمز هو سمعتنا وسوف يكون هم الذين سيحكمون علينا بها. كما قال روبرت مارتن بحق: "الحقيقة لا يمكن أن توجد إلا في الكود".