لا توافق على تطوير شيء لا تفهمه

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

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

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

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

المستوى الأول من الفهم: لماذا لا يعمل؟

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

يبدو المخطط القياسي كما يلي:

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

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

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

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

المستوى الثاني من الفهم: لماذا يعمل؟

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

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

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

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

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

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

المستوى الثالث من الفهم: لماذا يعمل؟

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

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

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

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

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

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

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

المستوى الرابع من الفهم: ؟؟؟

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

المصدر: www.habr.com