لتصبح مبرمجًا ، عليك التسجيل في تدريب مدى الحياة. لا يجف دفق الميزات الجديدة - الميزات الجديدة واللغات الجديدة والأدوات الجديدة والأطر الجديدة - أبدًا. ولكن في الوقت نفسه ، تعد البرمجة مجالًا ، مخلصًا بشكل مدهش للتقاليد ، حيث يعتمد كل شيء على مبادئ تم اختبارها بمرور الوقت. قدمنا البرمجة الموجهة للكائنات ، وحلول الأجهزة الحديثة ، والذكاء الاصطناعي ، ومع ذلك ، على الرغم من كل هذه التغييرات ، فإن العديد من البديهيات التي صيغت في الجيل الماضي أصبحت صحيحة اليوم.لقد كرست هذه المقالة لبعض بياناتي المفضلة حول البرمجة. المعيار الوحيد الذي اخترت به الاختيار هو شرط أن يكون الاقتباس مساوياً لعشرين سنة على الأقل. لأن التقنيات القديمة فقط هي التي أصبحت غير قابلة للاستخدام بسرعة ، في حين أن الوصايا القديمة لمبرمجي أسلافنا ظلت لفترة طويلة ذات صلة.1. اللا مباشرة
"يتم حل جميع مشاكل البرمجة من خلال إنشاء مستوى إضافي من التوجيه" - ديفيد ويلير
هنا اقتباس من كتاب نظرية علوم الكمبيوتر والتطبيق ، الذي يحب الجميع تكراره وقليل من الناس يرغبون في شرحه. ومع ذلك ، فهذه إحدى حقائق البرمجة المفضلة لدي - فهي تكشف عن جوهر البرمجة.أسهل طريقة لفهم الاتجاه غير المباشر هي تخيل الطبقات. حسنًا ، على سبيل المثال ، تخيل أن لديك مشروعًا صغيرًا تحتاج فيه إلى وضع المكون أ داخل المكون ب:كلا المكونين موحدين ، لذا فإن تفكيكها إلى مكونات وتغيير مبدأ التشغيل لن يعمل. يمكنك إنشاء مكون إضافي منفصل ( PlugTwoProngVariant) ، ولكن هذا عمل كثير وتكرار غير ضروري. هناك حل أفضل: أضف طبقة محول بين هذين المكونين تتفاعل بنجاح مع كليهما وتعمل كوسيط بينهما.مع كل هذا ، إذا تم استنفاد غير المباشرة بإضافة طبقات إضافية بين المكونات التي لن ترسو بطريقة أخرى ، فسيكون ذلك بالطبع مفيدًا ، ولكنه محدود جدًا في التطبيق. لكن فكرة حل المشكلات عن طريق تغيير بيئة مناطق المشاكل تتخلل جميع البرمجة من الأعلى إلى الأسفل. تصادفها عند محاولة ملاءمة نموذج بيانات جديد للواجهة القديمة. تصادفها عندما تحاول إرفاق تطبيق برمز قديم بالواجهة الخلفية لخدمة ويب جديدة. تصادفها عندما تحتاج إلى إضافة العديد من الوظائف الجديدة عالية المستوى مثل التسجيل والتخزين المؤقت أو تنسيق عمل العديد من الخدمات عالية المستوى مثل إرسال الرسائل وإجراء المعاملات.في الجزء العلوي من هذا الهرم ، تأتي إلى اتجاهات محسنة مثل التعلم الآلي (إذا لم تتمكن من كتابة سلوكك الخاص ، أضف طبقة أخرى من التعليمات البرمجية التي ستحل هذه المشكلة لك).سيخبرك الكثيرون أن الهدف من البرمجة هو كتابة تعليمات واضحة بلغة يمكن حتى لأغبي الكمبيوتر فهمها . لكن اقتباس ديفيد ويلر يقدم نظرة أعمق على السؤال. أن تكون مبرمجًا جيدًا يعني أن تتسلق سلم اللامباشرة ، وتسعى جاهدًا للحصول على الحلول الأكثر شيوعًا.الاقتباسالإضافي على Indirectness هو أداة قوية ، ولكن عليك أن تدفع ثمن التعقيد. نادرًا ما يستشهد الناس بالبيان بعد الاقتباس الشهير:"هذا عادة ما يخلق مشكلة جديدة." - ديفيد ويلر.
وبفضل هذه الحقيقة ، ظل المبرمجون لفترة طويلة في العمل.2. حول البساطة
"البساطة شرط أساسي للاعتمادية" - Edsger Dijkstra
لا يوجد نقص في المبرمجين الحكماء الذين يحذروننا من تعقيد التعليمات البرمجية دون الحاجة الملحة. لكن قلة قليلة تمكنت من إظهار مدى التعقيد بالنسبة لنا كرائد في علوم الكمبيوتر ، Edsger Dijkstra .هذه هي النقطة: أنت تقوم باختيار لصالح البساطة ليس فقط من الرغبة في جعل المستقبل يرضي الناس. وليس لأنك تفترض القدرة على إعادة استخدام هذا الرمز في المستقبل. وليس لأنك تريدها أن تبحث بدقة أكبر في عمليات التفتيش ، وليس لأنك تريد تسهيل عملية إجراء التغييرات في المستقبل (على الرغم من أن كل هذا ، بالطبع ، ميزة قيمة). أنت تفعل ذلك لأن البساطة شرط مسبق. بدونها ، لن يكون لديك مطلقًا رمز موثوق به يمكنك الوثوق به في إدارة الأعمال أو العمل مع البيانات.لاتخاذ موقف ديكسترا ، نحتاج إلى تغيير فهمنا لما هو "رمز جيد". هذا ليس بالضرورة الرمز الأكثر إيجازًا ، أو الأسرع ، وبالتأكيد ليس الأكثر ضبابية. الكود الجيد هو الكود الذي يمكنك الاعتماد عليه.عرض أسعار إضافي حول موضوعواحد من أفضل الطرق للحفاظ على الكود البسيط هو تذكر أن القليل هو أكثر. تقدم ديكسترا وحدة قياس جديدة تذكرنا دائمًا بما يلي:"إذا أردنا أن نحسب عدد أسطر التعليمات البرمجية ، فيجب ألا ندركها كما هي مكتوبة ، ولكن كما تم إنفاقها" - Edsger Dijkstra
3. حول سهولة القراءة وإعادة الكتابة
"قراءة الشفرة أصعب من الكتابة" - جويل سبولسكي
للوهلة الأولى ، يبدو هذا الاقتباس من جويل سبولسكي ، أسطورة البرمجة والمؤسس المشارك لـ Stack Overflow ، معقولًا ولكنه سطحي مخادع. نعم ، أجزاء التعليمات البرمجية غنية بالمعلومات أو مضغوطة بشكل مفرط أو طويلة جدًا. وهذا لا ينطبق فقط على ما كتبه الآخرون. إذا نظرت إلى عملك الخاص في العام الماضي ، فستحتاج إلى بعض الوقت لإعادة إنشاء المنطق الذي كنت تعرفه من وإلى.لكن ملاحظة سبولسكي تتكشف في شيء مثير للاهتمام. إن خطر وجود رمز يصعب قراءته ليس فقط العواقب الأكثر وضوحًا (من الصعب تصحيحه وتحسينه). هناك خطر آخر كبير: فالشفرة التي يصعب قراءتها تبدو أسوأ مما هي عليه في الواقع. في الواقع ، قد يبدو فهم رمز شخص آخر مهمة شاقة لدرجة أنك ستميل إلى القيام بما يسميه سبولسكي أكبر الأخطاء - لإعادة كتابة كل شيء مرة أخرى.أنا لا أقول أن بنية النظام لا تستفيد من مثل هذه إعادة الكتابة. بالطبع ، يحدث أن يفوز. لكن تحسين هذا النوع مكلف. في كل ما يتعلق باختبار وإصلاح الأخطاء - وهذان عنصران من التطوير يستغرقان وقتًا أطول من كتابة التعليمات البرمجية نفسها - يمكنك العودة إلى وضع البداية. تبدو إعادة الكتابة مغرية لأنها تتناسب مع أحد أكثر المفاهيم الخاطئة شيوعًا للمطورين - الميل إلى التقليل من تكاليف العمالة للأشياء البسيطة المفاهيمية. هذا هو السبب في قضاء 50٪ من الوقت على 5٪ الأخيرة من المشروع. يمكن أن تستغرق المهام الأولية وقتًا مدهشًا! وحل المشكلة التي تم حلها في الماضي يبدو دائمًا بسيطًا.حسنًا ، إذا أعدت كتابة كل شيء بدءًا من الصفر لإحضار الشفرة إلى الكمال ، فلا يجب أن تفعل ذلك ، فما هي البدائل الأكثر نجاحًا؟ الجواب: إشراك كل مطور في عملية إعادة بناء التجزئة المجزأة المستمرة . لذلك يتم تحسين شفرتك باستمرار ، بسبب سلسلة من التغييرات الصغيرة - فائدة حقيقية بأقل قدر من المخاطر. يمكن تحسين القراءة على طول الطريق.الاقتباس الإضافي للموضوعإذا كنت لا تزال تشك في أهمية سهولة القراءة ، فإن مارتن فاولر سيساعد في النظر إلى المشكلة على نطاق أوسع:"يمكن لأي أحمق كتابة التعليمات البرمجية التي يمكن لأجهزة الكمبيوتر فهمها. المبرمجون الجيدون يكتبون كودًا يمكن للناس فهمه. ”- مارتن فاولر
وبعبارة أخرى ، فإن مهمة المبرمج هي ليس فقط إصدار كود عمل ، بل كود مع منطق داخلي.4. حول التكرار
"عدم تكرار. يجب أن يكون لكل معلومة تمثيل فريد لا لبس فيه وموثوق به في النظام "- أندي هانت وديفيد توماس
يعرف كل مبرمج يحترم نفسه أن العديد من المشاكل تكمن في التكرار. إذا كتبت الشيء نفسه في عدة أماكن ، فيجب عليك بذل المزيد من الجهد في اختبار الأخطاء وإصلاحها. الأسوأ من ذلك ، أنت تهيئ الظروف للاختلافات ؛ على سبيل المثال ، قد يتم تحديث جزء واحد من التعليمات البرمجية في وقت لاحق ، وقد لا يتم الامتثال للإجراءات الأخرى ذات الصلة. البرنامج المتشعب هو برنامج لا يمكن الوثوق به ، ولا يمكن اعتبار البرنامج الذي لا يمكن الوثوق به حلاً قابلاً للتطبيق.يمكن تجنب هذا الخطأ باستخدام الطريقةGetTeamUniform()، ولكن التكرار يعيث فسادًا ليس فقط في الكود. هذا الإصدار من مبدأ DRY المعروف جيدًا (لا تكرر نفسك) يفسر مبدأ التخلص من التكرارات على نطاق واسع ، ويغطي أماكن أخرى حيث يمكن التكرار أن يشق طريقه. الآن لم تعد المحادثة حول التكرارات في الرمز - نحن نتحدث عن التكرار في جميع أنحاء النظام أيضًا. وأنظمة ترميز المعرفة بتنسيقات مختلفة. على وجه الخصوص ، هذه هي:- العاملين
- تعليقات التعليمات البرمجية
- وثائق للمطورين أو العملاء
- مخططات البيانات (مثل جداول قاعدة البيانات)
- مواصفات أخرى - خطط الاختبار ومعالجة وثائق التنظيم وقواعد التجميع
قد تتداخل كل هذه المجموعات في المحتوى. وعندما يحدث هذا ، هناك خطر من أنهم سيبدأون في بث إصدارات مختلفة لواقع واحد. دعنا نقول ما يجب فعله إذا كانت الوثائق تصف نموذجًا واحدًا للعمل ، والتطبيق نفسه يتبع نموذجًا مختلفًا؟ ما في هذه الحالة يعتبر صاحب الحقيقة؟ ولكن ماذا لو كانت الجداول في قاعدة البيانات لا تتطابق مع نموذج البيانات من الكود؟ أو إذا كانت تعليقات الكود تصف عملية أو خوارزمية تختلف اختلافًا جوهريًا عن التنفيذ الفعلي؟ يحتاج كل نظام إلى تمثيل واحد موثوق يعتمد عليه كل شيء آخر.بالمناسبة ، لا ينبغي للمرء أن يعتقد أن الخلافات بين المتقدمين للحصول على الحقيقة تحدث فقط في المشاريع الصغيرة أو هي نتيجة لسوء كود الجودة. واحدة من أفضل الأمثلة التي ظهرت في مرمى البصر هي المعركة بين XHTML و HTML5. زعم أحد الجانبين أن المواصفات - هذه هي النسخة الرسمية الصحيحة ، ويجب أن تتكيف المتصفحات معها. اعترض معسكر آخر على أن سلوك المتصفحات هو الذي يجب اعتباره المعيار الفعلي - بعد كل شيء ، هذه هي الطريقة التي تصور بها المصممون كل شيء عندما كتبوا صفحات الويب. في النهاية ، فازت نسخة الحقيقة التي روجت لها المتصفحات . منذ ذلك الحين ، HTML5 هو ما تفعله المتصفحات بالفعل ، بما في ذلك الاختصارات والأخطاء الصالحة.اقتباس مكافأة في الموضوع.احتمال أن تتعارض التعليمات البرمجية والتعليقات عليها مع بعضها البعض ، وقد ولدت مناقشات حية: ما هو أكثر من التعليقات - جيدة أو سيئة؟ يعاملهم مؤيدو البرمجة المتطرفة بعدم الثقة التام."الرمز لا يكذب أبدًا ، لكن هذا يحدث بالتعليقات" - رون جيفريز
5. حول المشاكل المعقدة
"في علوم الكمبيوتر ، هناك مشكلتان معقدتان فقط - إبطال ذاكرة التخزين المؤقت والخروج بأسماء" - فيل كارلتون
في المظهر ، يبدو هذا الاقتباس مجرد نكتة مبرمج ، مضحكة ، ولكنها لا تبرز عن الآخرين. يمكن لأي شخص أن يشعر بالتناقض بين شيء يبدو وكأنه مهمة شاقة (إبطال ذاكرة التخزين المؤقت) وشيء يبدو وكأنه هراء حقيقي (اختراع الأسماء). لقد قتل أي مبرمج مرة واحدة على الأقل ساعات كاملة لبعض المشاكل الصغيرة المضحكة - معلمتان ، تم ترتيبهما بشكل خاطئ ، متغير في مكان ما بحرف كبير وفي مكان آخر (بفضل JavaScript!). بينما يتعين على الأشخاص العمل مع أجهزة الكمبيوتر لتحقيق أهدافهم ، ستكون البرمجة دائمًا مزيجًا من تخطيط النظام عالي المستوى والأخطاء المطبعية الغبية.ولكن إذا نظرنا عن كثب إلى كلمات Phil Cardboard ، فسوف نجد هنا مساحة أكبر للتفكير. من الصعب التوصل إلى أسماء ، ليس فقط بسبب الصداع الصغير الذي يعاني منه المبرمج ، فكل حياته يمر رأسًا على عقب. النقطة هنا هي أن الأسماء هي أحد جوانب المهمة الرئيسية للمبرمج ، تصميم البرنامج. بمعنى آخر ، كيف تتم كتابة الشفرة الواضحة والأنيقة والمتسقة بشكل عام؟هناك العديد من أنواع الأسماء السيئة. التقينا جميعًا بالمتغيرات التي تم تسميتها بعد أنواع البيانات ( myString، obj) ، والاختصارات ( pcأي كتالوج المنتجات) ، وبعض تفاصيل التنفيذ غير المهمة ( swappable_name، formUserInput) ، أو حتى تُركت بدون اسم ( ret_value،tempArray) من السهل الوقوع في فخ وتسمية متغير بناءً على ما تفعله به الآن ، وليس من محتوياته. ومع قيم أنواع البيانات المنطقية ، فإن المشكلة هي: ماذا يعني progress- أن التقدم قد بدأ بالفعل ، وأنك بحاجة إلى عرض معلومات حول التقدم في الواجهة ، أو أي شيء آخر بشكل عام؟المصدر: CommitStrip.comنقل«results_tmp_2? ?.. , ? !» — «, … , results_tmp_2. »
لكن الأسماء المتغيرة ليست سوى البداية. عندما تبدأ في الخروج بأسماء للفصول ، يبرز السؤال حول كيفية تقسيم الشفرة إلى أجزاء مستقلة. تحدد أسماء أعضاء الجمهور ما سيكون عرض الواجهة التي من خلالها ستتفاعل أجزاء مختلفة من التطبيق مع بعضها البعض. من خلال تعيين اسم لجزء من التعليمات البرمجية ، فأنت لا تصف فقط ما يمكن أن تفعله - فأنت تحدد ما ستفعله.اقتباس مكافأة في الموضوع.« – , » —