تخطَّ إلى المحتوى

ورثت للتو شيفرة Laravel. اقرأها بهذا الترتيب.

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

قراءة 3 دقيقة

رحل أحدهم، أو اشتُريت شركة، أو انتهت علاقة مع وكالة. هناك مستودع، ووصول إلى الإنتاج، وسؤال عن كم سيستغرق شيء ما.

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

هذا هو الترتيب الذي ينجح.

١. المخطط، قبل أي PHP

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

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

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

٢. المهام، لأن المخاطرة تعيش هناك

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

اقرأ كل صنف مهمة. واسأل عن كل واحدة: ماذا يحدث إن نُفِّذت مرتين، لأن كل واحدة منها ستُنفَّذ كذلك في وقت ما. ثم انظر إلى جدول المهام الفاشلة في الإنتاج واعرف أيّها يفشل فعلًا، وكم مرة، وهل ينظر أحد.

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

٣. النشر، لأنه يخبرك بما تستطيع تغييره

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

أنت تبحث عن إجابات محددة: هل تعمل الهجرات تلقائيًا، وهل يُعاد تشغيل عمّال الطوابير، وهل هناك رجوع، وهل استخدمه أحد. الإجابات تقرر كم يمكن أن يكون أول تغيير لك جريئًا.

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

٤. Composer، للاعتماديات التي رحلت

composer outdated --direct

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

تحقق من إصدارَي Laravel وPHP اللذين يعمل بهما التطبيق، وهل أيّهما ما زال يتلقى إصلاحات أمنية. تلك الحقيقة وحدها تعيد ترتيب كل خطة.

٥. الإنتاج، لما يحدث فعلًا

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

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

٦. تاريخ git، أخيرًا وبفائدة

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

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

ما لا تفعله في الأسبوعين الأولين

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

لا تصلح ما يبدو خاطئًا. في اليوم الرابع تبدو الشيفرة غير المعتادة خطأً. وفي اليوم العشرين يتبين أن نصفها قاعدة تعلّمها أحدهم بالطريق الصعب.

لا تعطِ رقمًا حتى تنتهي. التقدير الذي يريده الجميع في اليوم الأول هو الذي سيُقتبس في وجهك في الشهر الثالث.

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

أسئلة ذات صلة

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

← العودة إلى كل المقالات

اتصل بنا+1 848 272 7583واتساب+90 850 308 5436البريدinfo@codefacture.comصفحة التواصل