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

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

قضيت سنة بجانب مبرمج رائد. هذا ما تعلمته.

محتوى

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

كتابة التعليمات البرمجية

كيفية تسمية الأشياء في التعليمات البرمجية

واحدة من أولى مهامي كانت العمل على React UI. كان لدينا مكون رئيسي يحتوي على جميع المكونات الأخرى. أحب أن أضيف القليل من الفكاهة إلى الكود ، وأردت تسمية المكون الرئيسي لـ GodComponent . لقد حان الوقت لمراجعة الرمز ، وفهمت سبب صعوبة تحديد الأسماء.


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

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

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

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

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

من وجهة النظر هذه ، فإن وظائف التسمية مثل x و y و z بدلاً من count() ، close() ، insertIntoDB() لا تسمح لنا بوضع معنى معين فيها insertIntoDB() بعناية ما تفعله هذه الوظائف. ²

لم أكن أعتقد أنني سأكتب عن مبادئ تسمية أكثر من سطر واحد من النص.

موروثة الكود والمطور القادم

هل سبق لك أن نظرت إلى الكود ويبدو لك غريباً؟ لماذا كتبت ذلك؟ هذا لا معنى له.

أتيحت لي فرصة للعمل مع قاعدة الشفرة الموروثة. هذا ، كما تعلمون ، بتعليقات مثل "فك الضغط عن الكود عندما يفهم محمد الموقف". ماذا تفعل هنا؟ من هو محمد؟

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

إذا نسيت هذا الرمز ، عدت إليه لاحقًا ولا أستطيع استعادة السياق ، سأقول: "ماذا فعلوا بحق الجحيم؟ هذا غبي ... آه ، انتظر ، لقد فعلت ذلك. "

وهنا الوثائق والتعليقات في الكود تدخل حيز التنفيذ.

الوثائق والتعليقات في التعليمات البرمجية

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

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

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

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

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

يرتكب الذري

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

كيفية بثقة حذف رمز رديء

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

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

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

مراجعة الكود

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

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

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


إحصائيات جيثب بلدي.

تجريب

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

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

الاختبارات والأتمتة اختبار مساعدة هنا.

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

اليوم ، عندما أكتب الاختبارات ، أحاول:

1. أظهر كيفية استخدام فئة الاختبار أو الوظيفة أو النظام.
   
2. أظهر ما ، في رأيي ، قد يحدث خطأ.
   

كنتيجة لذلك ، غالبًا ما أختبر السلوك ، ولكن ليس التنفيذ ( هنا مثال اخترته خلال فترات الاستراحة في Google).

في الفقرة 2 ، لم أذكر مصادر الخلل.

عندما لاحظت خللًا ، أتأكد من أن الإصلاح يحتوي على اختبار مناسب (يسمى اختبار الانحدار) لتوثيق المعلومات. هذا سبب آخر لحدوث خطأ ما. ⁵

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

هذا هو الوضع العام مع الاختبار.

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



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

• هناك آلات تقوم بتطويرها (مصدر جميع الميمات مثل "لقد عملت على جهاز الكمبيوتر الخاص بي!").
  
• هناك آلات تقوم باختبارها (قد تتزامن مع الأجهزة السابقة).
  
• أخيرًا ، هناك آلات تقوم بنشرها (يجب ألا تتزامن مع الأجهزة التي طورتها).
  

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

نحن نقوم بالتطوير المحلي في Docker على جهاز الكمبيوتر الخاص بنا.

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

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

يمكنك تكوين مجموعات فردية للتطوير والتشغيل. يستخدم AWS ECS صور Docker لنشرها ، لذلك ستكون العمليات في بيئات مختلفة متسقة نسبيًا. هناك فروق دقيقة من حيث التكامل بين خدمات AWS المختلفة. هل تتصل بنقطة النهاية الصحيحة من البيئة المناسبة؟

يمكنك الانتقال إلى أبعد من ذلك: قم بتنزيل صور حاوية بديلة لخدمات AWS الأخرى وتكوين بيئة محلية كاملة الوظائف تعمل بنظام Docker-Compose. هذا يسرع حلقة ردود الفعل. ⁶ ربما أكسب المزيد من الخبرة عندما أقوم بإنشاء مشروع جانبي وإطلاقه.

الحد من المخاطر

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

هندسة معمارية

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

تحتاج إلى التفكير كثيرًا عند إنشاء بنية.

• كيف سيتم استخدام الأرقام؟
  
• كم عدد المستخدمين سيكون هناك؟ كم يمكن أن يزيد عددهم (يعتمد عدد الصفوف في قاعدة البيانات على هذا)؟
  
• ما الشعاب يمكن أن تلبي؟
  

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

• كيف ستسير التنمية المحلية؟
  
• كيف سنقوم بحزم ونشر؟
  
• كيف سنجري اختبارات شاملة؟
  
• كيف سنجري اختبار الإجهاد للخدمة الجديدة؟
  
• كيف سنحتفظ بالأسرار؟
  
• التكامل CI / CD؟
  

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

من كان يظن أن نشر الأسرار إلى همز يمكن أن يكون غير تافه للغاية:

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

نحن لا نريد أن نفعل كل شيء يدويا.

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

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

نخلق الهندسة المعمارية ، لا ننسى الصيانة

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

أعرف ثلاث طرق على الأقل لتقليل معدل التدهور.

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

نشر

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

• النشر يستغرق الكثير من الوقت؟
  
• هل مراجعة الكود ليست ممتعة للغاية؟
  

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

1. أنت نفسك تحظر جميع الميزات إذا كان أحدها لديه خطأ.
   
2. أنت تزيد من خطر المشاكل.
   

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

عندما يحدث خطأ ما

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

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

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

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

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

لقد اعتقدنا أن nginx قد تم تثبيته بشكل غير صحيح ، لكن اتضح أنه تم تعطيل التكوين فقط

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

البيز نسيج أخضر تكسى به موائد البليارد

هذه المقالة لا يمكن أن تكتمل بدون قصة. , . SQLAlchemy. BNEF , . . SQLAlchemy, , Solr. - .

«MYSQL server has gone away.» . , , . , . , . , ?

, ? , , . , , __exit__() session.close() .

, , . . . . .

Session.close() MySQL- SQLAlchemy , NullPool. . , , . : StackOverflow (, !) , , SQL- . , . , , (), .

«» , 1 8. , , — .

, .

, . , , . , .

, , , . , . , . « ?! , ? ".

, : , . , , . , , . , . — ? , , . . , -, , , , , .. .

. , , ? (, AWS CloudWatch Grafana). .

. , , 50 %, — . ? . , — (, ?).

. , , , , ? ? , ?

, . , . — - .

استنتاج

. , , , . , - !

. , !

, . , — How to Build Good Software .

. : ! , .

1. ?
   
2. ? , ? , ?
   
3. . , ? ?
   
4. (utils) (, , , ) , « »?
   
5. ?
   
6. , , - ?
   
7. — API , ?
   
8. ? , .
   
9. , , . , , .
   
10. PR: « , , 52 , , , , , ». ?
    
11. . ?
    
12. ?
    
13. ?
    

الملاحظات

1. . , ? - ? , ?
   
2. , x() , y() z(), x() , y() z() . , WYSIATI .
   
3. .
   
4. . , ?
   
5. , - , , . , .
   
6. , , Docker- AWS.
   
7. .