زن وفن دعم قانون نقي



مرحبا يا هبر!

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

هل لديك قراءة لطيفة.

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

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

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

وضع النظام في مرآب الشركات


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

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

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

وضع النظام في تطوير البرمجيات


دعونا نلقي نظرة على مثال محدد: إعادة بيع المساكن تدريجيا.

هذا التعبير محير للكثيرين. لا أعرف أي كلمة تربكهم: "تزايدي" أو "إعادة بناء".

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

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

إعادة بناء المساكن تدريجيا


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

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

القاعدة الكشفية


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

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

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

"طويل الأجل" عادة لا يكون طويلاً كما يبدو


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

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

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

ما هو سريع ، ما هو بطيء؟


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

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

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

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

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

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

الدين الفني بمثابة استعارة


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

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

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

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

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

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

من المسؤول؟


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

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

Source: https://habr.com/ru/post/ar431670/


All Articles