هذا ما تعلمته بعد تسعة أشهر من عملي في هندسة البرمجيات

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

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

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

اطرح الكثير من الأسئلة وقم بتوثيق الإجابات

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

أستخدم قائمة التحقق هذه قبل طلب المساعدة من الآخرين:

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

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

إذا قطعت 90٪ من الطريق نحو حل المشكلة واحتجت فقط إلى آخر 10٪ من المساعدة ، فسيكون من دواعي سرور أحد كبار المطورين أن يساعدني في معرفة أنني وصلت إلى أبعد ما أستطيع بمفردي. البحث عن شخص آخر لحل مشاكلك ليس طريقة رائعة لبناء الثقة داخل فريقك.

الأشخاص الأذكياء يحبون الأسئلة الجيدة - لذا اسألهم.

تجنب ارتكاب نفس الأخطاء وطرح نفس الأسئلة مرارًا وتكرارًا

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

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

مراجعة عملك دائما

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

انظر حقًا إلى الكود واسأل نفسك هذه الأسئلة:

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

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

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

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

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

على محمل الجد ، لا تريد أن ترى المسودة الأولى من منشور المدونة هذا :)

لا شيء سحر

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

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

احصل على تصحيح أخطاء مريح ، نظرًا لأنك تفعل ذلك كثيرًا

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

بعض الموارد المفيدة التي وجدتها:

  • حيل CSS على التصحيح
  • تصحيح أخطاء الواجهة الأمامية للماجستير (مدفوع ولكنه جيد جدًا)

نصيحة احترافية : يمكن تنسيق إخراج console.log باستخدام CSS. هذا يجعل السجل الذي تريد رؤيته أسهل في التعرف عليه.

console.log('%c I want this to be big and red', 'font-size: 30px; color: red;');

اتبع البيانات

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

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

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

اعزل مشاكلك ثم ادمجها فيما تعمل عليه

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

فكر في كيفية عمل الوظيفة

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

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

احتضان الكفاح

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

خذ النقد البناء وكرره باستمرار

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

خذ وقتك

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

استمر في التعلم خارج العمل

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