لماذا يصبح كودك غريبًا عليك بعد أشهر من كتابته

لماذا يصبح كودك غريبًا عليك بعد أشهر من كتابته

عالم البرمجة

مطور يراجع كودًا قديمًا قبل تعديل جزء لم يعد يتذكر سياقه

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

بعد دقائق تبدأ في تتبع متغيرات لا تتذكر سبب تسميتها، وشروط تبدو زائدة، ومسار بيانات تعرف 

أنه يعمل لكنك لا تعرف لماذا بُني بهذه الطريقة.

هذا الشعور لا يعني أن مستواك تراجع، ولا أن الكود القديم سيئ لمجرد أنك احتجت إلى وقت لفهمه.

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

 التي رفضتها، والقيود التي ظهرت في الاختبار، وما الذي كان مؤقتًا وما الذي كان مقصودًا.

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

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

المشكلة الحقيقية إذن ليست أن نسخة مستقبلك أصبحت غريبة عن الكود، بل أن بعض القرارات 

كانت مفهومة فقط لأنك كنت حاضرًا لحظة اتخاذها.

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

ما يختفي أولًا هو سياق المهمة لا قدرتك على البرمجة

أثناء تطوير ميزة جديدة تكون لديك صورة مؤقتة تجمع ملفات متعددة في ذهنك.

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

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

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

أبحاث استئناف مهام البرمجة بعد الانقطاع وجدت أن المطورين يعتمدون على ملاحظات وآثار سابقة

 عند العودة، وأن استعادة السياق ليست لحظة واحدة بل سلسلة من التنقل والفهم وإعادة بناء الهدف قبل استئناف التعديل.

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

السؤال الأدق هو كم دليلًا تركه المشروع يساعدك على استعادة الصورة، وكم جزءًا لا تستطيع فهمه

 إلا بالتخمين.

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

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

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

ابدأ من سلوك النظام قبل أن تغرق في تفاصيل التنفيذ

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

هذه الطريقة قد تجمع معلومات كثيرة قبل أن تعرف أيها مهم للمهمة الجديدة.

ابدأ من السلوك الذي تريد تعديله.

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

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

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

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

وقد تكتشف أثناء التشغيل أن الكود الذي ظننته مهمًا لا يصل إليه المسار الحالي أصلًا، أو أن السلوك

 يعتمد على إعداد أو خدمة خارجية لم تكن ظاهرة من قراءة الملف وحده.

هذه المعلومة توفر عليك تفسير أجزاء لا تخص التغيير.

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

الأسماء الجيدة تختصر الأسئلة لكنها لا تعوض التصميم الواضح

الاسم الواضح يترك معلومة داخل الكود نفسه.

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

هناك دراسات تجريبية تدعم أهمية أسماء المعرفات في فهم الكود، لكن أثر الاسم ليس سحريًا.

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

لهذا استخدم الاسم ليكشف المعنى الذي يحتاجه القارئ، لا ليحكي جملة كاملة.

يجب أن يساعدك على توقع دور المتغير أو الدالة قبل فتح كل التفاصيل، ثم يؤكد التنفيذ هذا التوقع 

بدل أن يفاجئك بعكسه.

عندما يتغير دور عنصر مع الزمن ولا يتغير اسمه، يتحول الاسم القديم إلى مصدر ارتباك أكبر من الاسم المختصر.

إعادة التسمية هنا ليست تجميلًا، بل تصحيح للعقد الذهني بين الاسم والسلوك.

وعند مراجعة كود قديم لا تبدأ بحملة إعادة تسمية شاملة.

غيّر الاسم عندما فهمت الدور الحالي فعلًا وعندما يخدم التعديل الذي تعمل عليه، حتى لا تستبدل غموضًا قديمًا بتفسير جديد غير دقيق.

التعليق المفيد يحفظ السبب الذي لا يستطيع السطر حفظه

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

 بدل حل أبسط.

هنا تظهر قيمة التعليق.

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

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

 بدل أن تعيد وصف السطر بطريقة أخرى.

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

التعليق الذي يقول زد العداد لا يضيف شيئًا إذا كان السطر يفعل ذلك بوضوح.

أما تعليق يوضح أن الزيادة تأتي قبل الحفظ لتجنب إعادة معالجة حدث مكرر فيحفظ قيدًا قد لا يظهر من الصياغة وحدها.

لكن التعليقات نفسها تحتاج صيانة.

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

كل تغيير يلمس القرار الموثق يجب أن يراجع التعليق معه.

تاريخ التغيير يحفظ جزءًا من القصة التي لا تظهر في الملف

أحيانًا لا يكفي الاسم ولا التعليق لأن السبب الحقيقي كان مرتبطًا بمشكلة قديمة أو قرار مؤقت

 أو نقاش حدث أثناء تعديل سابق.

هنا يصبح سجل التغييرات مصدرًا مهمًا لاستعادة السياق.

وصف تغيير جيد لا يكتفي بقول تم تعديل الدالة.

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

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

استخدم تاريخ Git كدليل لا كحقيقة كاملة.

اقرأ ايضا : كيف أغير بنية قاعدة البيانات دون إفساد بيانات المستخدمين؟

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

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

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

إذا كانت الإجابة لا، فاحفظ السبب في المكان الذي سيبقى قريبًا من التغيير.

وقد يكون هذا المكان وصف التغيير نفسه، أو تذكرة مرتبطة به، أو وثيقة قرار قصيرة عندما تكون المسألة أوسع من تعليق داخل دالة.

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

حدود المكونات تقلل مساحة البحث لكنها ليست وصفة ثابتة

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

 أو عندما تتغير بيانات صغيرة فتمر عبر أجزاء كثيرة لا تملك حدودًا واضحة بينها.

لكن هذه الصفحة ليست دليلًا لاختيار معمارية المشروع.

لدينا فرق مهم بين بناء بنية تتحمل نمو التطبيق وبين القدرة على العودة إلى جزء قديم واستعادة سياقه بسرعة.

الحدود الجيدة تساعد هنا لأنها تضيق مساحة القراءة.

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

هذا لا يعني أن كل دالة يجب أن تكون قصيرة، ولا أن كل مسؤولية تحتاج ملفًا مستقلًا، ولا أن تقسيم

 الكود إلى مكونات أكثر يجعل الفهم أفضل تلقائيًا.

الإفراط في التجزئة يستطيع أن يجبرك على التنقل بين ملفات كثيرة لفهم فعل بسيط.

المعيار العملي هو هل تستطيع تتبع مسؤولية واحدة ومسار بيانات واحد دون أن تقفز عشوائيًا

 بين مناطق لا تعرف سبب ارتباطها.

إذا لم تستطع، فقد يكون التداخل نفسه جزءًا من تكلفة العودة.

الاختبارات تحفظ السلوك المتوقع لكنها لا تشرح كل سبب

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

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

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

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

لكن الاختبارات ليست وثائق كاملة.

قد تكون ناقصة، أو مرتبطة بتفاصيل تنفيذ، أو خضراء رغم أنها لا تختبر الشيء المهم.

لذلك لا تستخدم وجودها كبديل عن فهم السياق.

كما أن موضوع تصميم شبكة الاختبارات له صفحته المستقلة.

ما نحتاجه هنا فقط هو استخدام الاختبار كأثر يساعد على استعادة السلوك المتوقع قبل تعديل 

الجزء القديم.

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

حاول أولًا تثبيت السلوك الذي تحتاج الحفاظ عليه بفحص مناسب قبل إعادة هيكلة الجزء الذي 

لا تفهمه جيدًا.

لا تعالج شعور الغرابة بإعادة كتابة كل ما لا يعجبك

من الطبيعي أن تنظر إلى كود عمره عام وتجد أسلوبًا لم تعد تستخدمه.

ربما تعلمت نمطًا أفضل، أو أصبحت ترى تعقيدًا لم تكن تراه سابقًا.

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

أخطر لحظة هي أن تبدأ إعادة الهيكلة قبل أن تستعيد سبب السلوك الحالي.

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

قيدًا كان موجودًا عند الاختيار.

كذلك لا تخلط بين غرابة الكود وتغير البيئة.

مشروع توقف بعد تحديث مكتبة يملك مشكلة مختلفة عن مشروع يعمل كما كان لكنك

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

ابدأ بتغيير صغير مرتبط بمهمتك، وشغل السلوك الذي تريد حمايته، واقرأ التاريخ القريب، ثم حسن

 الجزء الذي أصبحت تفهمه.

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

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

وضوح الشكل لا يساوي وضوح القرار.

استخدم بوابة استعادة سياق الكود قبل أن تعدله

عندما تعود إلى مشروع قديم، مرر الجزء الذي ستغيره عبر خمس نقاط.

الأولى السلوك، ما النتيجة الحالية التي يعتمد عليها النظام أو المستخدم.

الثانية المسار، ما الملفات والمكونات التي تشارك فعلًا في إنتاج هذه النتيجة.

الثالثة السبب، ما القرارات أو القيود غير الظاهرة التي تفسر وجود الأجزاء غير المألوفة.

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

الخامسة التغيير، ما أصغر تعديل يحقق هدفك ويحافظ على السلوك الذي لم تقصد تغييره.

إذا لم تعرف السبب بعد، لا تجعل عدم إعجابك بالشكل مبررًا للحذف.

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

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

وبعد أن تنتهي، اترك نسخة مستقبلك في وضع أفضل قليلًا.

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

الكود القديم لن يصبح مألوفًا إلى الأبد، ولا تحتاج إلى أن تتذكره كله.

الهدف أن يستطيع المشروع مساعدتك على إعادة فهمه من دون اعتماد على ذاكرة الشخص 

الذي كتبه، حتى لو كان ذلك الشخص هو أنت.