تعتبر الوظيفة الأولى كمهندس برمجيات واحدة من أكثر اللحظات إثارة وإرهاقًا في حياتك المهنية. بيئة العمل لا تشبه الجامعة. إنه عندما تتحسن أكثر وأسرع لأن لديك أكبر قدر من الخبرة والمعرفة لتكتسبه. هناك الكثير من الأشياء التي أود أن أعرفها عندما بدأت العمل ، وهنا 10 منها (بالإضافة إلى القليل من المكافآت في النهاية).
1. خذ وقتك لتحليل المشكلة
تحصل على مهمة جديدة. تعتقد أنك تفهمها على الفور. تحصل على كتابة التعليمات البرمجية.
يبدوا مألوفا؟ إذا كانت الإجابة بنعم ، فأنت بحاجة إلى قضاء وقتك في تحليل المهمة. عندما تعتقد أنك تفهم المشكلة ، فكر في الأمر مرة أخرى. أحيانًا يكون من المغري الوصول إلى الكود فورًا (إنه الجزء الممتع بعد كل شيء ، أليس كذلك؟) وتقديم الحل الخاص بك في وقت قياسي ، ولكن في كثير من الأحيان سيتم ترجمته إلى المزيد من العمل على المدى الطويل عندما تظهر أشياء صغيرة غير متوقعة. لذلك ، خذ وقتك في تصفح الأقسام المتضمنة من التعليمات البرمجية والتي تتضمن كل وظيفة. بعد ذلك يمكنك صياغة حل تعليمي يغطي جميع الزوايا.
2. فكر في حالات الحافة
إذن ، ما هي حالة الحافة؟ بحسب ويكيبيديا:
في البرمجة ، تتضمن حالة الحافة عادةً قيم إدخال تتطلب معالجة خاصة في خوارزمية خلف برنامج كمبيوتر.
هذا يعني التفكير في أي مدخلات محتملة حتى تتمكن من التعامل معها جميعًا. عندما لا تؤخذ حالات الحافة في الاعتبار ، تولد الحشرات. ما الذي يأخذني إلى نقطتي التالية:
3. تعلم اختبار الوحدة ومفهوم تغطية الكود
أعلم أن اختبار الوحدة يمكن أن يكون مملًا جدًا. لكن صدقني ، يمكن أن يكون أيضًا أفضل صديق لك. لم يكن هناك اختبار للوحدة في وظيفتي الأولى ، لذا لم أتعلم عنها إلا عندما انتقلت إلى منصب آخر (خطئي ، كان ينبغي أن أهتم به في وقت سابق). يمكنني أن أؤكد لكم ، أن الأخطاء التي ظهرت بشكل أقل بكثير في تلك التي تتطلب تغطية كود بنسبة 80٪.
في علوم الكمبيوتر ، تعد تغطية الاختبار مقياسًا (بالنسبة المئوية) لدرجة تنفيذ الكود المصدري للبرنامج عند تشغيل مجموعة اختبار معينة.
ويكيبيديا
من خلال اختبار الوحدة ، فأنت لا تتحقق فقط من أن الكود الخاص بك يعمل ويقدم الحل المتوقع وكل حالة طرفية يمكنك التفكير فيها ، ولكنه يؤكد أيضًا أنك لا تفسد شيئًا آخر دون أن تلاحظه في المستقبل.
4. فحص كل وظيفة
يمكن القول أنك تتعلم البرمجة أكثر من خلال القراءة بدلاً من الكتابة. عند العمل في مهمة (إذا سمحت لك الأوقات بذلك) ، تأكد من فهم كل سطر صغير من التعليمات البرمجية ، ولا تفكر فقط "هذه الوظيفة هنا تفعل هذا الشيء وهذا هو المهم". انتقل إلى الوظيفة ، واقرأ كل سطر وبهذه الطريقة تتعلم كيفية حل المشكلات. صدقني ، عندما بدأت تعلم البرمجة لأول مرة ، انتبهت فقط لما تفعله الأشياء بدلاً من كيف تفعل الأشياء ما تفعله ، وعندما بدأت في أخذ وقتي في استعراض كل شيء ، نمت معرفتي بشكل كبير. حتى بدون إشعار ، يبدأ دماغك في اكتشاف المشكلات الشائعة والحلول.
5. اطلب المساعدة (ومراجعات الكود) ، فمهندسو البرمجيات يحبون مساعدة الآخرين
قد تكون خبرتي التجريبية فقط ، لكن مهندسي البرمجيات يحبون مشاركة المعرفة ومساعدة الآخرين. كدليل ، فكر في جميع الأسئلة والأجوبة التي لدى Stack Overflow. لا تخف من طرح الأسئلة ، حتى لو كانت تبدو سخيفة. لقد كنا جميعًا هناك ولن يحكم عليك زملاؤك على ذلك. السؤال الغبي الوحيد هو السؤال الذي لا تطرحه.
الشيء نفسه ينطبق على مراجعات الكود. يعد الحصول على مهندسي برمجيات آخرين لقراءة التعليمات البرمجية الخاصة بك وإعطائك ملاحظات طريقة رائعة للتعلم ، لأنك ستكتسب نظرة ثاقبة بطرق مختلفة لتحقيق نفس النتيجة ، ناهيك عن الأخطاء التي ربما تكون قد أغفلتها.
6. كلنا نحب الممارسة ، لكن لا تنس النظرية
كمهندسي برمجيات ، فإن أكثر ما نستمتع به في حياتنا المهنية هو الترميز. حل المشكلات المعقدة باستخدام بعض سطور التعليمات البرمجية الملونة المميزة على لوحة قماشية سوداء. لذلك من السهل التغاضي عن النظرية. وأنا لا أتحدث عن نظرية حسابية متشددة ، ولكن أشبه بأنماط التصميم ، ومبادئ التصميم ، والخوارزميات الشائعة ، تحصل على الصورة. تعرف على أنماط التصميم والنمط المضاد (كيف ينبغي حل المشكلات الشائعة بسهولة وكيف لا ينبغي) ، ومبادئ التصميم والتطوير مثل TDD و KISS و SOLID و DRY و YAGNI ؛ تدوين Big O وتعقيد الخوارزمية الشائعة ، واستمر في ذلك. ستجعل النظرية حياتك كمهندس برمجيات أسهل وأكثر مرونة وحسن الإدارة واحترافية.
7. راجع كود الآخرين
من المهم مراجعة شفرتك ، ولكن مراجعة كود الآخرين مهمة أيضًا. كما هو الحال مع مراجعة الكود الخاص بك ، ستتعلم طرقًا مختلفة لحل المشكلات المختلفة ، وستحصل على نظرة ثاقبة حول المشكلة التي تحلها الكود والمكتبات التي لم تكن تعرفها. قد يكون الأمر صعبًا في بعض الأحيان وربما يكون نوعًا من العملية البطيئة حتى تحصل على الصورة الأكبر ، وتحصل على ما يفعله الكود وما يحاول مهندس البرنامج الذي تقوم بمراجعته تحقيقه ، ولكن لا يزال يستحق ذلك كثيرًا.
8. لا تحاول أن تجعل كل شيء بطيئًا واحدًا
تبدأ في تعلم البرمجة وتبدأ في التفكير في أنك تنشئ أساسًا قويًا ، ثم تقرر البدء في حل مشكلات Code Wars (ربما للتعلم أو التدريب أو للمتعة فقط). أنت تعمل من خلال تمرينك الأول ، وتحصل على حل جيد تفخر به وقمت بإرساله لتكتشف فقط أن 37 شخصًا استبدلوا 14 سطرًا من التعليمات البرمجية بخط واحد. بطبيعة الحال ، تبدأ في التساؤل عن مدى قوة مؤسستك وتفكر في كل الأشياء التي لا يزال عليك تعلمها. نعم ، لديك الكثير لتتعلمه ، لكن ربما لا تكون إحدى الخطوط واحدة منهم.
يبدو رمز سطر واحد رائعًا في البداية. تعتقد أنه يحدد كفاءة لغوية لا تضاهى لن تحصل عليها أبدًا. ولكن في العالم الاحترافي ، وإذا كنت لا تصدقني سألت أقرب مهندس كبير لك ، فإن كود الخطوط الواحد يصنع كودًا فظيعًا. إنها بطيئة في القراءة وبطيئة في الفهم ومعقدة غير ضرورية. إذا كان بإمكانك تحقيق نفس النتيجة ببعض الأسطر الإضافية من التعليمات البرمجية ولكن جعلها أكثر قابلية للقراءة للشخص التالي ، فمن المحتمل أن تكون شفرة أفضل. ما لم تكن تعمل بمفردك ، ونادرًا ما تكون كذلك ، فهناك احتمالات في المرة التالية التي تتم فيها قراءة التعليمات البرمجية الخاصة بك ، فلن تكون بواسطتك.
9. في حاجة إليها مرتين؟ اجعلها وظيفة
يتماشى هذا مع مبدأ التصميم DRY الذي اقترحت التعرف عليه في القسم 6. يرمز DRY إلى "لا تكرر نفسك" ، وهذا يعني أنه إذا كنت بحاجة إلى كتابة نفس الرمز مرتين ، فمن الأفضل جعله وظيفة لذلك يظل قابلاً لإعادة الاستخدام في المستقبل ويحافظ على نظافة شفرتك.
10. تعلم أدواتك
نعم ، أنا أتحدث عن الأداة الرئيسية لمهندس البرمجيات: IDE / محرر النصوص. سواء كنت تستخدم بيئة تطوير متكاملة JetBrain كاملة أو كنت تفضل الذهاب إلى المتشددين وتخصيص Vim حسب ذوقك ، خذ وقتك لتعلم أدواتك بعمق. خطأ في التمييز ، إعادة البناء ، إعادة التسمية ، الاستبدال ، البحث ... وتستمر القائمة. لا يمكنك حتى تخيل مقدار الإنتاجية التي يمكن أن تجعلك معرفة IDE / محرر النصوص الخاص بك.
قسم المكافآت: تعلم واعتماد واستيعاب اختصارات Vim.
على محمل الجد ، لا تقلل من إنتاجية تعلم اختصارات فيم. لا بأس إذا كنت لا تحب الترميز في الجهاز الطرفي ، لأن معظم محرري النصوص / IDEs لديهم مكونات إضافية Vim. باختصار ، يحتوي على ثلاثة أوضاع ، الوضع العادي (المعروف أيضًا باسم وضع الأوامر) ، وضع الإدراج والوضع المرئي. في وضع الإدراج ، خمنت ، يمكنك إدراج نص ؛ في الوضع المرئي ، تقوم بتمييز النص وعندما تكون في الوضع العادي ، يمكنك التنقل في التعليمات البرمجية بأحرف (h ، j ، k ، l) وتقوم مفاتيح مختلفة بتنفيذ إجراءات مختلفة. على سبيل المثال ، يمكنك إزالة سطر به dd ، وكلمة بها dw ، وتحريك كلمة إلى الأمام باستخدام w ، وإعادة كلمة مع b ، والتراجع عن تغيير باستخدام u ، وتحصل على الصورة. يمكنك التنقل في الكود بضربات قليلة على المفاتيح ، واستبدال كل التعليمات البرمجية الموجودة داخل حرف معين ، واستبدال كلمة أو عدد من الكلمات ، أو الأسطر ، أو الفقرات ، أو سمها ما شئت. وهذا مجرد غيض من فيض.
لن أكذب عليك ، فمن الصعب في البداية وسيستغرق الأمر بعض الوقت لتعتاد على ذلك ، لكن تخيل السرعة التي يمكنك تحقيقها إذا كانت أفعالك على بُعد ضغطة واحدة أو اثنتين من المفاتيح. ولا يقتصر الأمر على التنقل في التعليمات البرمجية ، بل يمكنك أيضًا تبديل الملفات دون الخروج من لوحة المفاتيح. يتيح لك البرمجة بدون استخدام الماوس إلى حد كبير (لنكن صادقين ، حلم المبرمج). من الجيد جدًا أنك عندما استوعبتها ، فاتتك عندما لا تكون لديك (على سبيل المثال كتابة مستند) وهذا هو السبب في أنني الآن أستخدم Vim كمحرر نصي رئيسي لكل شيء خارج الترميز أيضًا.
آمل أن تكون هذه النصائح مفيدة لك وأتمنى لكم جميعًا حياة مهنية سعيدة وسعيدة!