تباطؤ لدفع التنمية

من المترجم:
بداية العام وقت رائع لتقييم السنة الماضية بعناية. ألق نظرة واسعة على ما يحدث وفهم كيفية جعل 2019 عامًا أفضل وأكثر هدوءًا وإنتاجية. في هذه الحالة ، وجدنا مقالة كيف تبطئ في العمل بشكل أسرع من أي وقت مضى في تطوير البرمجيات كتبها Lemi Orhan Ergin مفيدة . ونحن ننشر ترجمتها أدناه.

النقاط الرئيسية:

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

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

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

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

يحتاج برنامج Zombie إلى إعادة الكتابة مرارًا وتكرارًا

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

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

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

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

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

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

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

الاندفاع في تطوير البرمجيات هو الشر

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

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

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

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

• الناس - زيادة الاحتراف والمهارة ،
• عملية تحسين المرونة والكفاءة ،
• تحسين جودة المنتج والأتمتة.

أين تبطئ عندما يتعلق الأمر بالناس

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

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

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

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

التوقف عن العمل وحده ، والعمل معا. لا تسمح تجزئة في الفريق. Loners والمطورين البطل هي علامة على تنظيم مختلة وظيفيا. الجلوس بالقرب من. وضع المعايير مع الفريق بأكمله. العمل في أزواج أو مجموعات. مراجعة معا. اسمح لجميع المشاركين في العملية بأن يكونوا مسؤولين عن النتيجة.

الممارسة معًا هي الطريقة الأكثر فعالية لرفع مستوى مهاراتك. من خلال التفاعل ، لا نلهم الآخرين فحسب ، بل نتعلم أيضًا من بعضهم البعض. قم بانتظام بتشغيل تراجع الكود ، والترميز dojo ، و randori مع فريقك بأكمله. اقضي 30 دقيقة كل يوم في التدريب فقط.

دع المعرفة تنتشر بين الناس. نتعلم معا. لقد عقدت جلسات Brown Bag / Lunch & Learn مع جميع الفرق التي عملت فيها منذ عام 2010. سمعت مرتين من زملائي: "المشاركة في جلسات يوم الأربعاء تسمح لي بالضخ ، وهذا يحفزني كثيراً." هذا يعكس بوضوح فوائد إجراء عمليات تخفيف داخلية منتظمة.

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

تعليم الآخرين وتبادل المعرفة هو أفضل وسيلة لتحقيق التمكن. التحدث علنا ​​والمساهمة في المجتمع.

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

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

كيفية إبطاء وتحسين العملية

كل يوم نواجه تحديات جديدة. هذه ليست فقط احتياجات السوق ومتطلبات المنتج الجديد. تؤثر التحديات التقنية أيضًا على تقدمنا.

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

تحديد الأهداف قصيرة وطويلة الأجل. الأهداف قصيرة الأجل تحدد التركيز للفريق ، الأهداف طويلة الأجل تمنع خسارته.

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

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

النفايات هي كل ما تقضيه في الوقت ، لكن هذا ليس له قيمة للعمل. البحث عن النفايات في المكتب والتخلص منها ، وفي الكود وفي العمليات التجارية.

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

يمكنك اكتشاف النفايات في أي وقت في دورة تطوير النظام. اتبع معايير محددة بوضوح للاستعداد (تعريف القيام به) والقضاء على المهام بروح "90 ٪ الانتهاء ، 90 ٪ اليسار."

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

كيف يمكن للتباطؤ تحسين جودة المنتج

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

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

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

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

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

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

لقد كنت تستخدم TDD لسنوات. غالبًا ما يشتكي الناس من أن TDD يؤثر سلبًا على سرعة التطوير. شارك جو Rainsberger أفكاره على TDD على تويتر : " هل أنت قلق من أن TDD سوف يبطئ المبرمجين؟ لا حاجة ربما يحتاجون إلى إبطاء ".

TDD هو أكثر refactoring من الاختبار ؛ تفكير أكثر من الترميز ؛ أكثر بساطة من الأناقة. هذا هو السبب في أن TDD تؤدي إلى جودة أعلى. عند استخدام TDD ، سيكون لديك فقط الحد الأدنى من عدد الاختبارات والتصميم البسيط.

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

قم بتصحيح الأخطاء فورًا إذا استغرق الأمر 30 دقيقة أو أقل. بالإضافة إلى ذلك ، استخدم 20 ٪ من الوقت للقضاء على الديون الفنية.

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

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

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

تباطؤ لتسريع كنهج للحياة

شارك أندرياس مولر مشاعره حول تطوير البرمجيات في تغريدة : "لا أريد أن أكتب كودًا يعمل فقط. أريد أن أكتب رمزًا نظيفًا ويمكن صيانته وسهل الفهم واختباره جيدًا. "

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

يجب أن نتذكر ما يلي:

• نظام العمل ليس بالضرورة مكتوبًا جيدًا
• يمكن للمهنيين الحقيقيين فقط إنشاء نظام مصمم جيدًا
• فقط نظام مصمم جيدًا سيسمح لك بالإفراج عن وظائف جديدة في أسرع وقت ممكن

عن المؤلف

Lemi Orhan Ergin هو معالج لتطوير البرمجيات يسعى إلى رفع مستوى التميز في صناعته ومشاركة تجربته مع المجتمع. Craftbase المؤسس المشارك ومؤسس مجتمع صناعة البرمجيات التركية . شارك في تطوير البرمجيات منذ عام 2001. يمارس بنشاط والموجهين في مجالات مثل سكروم ، والبرمجة المتطرفة ، ومنهجيات التنمية وتقنيات الويب.