منذ بداية عام 2018 ، أصبحت رائدة / مطور رئيسي / رئيسي في الفريق - أطلق عليه ما تريد ، ولكن خلاصة القول هي أنني مسؤول مسؤولية كاملة عن إحدى الوحدات وعن المطورين الذين يعملون عليها. هذا الموقف يعطيني نظرة جديدة على عملية التطوير ، حيث أنني أشارك في المزيد من المشاريع والمشاركة بنشاط أكبر في صنع القرار. في الآونة الأخيرة ، وبفضل هاتين الحالتين ، أدركت فجأة مقدار تأثير الفهم على الكود والتطبيق.
الفكرة التي أرغب في التعبير عنها هي أن جودة الشفرة (والمنتج النهائي) ترتبط ارتباطًا وثيقًا بمدى إدراك الأشخاص الذين يقومون بتصميم وكتابة الشفرة لما يقومون به.
ربما تفكر الآن: "شكراً لك يا كاب. بالطبع ، سيكون من الجيد أن تفهم ما تكتبه على الإطلاق. بخلاف ذلك ، وبنفس النجاح ، يمكنك استئجار مجموعة من القرود للمطرقة على مفاتيح تعسفية ، وتهدئة ذلك. " وأنت على حق تماما. وفقًا لذلك ، أعتبر أمراً مفروغًا منه: أنت تدرك أن وجود فكرة عامة عما تفعله ضروري. يمكن أن يسمى هذا مستوى صفر من الفهم ، ولن نقوم بتحليله بالتفصيل. سنحلل بالتفصيل بالضبط ما يجب فهمه وكيف يؤثر على القرارات التي تتخذها كل يوم. إذا كنت أعرف هذه الأشياء مسبقًا ، فإن هذا سيوفر لي الكثير من الوقت الضائع والرمز المشكوك فيه.
على الرغم من أنك لن ترى سطرًا واحدًا من التعليمات البرمجية أدناه ، إلا أنني ما زلت أعتقد أن كل ما يقال هنا ذو أهمية كبيرة لكتابة رمز تعبير عالي الجودة.
المستوى الأول من الفهم: لماذا لا يعمل؟
عادة ما يصل المطورون إلى هذا المستوى في المراحل الأولى من حياتهم المهنية ، حتى في بعض الأحيان حتى بدون أي مساعدة من الآخرين - على الأقل وفقًا لملاحظاتي. تخيل أنك حصلت على تقرير بالأخطاء: بعض الوظائف في التطبيق لا تعمل ، تحتاج إلى إصلاحها. كيف تتصرف؟
المخطط القياسي يشبه هذا:
- ابحث عن الكود الذي يسبب المشكلة (كيف يتم ذلك هو موضوع منفصل ، أفصح عنه في كتابي عن الكود القديم)
- قم بإجراء تغييرات على هذا المقتطف
- تأكد من إصلاح الخلل وعدم وجود أخطاء رجعية
الآن دعنا نركز على النقطة الثانية - إجراء تغييرات على الكود. هناك طريقتان لهذه العملية. أولاً: للتطرق إلى ما يحدث بالضبط في الكود الحالي ، حدد الخطأ وإصلاحه. ثانيًا: انتقل إلى اللمس - أضف ، على سبيل المثال ، +1 إلى بيان أو حلقة شرطية ، معرفة ما إذا كانت هذه الوظيفة تعمل في السيناريو الصحيح ، ثم جرب شيئًا آخر وما إلى ذلك.
النهج الأول هو الصحيح. كما يوضح ستيف ماكونيل في كتابه Code Complete (بالمناسبة ، أنا أوصي به بشدة) ، في كل مرة نقوم فيها بتغيير شيء ما في الكود ، يجب أن نكون قادرين على التنبؤ بشكل مؤكد كيف سيؤثر هذا على التطبيق. أقتبس من الذاكرة ، ولكن إذا لم يعمل الخطأ الذي كنت تتوقعه ، فيجب أن تكون خاضعًا للحراسة الشديدة ، ويجب أن تشكك في خطة عملك بالكامل.
تلخيص ما ورد أعلاه ، من أجل إجراء إصلاح قوي لا يؤدي إلى تدهور جودة الكود ، تحتاج إلى فهم بنية الكود بأكملها ومصدر مشكلة معينة.
المستوى الثاني من الفهم: لماذا يعمل؟
يتم فهم هذا المستوى أقل حدسيًا من المستوى السابق. كوني مطور مبتدئ ، تعلمت ذلك بفضل رئيسي ، وبعد ذلك أوضحت مرارًا وتكرارًا جوهر الأمر للمبتدئين.
هذه المرة ، دعونا نتخيل أنك تلقيت تقريرين عن الأخطاء في وقت واحد: الأول يتعلق بالسيناريو أ ، والثاني يتعلق بالسيناريو ب. هناك خطأ ما في كلا السيناريوهين. وفقا لذلك ، يتم نقلك أولا عن الخطأ الأول. تسترشد بالمبادئ التي قدمناها للمستوى الأول من التفاهم ، حيث تقوم بالبحث في الكود ذي الصلة بالمشكلة ، ومعرفة سبب فرض التطبيق على التصرف مثل ذلك تمامًا في السيناريو A ، وإجراء تعديلات معقولة تعطي النتيجة التي حددتها بالضبط من المتوقع. كل شيء على ما يرام.
ثم تذهب إلى السيناريو ب. تكرر السيناريو في محاولة لإثارة خطأ ، ولكن - مفاجأة! - الآن كل شيء يعمل كما يجب. لتأكيد تخمينك ، يمكنك إلغاء التغييرات التي تم إجراؤها في عملية العمل على الخطأ "أ" ، ويعود الخطأ "ب" مرة أخرى. حل الخلل الخاص بك حل كل المشاكل. محظوظ!
أنت لم تعتمد عليه على الإطلاق. لقد توصلت إلى طريقة لإصلاح الخطأ في السيناريو "أ" وليس لديك أي فكرة عن سبب نجاحه في السيناريو "ب". في هذه المرحلة ، هناك إغراء كبير لتقرر أن كلتا المهمتين قد تم بنجاح. هذا منطقي تمامًا: كانت النقطة هي إزالة الأخطاء ، أليس كذلك؟ لكن العمل لم ينته بعد: لا يزال يتعين عليك معرفة سبب تصرفاتك في تصحيح الخطأ في السيناريو ب. لماذا؟ بعد ذلك ، ربما كان يعمل على المبادئ الخاطئة ، وبعد ذلك سوف تحتاج إلى البحث عن طريقة أخرى. فيما يلي بعض الأمثلة على مثل هذه الحالات:
- نظرًا لأنه لا يمكن استهداف الحل على وجه التحديد للخطأ B ، مع مراعاة جميع العوامل ، فقد يكون لديك وظيفة غير معروفة.
- من المحتمل أن يكون هناك خطأ في مكان ما يتعلق بالخطأ الثالث المرتبط بنفس الوظيفة ، كما أن bugfix يجعل النظام يعمل بشكل صحيح في البرنامج النصي B عليه. الآن يبدو كل شيء جيدًا ، لكن في يوم من الأيام ، سيتم ملاحظة هذا الخطأ الثالث وإصلاحه. ثم في السيناريو B ، يحدث خطأ مرة أخرى ، وكذلك ، إذا كان هناك فقط.
كل هذا يقدم العشوائية في الشفرة ويومًا ما يقع على رأسك - على الأرجح ، في أكثر اللحظات غير ملائمة. يجب عليك جمع إرادتك في قبضة لإجبار نفسك على قضاء بعض الوقت في فهم سبب ظهور كل شيء ، لكن الأمر يستحق ذلك.
المستوى الثالث من التفاهم: لماذا ينجح؟
إن رؤيتي الأخيرة مرتبطة بدقة بهذا المستوى ، وربما كانت ستوفر لي أكبر الفوائد إذا كنت قد جئت إلى هذه الفكرة في وقت سابق.
لتوضيح الأمر ، دعنا نلقي نظرة على مثال: يجب أن تكون الوحدة النمطية الخاصة بك متوافقة مع الوظيفة X. لست على دراية بالوظيفة X بشكل خاص ، ولكن تم إخبارك أنك بحاجة إلى استخدام إطار F. للتوافق معها. الوحدات النمطية الأخرى التي تتكامل مع X تعمل تمامًا معه
منذ اليوم الأول من حياتك ، لم تتلامس الشفرة الخاصة بك مع إطار عمل F على الإطلاق ، لذلك لن يكون من السهل تنفيذها. سيكون لذلك عواقب وخيمة على بعض مكونات الوحدة. ومع ذلك ، تتقدم إلى مرحلة التطوير: كتابة التعليمات البرمجية لأسابيع ، الاختبار ، طرح الإصدارات التجريبية ، الحصول على ملاحظات ، إصلاح أخطاء الانحدار ، العثور على مضاعفات غير متوقعة ، لا تنسجم مع الإطار الزمني المتفق عليه أصلاً ، كتابة المزيد من التعليمات البرمجية ، الاختبار ، الحصول على العكس اتصال ، تصحيح أخطاء الانحدار - كل هذا من أجل تنفيذ الإطار F.
وفي مرحلة ما ، أدركت فجأة - أو ربما سمعت من شخص ما - أن إطار F لن يمنحك التوافق مع وظيفة X على الإطلاق. ربما لم يتم تطبيق هذا الوقت والجهد على الإطلاق لذلك.
حدث شيء مماثل مرة واحدة أثناء العمل في مشروع كنت مسؤولاً عنه. لماذا حدث هذا؟ لأنني فهمت بشكل سيء جوهر الوظيفة X وكيفية ارتباطها بالإطار F. فماذا أفعل؟ اطلب من الشخص الذي يحدد مهمة التطوير أن يشرح بوضوح كيف تؤدي خطة العمل المخططة إلى النتيجة المرجوة ، بدلاً من مجرد تكرار ما تم القيام به للوحدات النمطية الأخرى ، أو أن تأخذ الكلمة التي تفيد أن الوظيفة X تعمل.
لقد علمتني تجربة هذا المشروع أن أرفض بدء عملية التطوير حتى يكون لدينا فهم واضح لسبب مطالبنا بتنفيذ إجراءات معينة. رفض النص العادي. عندما تتلقى مهمة ، فإن الدافع الأول هو تناولها على الفور حتى لا تضيع الوقت دون جدوى. لكن سياسة "تجميد المشروع حتى ندخل في كل التفاصيل" يمكن أن تقلل من الوقت الضائع بأوامر من الحجم.
حتى لو حاولوا الضغط عليك ، لإجباركم على بدء العمل ، على الرغم من أنك لا تفهم كيف يمكن تبرير ذلك ، فالمقاومة. أولاً ، حدد الغرض الذي تم تعيينك له لمثل هذه المهمة ، وحدد ما إذا كان هذا هو المسار الصحيح للهدف. كان عليّ أن أتعلم كل هذا من خلال تجربة مريرة - آمل أن يضفي مثالي على أولئك الذين قرأوا هذا ، الحياة أسهل.
المستوى الرابع من الفهم: ؟؟؟
هناك دائمًا شيء يمكن تعلمه في البرمجة ، وأفترض أنني لمست فقط الطبقات العليا من موضوع الفهم. ما مستويات الفهم الأخرى التي اكتشفتها على مدار سنوات العمل باستخدام الكود؟ ما القرارات التي اتخذت والتي كان لها تأثير جيد على جودة الكود والتطبيق؟ ما هي القرارات التي اتضح أنها خاطئة وعلمتك درساً قيماً؟ تبادل الخبرات الخاصة بك في التعليقات.