كنت أرغب في الدخول في التطوير لفترة طويلة ، لكن كما يحدث غالبًا ، لم أكن أؤمن بنفسي حقًا. اعتقدت أن قطاري قد انتهى منذ فترة طويلة ، ولم تعد العقول قادرة على إتقان هذه المهنة الصعبة. لحسن الحظ ، تم إقناعي ، علاوة على ذلك ، أنهم منحوني فرصة لإثبات نفسي وحصلوا على تدريب داخلي في قسم التطوير. لقد حدث ذلك بطريقة عرضية وببساطة لدرجة أنني لم أصدق ذلك في البداية. طوال الوقت بدا لي أن الجميع الآن يفهمون أخيرًا أنني كنت جاهلًا وألوح وداعًا بقلمهم. لكن هذا لم يحدث ، لقد استمروا في دعمي ، وبذلت قصارى جهدي حتى لا يخذل أحدًا.
أنا متدرب في قسم الخلفية لدينا ، والذي يتعامل مع تتبع المنتجات ، وفي نفس الوقت أعمل في قسم التكامل التقني الخاص بي (لمدة 6 أشهر الآن). اللغة الرئيسية في الفريق هي بايثون . لقد قمت بتدريسها بمفردي للحصول على تدريب. في الأساس ، بالطبع ، على الكتيبات ومقاطع الفيديو على الإنترنت.
كان لدي قاعدة صغيرة - لقد كتبت العديد من المشاريع التدريبية في C ، لكن بشكل عام لا أستطيع أن أقول إنني كنت على الأقل مبرمجًا ذا خبرة إلى حد ما عندما تم قبولي في فترة تدريب. من ذروة هذه التجربة المتواضعة ، أود أن أخبركم عن شيئين لم أكن أعرفهما أو بالكاد أعرفهما في البداية.
العمل الجماعي مع Git
عندما يأتي شخص ما إلى تدريبه الأول ، فإنه يتخيل ماهية Git (وإلا فمن غير المرجح أن يتم أخذه على الإطلاق) ، لكن لديه فكرة قليلة عن كيفية عملهم معه في فريق. لقد أنشأنا جميعًا حسابًا على GitHub في وقت واحد وسعدنا بتخصيص السطر الأول من التعليمات البرمجية إلى الفرع الرئيسي ، وشعرنا وكأننا محترفون حقيقيون. إذن: هذا ليس أفضل نهج للمشاريع الكبيرة.
في تطوير الفريق ، يتم تنفيذ العمل مع Git وفقًا لتدفق git المعتمد . على سبيل المثال ، لدينا فرعين: التطوير والإتقان. لا أحد ، باستثناء قائد الفريق ، يمكنه تحميل الكود إلى الفرع الرئيسي ، لأنه يجب على الفريق التأكد من وجود كود عمل هناك لن يدمر الإنتاج عند نشره. مسؤولية ذلك تقع على كاهل قائد الفريق ولا أحد يريد أن يغضب قائد الفريق.
لمنع مثل هذه المواقف ، هناك مراجعة الفريق. يعمل كل مطور على مهمة في فرعه الخاص وفي نهاية العمل يضع طلب دمج في فرع التطوير. ويقوم قائد الفريق بالفعل بوضع طلب الدمج في الفرع الرئيسي ويكون مسؤولاً عن جودة الكود لمالكه. وبالتالي ، فإن نقاء الكود الذي ينتهي به الإنتاج مضمون ، وتقليل مخاطر صب شيء من شأنه إفساد عمل المشروع.
فائدة: إذا كنت ترغب في الاستعداد بشكل أفضل للعمل الجماعي ، فاقرأ عن git-flow وابدأ في إضافة التزامات جديدة إلى مشروعك المفضل عبر الفروع.
بنية الكود مهمة
عندما جئت إلى التدريب ، توقعت أنهم سيخبرونني ماذا أفعل ، ويعطون بعض الوظائف الصغيرة أو اختبارات الوحدة ، وسأعمل عليها تحت إشراف الفريق.
ومع ذلك ، تحول كل شيء بشكل مختلف. لا ، لم يوجهني أحد للقيام بشيء شديد التعقيد ، لكن تم تكليفي بمشروع صغير (علامة فارقة) للمراقبة (Python + Prometheus + Grafana ) ، وهو ما اضطررت للقيام به أثناء فترة التدريب. علاوة على ذلك ، كان عليّ أن أفكر بنفسي في البنية ، وأحلل المشروع إلى مهام وأنقله عبر مراحل كانبان. كانت مثيرة ، لكنها صحيحة للغاية. سمح هذا النهج أنا وأميني أن نفهم بوضوح ما هي مشاكلي وأن نبدأ في إصلاحها.
بصراحة ، كان قراري الأول غير ناجح. والثاني أيضًا. لقد قمت بمهام كانت كبيرة جدًا ، وأعدتها إلى الأعمال المتراكمة عدة مرات ، وأنشأت بنية غير ناجحة ولم أتمكن من مراعاة الفروق الدقيقة.
ومع ذلك ، في الوقت الحالي ، تم بالفعل تنفيذ معظم المشروع ، وأصبحت أكثر وعيًا بكيفية تأثير الكود الخاص بي على بقية المشروع. انها مثيرة. قرأت العديد من المقالات حول العمارة النظيفة ، ودرست فصولًا مجردة ، وتعلمت كيفية التخطيط للواجهة أولاً وبعد ذلك فقط ابدأ التنفيذ. لا أستطيع أن أقول إنني فهمت الأمر برمته ، لكنني فهمت بالتأكيد عبارة "يمكن حل أي مشكلة من خلال تقديم مستوى إضافي من التجريد ، باستثناء مشكلة العدد المفرط من مستويات التجريد." وتعلمت أيضًا كيفية تقييم قوتي بشكل صحيح (لكن هذا ليس دقيقًا).
: . , , . , Netflix, . , .
في شركتنا ، يتم إطلاق جميع الخدمات في حاويات. وفقًا لذلك ، يجب على كل مطور فهم كيفية عمل Docker نفسه ، وكيفية كتابة Dockerfile بسيط ، أو رفع خدماتهم من خلال Docker Compose .
بالنسبة للشخص الذي يكتب فقط لنفسه وعلى جهاز الكمبيوتر الخاص به ، من الصعب فهم سبب الحاجة إلى استخدام الحاويات. ومع ذلك ، في المشاريع الكبيرة ، من الضروري التأكد من أن الكود يعمل بغض النظر عن البيئة. بعد ذلك بقليل ، عندما تكتشف الأساسيات ، سيصبح من الواضح مدى ملاءمتها. لست بحاجة إلى تثبيت التبعيات في بيئتك ، فلا داعي لإطلاق مشروع طويل وصعب. يمكنك إجراء اختبارات أو فصل pro و dev من خلال كتابة بضعة تكوينات مرة واحدة.
يمكن أن تتضمن نفس النصيحة العمل مع IDE. قبل أن أبدأ التدريب ، كتبت جميع برامجي حصريًا في Emacs ، لكن عندما بدأت العمل ، قررت التحول إلى أداة أكثر تقدمًا ، وفي النهاية لم أندم على ذلك. في بعض الأماكن ، ما زلت أفضل استخدام وحدة التحكم (على سبيل المثال ، من الأنسب حذف جميع الحاويات من خلالها
docker stop $(docker ps -qa)) ، ولكن بخلاف ذلك ، أنا ممتن لـ Git GUI والنصائح في PyCharm.
الخلاصة: اقرأ عن Docker. حاول تشغيل التعليمات البرمجية الخاصة بك في حاوية. جرب IDE للغة الخاصة بك وشاهد ما يمكن أن يفعله لك.
التوثيق والاختبارات لا تقل أهمية عن الكود
قال أمين المعرض ذات مرة أن الاختبارات هي وثائق المطور الثاني. وهذا صحيح جدًا ، لأنه في حالة عدم توفر التوثيق الفعلي ، يمكنك دائمًا الدخول في الاختبارات ومعرفة السلوك المتوقع.
قبل فترة التدريب ، استخدمت UnitTest و PyTest ، ولكن فقط كجزء من تدريبي. و Mock ، على سبيل المثال ، لم تستخدم على الإطلاق ، لأن مشاريعي لم تكن معقدة لدرجة أنه كان من الضروري استبدال البيانات (حسنًا ، أو كانت اختباراتي سيئة للغاية).
أوصي جميع المطورين المبتدئين بكتابة اختبارات لجميع المنطق الذي يحدث في المشروع. حتى لو كنت تعتقد أن السلوك واضح ، فمن الأفضل أن تلعبه بأمان. بعد كل شيء ، عندما يكتب شخص آخر وظيفة تستخدم الكود الخاص بك ، فهناك احتمال ألا يخوض في التفاصيل وأن اختبارك الفاشل هو الذي سيوفر المشروع من المتاعب.
ولتقليل المخاطر بشكل أكبر ، اكتب وثائق واضحة. في Admitad ، ستثير طريقة أو وظيفة بدون وثائق أسئلة للمراجعة. بعد أسبوعين ، لا أحد يريد إضاعة الوقت في محاولة اكتشاف رمز شخص آخر مرة أخرى. إنها مجرد مسألة احترام للزملاء.
بالإضافة إلى ذلك ، سأقول إننا نعلق أيضًا على الأنواع في بايثون بالتفصيل ، ولكن إذا كتبت بلغة مكتوبة بشدة ، فهذا التعليق ليس لك. (استخدام لينتر مثل Flake8 يساعد كثيرًا في هذا الصدد ).
الخلاصة: انتبه للاختبارات والتوثيق. ابدأ ببرنامج Git التمهيدي المعتاد - صف كيفية تشغيل المشروع ، وماذا يفعل ، وما تتوقعه. جرب كتابة اختبارات للطرق والوظائف الرئيسية ، أو الأفضل من ذلك ، قم بعمل Docker Compose الذي يدير جميع الاختبارات.
ما هي الخبرة التي لديك؟
بالنسبة للمطورين الراسخين ، قد تبدو نصيحتي تافهة وواضحة. أفهمك جيدًا ، لكن في البداية كنت أفتقر بشدة إلى معرفة النظام. أنا متأكد من أن العديد من أولئك الذين أتقنوا المهنة بأنفسهم واجهوا هذه المشكلة.
لذلك ، أشجعك على مشاركة الخبرات والملاحظات التي تعلمتها بعد الأشهر (أو السنوات) الأولى في الصناعة. ما هي النصيحة التي تعطيها لنفسك في بداية حياتك المهنية؟ ما هي المهارات التي تنصح بتطويرها؟ قد أحتاج أنا والأشخاص الآخرين من العصاميين إلى نصائحك ، لذا لا تتردد في ترك تعليقات.