البساطة هيكي

مرحبا يا هبر!

أوجه انتباهكم إلى ترجمة لمقال " Simple Hickey " من تأليف روبرت سي مارتن (العم بوب).



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

سيكون هناك بعض الأشياء في هذه المحاضرة التي لا توافق عليها. عندما يحدث هذا ، توقف وتفكر - فكر بجدية - هل لا توافق حقًا. ربما يجب أن لا تعتقد أن هذا هو الحال.

على سبيل المثال ، يقول ريتش عن بعض الأشياء التي تبدو رافضة عن TDD و Agile and Refactoring - الأبقار المقدسة للمجتمع Agile. إذا كنت ملتزمًا بهذا المجتمع ، يمكنك الرد بشكل سلبي. لا حاجة الغنية لا تهمل الممارسة. يهمل الدين - التهور - التافهة.

ريتش يقارن اختبارات الوحدة مع قضبان السلامة. ثم انه يجعل نقطة جيدة جدا. يقول أنه عندما يكون لديك خطأ ، فإن هذا الخطأ اجتاز اختباراتك. والآن ماذا؟ يجب أن تجد الآن الخطأ. وإذا لم يكن النظام بسيطًا ، فلن يكون الأمر سهلاً. (يرجى ملاحظة أنني استخدمت الكلمات هنا ببساطة وبسهولة. ترتبط بداية خطاب ريتش بتعاريف مختلفة لها هذه الكلمات. أقترح عليك التوقف في هذا المكان والاستماع إلى الدقائق العشر الأولى من كلمته ، ثم العودة إلى هذه الفقرة مرة أخرى.)

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

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

ريتش يضحك من فكرة أن مجموعة الاختبارات ستسمح لك بتغيير الشفرة. يقول إن الاختبارات هي شبكة أمان ، لا شيء أكثر من ذلك. نعرف TDDers أن مجموعة الاختبار ضرورية إذا أردنا تغيير الكود بدون خوف. لكن ريتش محق في شبكة الأمان. يمكن أن يساعدك نظام الأمان في تبسيط نظامك إذا كان بسيطًا بالفعل. لكن نظام الأمن تحت عبء كبير من الأوساخ لن يكون له سوى القليل من المساعدة في كشف الفوضى. لا تفهموني. أحتاج هذه الاختبارات! لكن العمل لن يكون سهلا. (مرة أخرى هذه الكلمة).

إليكم حديث آخر من ريتش: Hammock-Driven Development ، الذي يشجعنا على التفكير فيه ، وليس فقط كتابة القطع والأكواد.


لذلك ها هو. الأثرياء قلقون ، وبحق ، أن لدينا ثقافة معقدة. عندما يتم تعيين مهمة للمبرمجين ، فإنهم يتقدمون إلى الأمام ويكتبون الكثير من التعليمات البرمجية المربكة ، باستخدام الأطر والأدوات "البسيطة" ، دون إعطاء المشكلة المعنى المناسب. ما نخلط بين الخفة والبساطة. (على سبيل المثال ، Rails سهلة ، ولكنها ليست سهلة.) شكواه بشأن الاختبارات هي أننا استخدمناها لاستبدال الأفكار. هذا أمر جيد بالنسبة لنا ، لأننا كتبنا الاختبارات ، لكن في الواقع لم نقضي وقتًا كافيًا في المشكلة التي تستحقها. نحن لم تبسيط المشكلة. لقد فعلنا ما كان سهلا.

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

في النهاية ، أعتقد أن تصور Rich TD TDD مشوه بما يراه في الصناعة. بصراحة ، أعتقد أنه فاته بعض التفاصيل. وأعتقد أنه سيفهم أن هذه الممارسة ستكون مفيدة له بالنسبة لي. ليس كطريقة لتجنب التفكير ورمي نفسك في حالة من الفوضى ، ولكن كوسيلة منضبطة لتكون مفصّلة ودقيقة ومدروسة.

الآن اسأل نفسك ماذا يعني TDD لك. هل TDD هو الانضباط الذي تستخدمه لتسهيل الأمور؟ أم هو مجال تستخدمه لتكون مدروسًا ودقيقًا وليس معقدًا؟