نصيحة حول كيفية التعامل مع قانون الإرث

جهاز APPLE MACINTOSH الأيقوني

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

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

خلال الشهر الرابع ، طُلب مني إضافة مشروط مرشح التبديل إلى تطبيق أنشأه أحد زملائي في العمل قبل عامين أو ثلاثة أعوام. بدا الأمر سهلاً بما فيه الكفاية ؛ قضيت معظم السنوات الثلاث الماضية في العمل على تطبيق معقد بشكل لا يصدق يتضمن الحزمة القياسية: TypeScript / React / Angular / Dotnet. لقد قمت بالفعل بحل العديد من المشاكل الفريدة وشعرت بالثقة في قدرتي على البرمجة بما يكفي لإنشاء مشروط بسيط لتمرير معلمات الاستعلام إلى الواجهة الخلفية.

كما كنت قد خمنت ، لم يكن الأمر بهذه البساطة. لكن لماذا؟

ما هو الرمز القديم ولماذا قد يكون من الصعب التعامل معه

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

في حالتي ، استخدم التطبيق قالب نص XAML و T4 بدلاً من رمز C # الأساسي ، ولم يتم كتابته بقوة كما اعتدت عليه. هذا جعل الأمر أصعب بالنسبة لي لفهم هيكل البيانات. لا توجد أنواع تعني أنني كنت أواجه TypeErrors في وقت التشغيل بشكل أكثر تكرارًا ، والذي قد يكون من الصعب تصحيحه عند كتابة ميزة كبيرة. علاوة على ذلك ، استخدم التطبيق إصدارًا أقدم من dotnet ، والذي كان بحاجة إلى التوفيق بينه وبين إصدار متوافق من مكتبة المكونات.

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

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

كيفية التعامل مع الشفرة القديمة على المستوى الفني

اقرأ الوثائق والتعليقات البرمجية عندما يكون ذلك ممكنًا

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

انظر إلى قاعدة التعليمات البرمجية ككل

إذا كنت تائهًا ولا تعرف من أين تبدأ ، اسأل نفسك هذه الأسئلة:

  • ما هو الغرض من التطبيق؟
  • كيف تتدفق البيانات من خلال التطبيق؟
  • كيف تتناسب ميزتك مع التطبيق؟

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

اختبر التطبيق يدويًا وباختبارات الوحدة كلما أمكن ذلك

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

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

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

طلب المساعدة

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

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

اعرف متى تقلص خسائرك

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

ومع ذلك ، هناك عيوب في القيام بذلك بهذه الطريقة:

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

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

كيفية التعامل مع الشفرة القديمة على المستوى النفسي

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

كن متواضعا ولطيفا

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

هناك الكثير من العوامل التي يمكن أن تؤدي إلى ظهور رمز قديم في وضع "إيقاف التشغيل" والذي يجب أن تأخذه في الاعتبار قبل أن تبدأ في انتقاد المؤلف أو افتراض الأسوأ بشأنه (وهذا مرتبط بشكل فضفاض بخطأ الإسناد الأساسي!).

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

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

تغيرت الاتفاقيات.

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

يصبح كل رمز في نهاية المطاف إرثا

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

افتخر بالنجاحات الصغيرة

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

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

فى الختام

استخدم هذا الوقت لتعزيز كتابة التعليمات البرمجية الخاصة بك

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

تطوير تطبيقات للمستخدم والمطور المستقبلي

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

تذكر أن شفرتك ستكون قديمة في يوم من الأيام

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

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