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

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

ربما سيجد الصغار الحاليون بعض معتقداتهم وينظرون إليها من الجانب الآخر. أو أنهم يدركون أنهم تخلصوا بالفعل من هذا ، لذا فقد ذهبوا أبعد مما كنت عليه في مرحلتكم.

قد يرغب كبار السن الحاليين أيضًا في مشاركة قصص مضحكة (ومهينة قليلاً) حول الدروس المستفادة من تجربتهم المبتدئة.

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

آمل أن تستمتع المنشور وأن أذكرك بشيء من الماضي أو الحاضر.

شكرا ل Artyom وسارة لردود الفعل!

الحقائق المطلقة للناشئين التي كان من الضروري التخلي عنها

1. أنا مطور كبير

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

منذ ذلك الحين كنت أقوم بترميزها لعدة سنوات في غرفة نومي ، كنت متأكدًا من أن هذه السنوات تعتبر "سنوات من الخبرة". لذلك ، عندما سئل عن مقدار الخبرة التي كتبتها في PHP ، أجبت بثقة: "3 أو 4 سنوات!"

اعتقدت أنني كنت أعرف الكثير عن SQL لأنني أستطيع أن أقوم بوصلات خارجية (وصلات خارجية).

وعندما غوغل ، اكتشفت أن خبرة ثلاث إلى أربع سنوات تعني الكثير من المال.

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

لذلك أصبحت مطورًا أقدم في سن 24 عامًا.

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

تماما مثل رئيسه.

ماذا فهمت أخيرا

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

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

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

2. الجميع يكتب الاختبارات

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

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

لأنه ... حسنًا ، إنه مجاني.

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

باختصار ، لقد تركت المعهد بتوقعات كبيرة.

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

جلالة الملك ...

تخيل دهشتي عندما لم أجد أي اختبارات في يوم العمل الأول في بدء التشغيل. لا اختبارات في الواجهة. لا اختبارات في الخلفية. لا اختبارات على الإطلاق.

نعم. لا تهتم. الصفر. نان. الاختبارات مفقودة كظاهرة.

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

ولكن ليس لأن الناس لا يعرفون كيفية كتابتهم.

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

ماذا فهمت أخيرا

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

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

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

3. نحن وراء هذا الباقي (ويعرف أيضًا باسم الإصدار الفني لمتلازمة الربح المفقود )

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

قرأت مجموعة من التدوينات. شاهدت الكثير من خطب المؤتمرات على موقع يوتيوب. تبا ، قرأت "هذا الموقع البرتقالي" في كل وقت [ربما في اشارة الى هاكر نيوز - تقريبا. العابرة.]. يبدو أن الجميع يكتبون تطبيقات فائقة التطور وعالية الجودة مع أداء رائع ورسوم متحركة عصرية ، بينما أقوم فقط بعمل تصحيحات تحاول اللحاق بالموعد النهائي.

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

ماذا فهمت أخيرا

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

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

4. جودة الكود مهم جدا.

في الأيام الخوالي ، كان بإمكاني القيام بمراجعة رمز صارمة للغاية

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

أرسل أكثر من 50 تعليقًا لطلب السحب الذي يسرد جميع الفواصل المنقوطة التي فاتتك!

لأن لدي عيون مثل النسر - وهذا النسر يريد الحصول على كل فواصل منقوطة عالية الجودة!

(لحسن الحظ ، بعد سنوات عديدة من العمل على الكمبيوتر ، اختفت رؤية مثل النسر ، لذا ليس لديك الآن ما يدعو للقلق - # نكت مضحكة)

ماذا فهمت أخيرا

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

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

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

5. يجب توثيق كل شيء !!!

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

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

لذلك ، كيف تعاملت مع حقيقة أن 300 سطر من الشفرة غير المألوفة جعلتني أشعر أنني غرق؟

JSDOC. في كل مكان.

لقد بدأت في التعليق على كل شيء في محاولة لفهمه. شروح لكل ميزة يمكنني الحصول عليها.

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

ماذا فهمت أخيرا

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

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

6. الديون الفنية سيئة

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

نظرًا لأنني اعتبرت أن أي كود "مضطرب" يعد واجباً تقنيًا ، فقد حاولت على الفور القضاء عليه بأقصى درجة من الشدة!

مرة واحدة قضيت حرفيا عطلة نهاية الأسبوع يدويا تصحيح 800 أخطاء الوبر.

هذا ما كنت عصابي.

(إخلاء المسئولية: كان هذا قبل ظهور التصحيحات التلقائية).

ماذا فهمت أخيرا

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

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

7. كلما كان موضع مبرمج ، كلما كان أفضل

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

لفترة طويلة ، اعتقدت أن هذا هو جوهر المطور الرئيسي.

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

ماذا فهمت أخيرا

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

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

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

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