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

كان هناك المادة الأخيرة على الكوارتز التي تحدثت عن انتباه أبل لقوائم المراجعة.

لقد تبين أن المفتاح لإبداع Apple وسرعته وقدرته على التكيف ، على سطحه ، هو النقيض التام لنوع الإبداع الحر الذي يمكن أن يتوقعه المرء. انها قائمة مرجعية ... واحدة طويلة حقا.

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

لكن قوائم المراجعة ليست جيدة إلا إذا كانت مطبقة ويتم تحديثها في كثير من الأحيان ، وكنت لا تزال في نزوة من إنسان ، دعنا نواجهها ، لا نبني لتكون مثالية طوال الوقت.

مشكلة العالم الحقيقي

لدينا معيار دروبال تثبيت نبدأ مع معظم العملاء الذين هم على دروبال. يتضمن ذلك الوحدات والإعدادات والمستخدمين الافتراضيين وبيانات الاختبار الافتراضية. كانت تستخدم كقائمة تحقق ، ولكنها كانت قديمة دائمًا. ثم دخل أحدهم وجعله محددًا جدًا حتى أن أي شخص لديه معرفة محدودة بدربال يمكنه فعل ذلك ، لذا فقد كرهه كل الناس الذين يذهبون إلى دروبال في المتجر ، لذا استنفدنا ذلك ، ثم لم نتمكن من تدريب أي شخص جديد على ذلك ، فلم يكن بوسع سوى كبار المحترفين في دروبال متابعتها ، لذلك بدأنا في تشفيرها Drush.

يعني Drush أن أي شخص لديه خبرة دروبال يمكنه تشغيل بضعة أسطر من الشفرة وكل شيء "يحدث" بطريقة سحرية. لا مزيد من "الأخطاء البشرية" ، إنها قائمة مرجعية ، ولكن بدلاً من الإنسان الفوضوي الذي يحاول اتباع قائمة التحقق ، اتبعها الكمبيوتر.

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

في النهاية ، توصلنا إلى الحل الواضح ، وهو أمر مشفر في Drush ، الأمر الذي جعل من الصعب تغييره إلى حد ما.

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

"في المرة الأولى التي تفعل فيها شيئًا ما تفعله فقط. في المرة الثانية ، افعل ذلك وتدوين الملاحظات. في المرة الثالثة ، توقف واكتشف ما إذا كان هو نفسه. إذا كانت هذه العملية ستخرج منها لأنه سيكون هناك على الأرجح 4 و 5 ، وهكذا. "- غافين أندريسن ، CTO Bitcoin

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

علمنا غافن أن الشفرة الجيدة هي ذاتية التوثيق.

الوصايا 10 من الوثائق

  1. لا يجب الإفراط في التوثيق - إذا استغرق الأمر وقتًا أطول للوثيقة من أن تفعل ، فأنت تفرط في التوثيق.
  2. يجب عليك أتمتة قبل وثيقة - اخراج العامل البشري كلما أمكن ذلك.
  3. لا يجوز لك التشويش على الشيء نفسه ثلاث مرات - إذا كنت قد عابث أو اضطرت إلى معرفة نفس الشيء مرتين ، فقد حان الوقت لإجراء الإجرائية.
  4. إذا فشلت ، فاجعلها تفشل - الأشياء الأكثر تعقيدًا هي الأشياء التي تفتقدها في المرة الأولى (وحتى العاشرة) التي تراجعها. إذا كان لديك خيار بين إنشاء عملية من شأنها إيقاف خط التجميع أو تعطل موقعك إذا فشلت أو التي ستحدث خطأً طفيفًا ، فاختر دائمًا "إنزال الموقع" لأنك ستكتشف المشكلة لأول مرة على الأقل .
  5. يجب عليك أن تضع العملية حيث يجب على المرء أن يتفوق عليها - لأنه يحتاج إلى العثور عليها.
  6. امتلاكه - عند اتباع إحدى العمليات ، ضع في اعتبارك أن عملك هو تحقيق أفضل نتيجة. انها ليست لمتابعة هذه العملية. دائما تقترب من الشكوك وتبدو ناقدة في النتائج.
  7. اعترف عندما لا يعمل - أحيانًا قد تبدو الأشياء كما هي ، ولكنها ليست كذلك. في عالمنا ، نحتاج دائمًا إلى بيانات اختبار قياسية ، ولكن عملية إنشاء ذلك في WordPress مختلفة تمامًا عن إنشاءها في دروبال ، لذلك نحتاج إلى عمليات مختلفة تمامًا.
  8. إصلاح المشكلة بسرعة - إذا كانت العملية قديمة ، فلا تقم فقط بتجاهل المشكلة وجناحها ، أو انتقاء الأجزاء التي تريد متابعتها واختيارها. اصلاحها كما تذهب. لن يستغرق الأمر سوى دقائق قليلة في معظم الحالات ، وستتحول هذه الدقائق إلى ساعات في المرة القادمة التي تستخدم فيها أنت أو أي شخص آخر هذه العملية.
  9. اختر معاركك - يقول ستيف كروج (سيد القابلية للاستخدام) أنه يجب عليك الاختبار كثيرًا. العثور على أكبر مشكلة لديك. قم بأخذ كمية العمل التي يمكنك القيام بها حتى لا تعد المشكلة الأكبر ثم تتكرر. أنت لا تحاول الحصول على أي شوكة صغيرة خارج النظام ، فأنت تحاول الحصول على نظام WHOLE ليعمل بشكل أفضل.
  10. مراجعة - إذا كنت قد استخدمت عملية عشرات المرات ولم تقم بتغييرها ، فيجب أن تفكر في كيفية جعلها أكثر كفاءة أو إذا كان يجب عليك جعلها تلقائية.