1. اترك الأنا عند الباب
المطورون تضخم الغرور. إنها حقيقة. لكن لماذا؟ أود أن أقول إن أي شخص جاد في مهنته يعتبر نفسه شخصًا فنيًا. نعم ، نحن لا نغني أمام الملايين ولا نرسم "الموناليزا" ، لكن في بعض الأحيان نكتب كودًا يحل المشكلات المعقدة بكفاءة وأناقة لا يسعنا إلا أن نفخر بعملنا. أعتقد أن المطور ، بسبب أسلوبه في التعامل مع المشاكل ، هو رجل فني بقدر ما هو عالم رياضيات. على هذا النحو ، فإننا نميل إلى الزحف حول الكود تمامًا مثل الأم التي تدور حول نسلها. نكتبها ونحبها ونكرهها عندما يتجادل الناس حول مدى خطأ الشفرة أم لا.
من ناحية أخرى ، لم يساعد أي شخص حتى الآن. نحن نحب عملنا ، لكن يجب أن نفهم أننا نحل المشاكل. عند مناقشة أفكارنا وحلولنا مع أشخاص آخرين ، قد يظهر بديل أفضل. لا يوجد شيء خاطئ. في الواقع ، يميل التعاون إلى تقديم حلول أفضل. لقد شاهدت كل أنواع الأنا ، لكنني لم أر أبدًا موقفًا تعمل فيه الأنا مع مطور.
ما النصيحة التي يمكنني تقديمها؟ من اللحظة التي تبدأ فيها العمل كمطور ، اترك نفسك عند الباب. ابتلعها واستمع إلى ما يقوله الآخرون عن عملك. تقبل فكرة أن أفضل الأفكار قد لا تخطر ببالك وأنها يمكن أن تعزز احترافك. ستستفيد فقط من الاستماع إلى التعليقات.
2. اللغات هي أداة. هل تعرف المطرقة فقط؟ ثم كل المشاكل مثل الأظافر
توقف عن تسمية نفسك بمطور Java أو مطور JavaScript. نعم ، هناك لغات تعجبك بسبب تركيبها أو قدراتها. هذا طبيعي تمامًا. ومع ذلك ، فإنك تربح إذا قضيت بعض الوقت في دراسة شيء آخر. إن تعلم لغات جديدة ، خاصة إذا كانت تتبع نموذجًا مختلفًا عن تلك التي اعتدت عليها ، يمكن أن يفتح عقلك على مناهج مختلفة لحل المشكلات.
لا أعرف حتى مدى أهمية هذا: تعلم لغات جديدة وتطبيقها سيفيد مهاراتك. لقد قرأت كتاب سبع لغات في سبعة أسابيع قبل بضع سنوات ، وفتح لي الكثير من الخيارات لمجرد أنه أظهر طرقًا لحل المشكلات المتوفرة بلغات أخرى.
نحن مطورين. نحن نعرف كيف نحل المشاكل مع الكود. لا تقيد نفسك. انظر إلى ما وراء الحدود ، وفكر خارج الصندوق ، وتعلم خيارات أخرى ، ولغات ، وطرق لحل المشكلات. حتى إذا لم تفعل ذلك لفترة طويلة ، فستعود إلى أداتك المألوفة بأفكار جديدة وتفكير أوسع.
3. لا يتعلق الأمر بحفظ الخوارزميات ، ولكن بإيجادها
يعتقد بعض المطورين الجدد أنهم بحاجة إلى معرفة الخوارزميات عن ظهر قلب ، لذلك يشعرون بالسوء في اللحظة التي يدركون فيها أنهم بدأوا في نسيان كيفية كتابة حلقة for. هذا ليس طبيعيا فقط. أود أن أقول إنه مفيد حتى. لدينا الكثير لنتذكره. لكن هذا أيضًا غير ضروري. نحتاج إلى قبول فكرة أن الإنترنت مجرد أداة أخرى حسب الحاجة مثل IDE الخاص بنا للعثور على إجابات.
كلنا نفعل هذا. وإذا كان ذلك يجعلك تشعر بالسوء ، فلا تضيع الوقت في هذا الشعور. ما عليك سوى البحث في Google عن الإجابة وفهم مشكلتك. التفكير في هذا. كل لغة لها طرق متشابهة ولكنها مختلفة قليلاً لتطبيق نمط المراقب. ما هو أكثر فائدة؟ فهم ما هو النمط الجيد وما المشكلات التي يحلها ، أو تذكر كيفية تنفيذه في كل لغة تعمل بها؟
إذا كنت تعلم أن النمط سيحل مشكلتك ، فهذا يعني أنك قد قمت بحلها بالفعل. كل شيء آخر هو مجرد بحث عن أفضل طريقة لتنفيذه على Google. هذا البحث لا يسلبك أي احترام لك أو لعملك أو لتجربتك. الأمر نفسه ينطبق على أي بحث آخر. ركز على ما هو مهم وحل المشكلة ودع Google تدفع ذاكرتك. هذا هو سبب وجودها.
4.
أو بالأحرى، ل ديك لدراسة لحياتك المهنية بأكملها. إن قرار متابعة آخر التطورات في الصناعة متروك لك. لكن من الأفضل القيام بذلك إذا كنت تريد المطابقة.
تتطور اللغات والتقنيات ، وهذا أمر طبيعي تمامًا. بالطبع ، تتغير بعض الأنظمة البيئية بشكل أسرع من غيرها ، وقد تبدو مواكبة هذه الأنظمة مهمة جسيمة ، لكن ركز على الأشياء المهمة ، تذكر أنك مجرد بشر ولا تستطيع معرفة كل شيء. لذلك ، إذا كنت بحاجة إلى تعلم شيء واحد ، أقترح أن تتعلم كيف تتعلم.
أعلم أن هذا قد يبدو سخيفًا ، لكن ربما يمتلك المطور هذه المهارة الأولى. يجب أن نتعلم كيف نتعلم مهارات جديدة بسرعة. وإلا فإنك تخاطر بالحصول على التصنيف "قديم".
هذا هو المكان الذي تلعب فيه بعض الدروس الأخرى في هذه المقالة. التباين ، والتغيير ، والتحديات الجديدة ، ونقص الأنا - كل هذا سيساعدك على التعلم وتوسيع نطاق مهاراتك. كلما مارستها ، كان ذلك أفضل. في النهاية ، ستجد أن جميع اللغات متشابهة. ستبدأ في رؤية جذورهم المشتركة وستكون قادرًا على العمل مع أي منهم. كل ما عليك فعله هو قراءة بضعة أشياء أساسية. طوال حياتك المهنية ، سوف تدرس:
- لغات جديدة.
- نماذج البرمجة الجديدة (والقديمة).
- مناهج جديدة للعمل.
- طرق جديدة لحل المشاكل.
- طرق جديدة للتفاعل مع الزملاء.
- طرق جديدة لمراجعة واختبار التعليمات البرمجية الخاصة بك.
إذا لم تكن مستعدًا لأن تكون طالبًا دائمًا ، ففكر فيما إذا كانت هذه المهنة مناسبة لك. لاحظ أنني لم أقل ، "غادر فورًا" ، ولكن ضع في اعتبارك ما إذا كنت مستعدًا لفتح عقلك للتعلم المستمر.
5. يعمل بشكل أفضل من المثالي
كمدير ، سمعت هذا مرات عديدة. لكن بصفتنا مطورين ، نميل إلى الاعتقاد بأن الشفرة يجب أن تكون مثالية قبل إصدارها. وهذا ليس فقط غير صحيح ، ولكن يحتمل أن يكون مشكلة. يعد التحسين مبكرًا مشكلة لأنك في نهاية المطاف تنفق الكثير من الوقت والجهد على أشياء قد لا تحتاج إلى تحسين. وفي بعض المواقف ، عند القيام بهذا التحسين ، فإنك تضع افتراضات تعطل الوظيفة.
لذا ركز على العمل الذي يتعين القيام به والمشكلة التي تحاول حلها. بعد حل المشكلة ، اختبرها ، وكرر النتائج ، واطلع على رأي فريقك في الحل الذي تقدمه ، حتى لو كان بإمكانك بالفعل رؤية طرق لتحسينه. إذا كنت ستقضي يومين آخرين فقط في جعل الكود مثاليًا ، ولكن قد يدخل حيز الإنتاج الآن ، فمن المحتمل أنه يجب أن يكون قيد الإنتاج الآن.
في النهاية ، أنت تحل المشكلة. كلما تم حل المشكلة بشكل أسرع ، كان ذلك أفضل للمستخدمين لديك.
6. اجعل الكود يعمل ، ثم قم بالتحسين
وفقًا لبعض النقاط السابقة ، لا تدخل في الثقب الأسود للتحسين المبكر. حتى إذا كنت تعتقد أنك ستنجز الشفرة بسرعة ، فبمجرد خروجها (إذا حدث ذلك) ، ستجد أن تأثير تمدد الوقت حقيقي.
بصفتك مطور برامج يكتب ميزة جديدة أو يصلح خطأ ، فإن أولويتك الأولى هي جعلها تعمل ، بغض النظر عن مدى قبح الكود أو مدى عدم كفاءة الحل. إذا نجحت الشفرة ، فقد أثبتت للتو أنه من الممكن كتابة التعليمات البرمجية. هذا نصف المعركة.
الخطوة الثانية هي التحسين. هذه الخطوة اختيارية. التفاصيل التي يميل بعض الناس إلى نسيانها. يعتمد الوقت المتاح لك لتحسين شفرتك على العديد من المتغيرات التي لا تتحكم فيها أحيانًا. لذا ركز على جعل الكود يعمل ثم اكتشف ما إذا كان لديك بالفعل الوقت لتحسينه.
التحسين المبكر يعني تحسين الكود الخاص بك أثناء كتابته. هذه ممارسة خطيرة لأننا عند التحسين نقوم بعمل افتراضات حول وقت التشغيل ومتطلبات البيانات ومتطلبات الذاكرة وعوامل أخرى لم نرها بعد في العمل. قد يكون أي افتراض من هذا القبيل خاطئًا ، وفي النهاية ستدخل أخطاء في منطقك.
فكر في سير عمل TDD:
- اكتب اختبارًا لفهم كل ما يجب القيام به لوظيفتك (سيفشل الاختبار).
- اكتب الكود الخاص بك حتى ينجح الاختبار.
- الآن تقلق بشأن تحسين التعليمات البرمجية الخاصة بك.
الخطوة الثانية مطلوبة. تحتاج أولاً إلى الاهتمام بالاختبار ، مما يعني أن الوظيفة تعمل. لا يهتم الاختبار باستخدام ثلاث عبارات if المتداخلة في الخوارزميات الخاصة بك. سيصبح هذا مهمًا ، ربما في مرحلة مراجعة الكود.
7. آخر 10٪ من المشروع تستغرق 90٪ من الوقت
هذا مهم بشكل خاص إذا كنت تعمل بمفردك ، لكن الفرق تعاني أيضًا من عدم فهم هذه التفاصيل الرياضية الصغيرة بشكل صحيح. أي شخص أكمل مشروعًا سيقول الشيء نفسه (وبصراحة ، هذا ليس هو الحال في صناعتنا فقط). أولاً ، تستعجل كثيرًا من التفاصيل لتفكر فيها لاحقًا.
وهذا طبيعي تمامًا. نميل إلى التركيز بشكل أساسي على الميزات الكبيرة ، وترك التفاصيل الصغيرة أو حتى الأخطاء المعروفة حتى النهاية. لكن مع ذلك ، يجب أن تقاتلهم - وهنا تظهر 90٪ إضافية. يجب عليك اختبار الكود وإصلاحه واختباره مرة أخرى وتعليم المستخدمين كيفية التعامل مع الحل وإرسال الإصدار النهائي من الحل وما إلى ذلك. بالطبع ، كل هذا يتوقف على السياق ومن هو عميلك والعديد من العوامل الأخرى ، ولكن هناك دائمًا شيء ما. لذا تذكر ، عندما تعتقد أنك على وشك الانتهاء من الشفرة ، فمن المحتمل أنك نسيت شيئًا ما.
8. عندما تكون في فريق ، فأنت بحاجة إلى التجريد.
تتعلق البرمجة بسلوك التجريدات. باستخلاص المنطق العام ، يمكننا إعادة استخدامه في مكان آخر ، لكن في البداية ننسى أهمية التجريدات. ها هي قاعدتي الشخصية: إذا تكرر الرمز في مكانين ، يتم إرساله إلى دالة (طريقة ، وحدة) ؛ انت وجدت الفكرة. إذا بدت التكراران كرقم صغير لعينيك ، فضع في اعتبارك أنه قد تكون هناك أماكن أخرى في المستقبل لتطبيق الكود الذي استخلصته للتو. وبتجريد الشفرة على الفور ، ستتمكن من الوصول إليها على الفور.
التجريد هو التحجيم. يمكن استخدام قطعة من المنطق المستخلص عدة مرات بأقل جهد ، بينما نسخ ولصق (على الرغم من أنه من السهل القيام بذلك) - فكلما زاد استخدامه ، زاد الجهد الذي يتطلبه. فكر فيما يحدث إذا احتجت ، بسبب خطأ ما ، إلى تغيير جزء من المنطق يتكرر 5 مرات. لإصلاح خطأ ، يمكنك تغيير نفس الجزء من الكود 5 مرات.
نفس المنطق ينطبق على المهام اليومية. إذا فعلت شيئًا أكثر من مرة ، فمن المحتمل أن يكون آليًا بطريقة ما. هذا هو مفتاح الكفاءة ، لذا انظر إلى التكرار ليس فقط في التعليمات البرمجية الخاصة بك ، ولكن أيضًا في أفعالك. إذا قمت بأتمتة مهمة تستغرق 10 دقائق في اليوم ، فستوفر 5 ساعات في الشهر.
9. المشاريع الجانبية اختيارية ، لكنها يمكن أن تساعد
يقول البعض أنك إذا كنت تريد أن تكون مطورًا ناجحًا ، فأنت بحاجة إلى مشاريع جانبية. لا أعتقد أن هذا صحيح. أنا شخصياً أعرف العديد من المطورين الرائعين الذين يكتبون التعليمات البرمجية في العمل فقط ، "من 9 إلى 17". لأكون صادقًا ، أنا معجب بهم. إنهم سادة حرفتهم ، وفي أوقات فراغهم ، يفعلون شيئًا آخر ، يستمتعون بالحياة. ليست هناك حرج في ذلك. ومع ذلك ، في بعض الأحيان تحتاج إلى بعض الممارسة الإضافية. تشعر أحيانًا أنك متأخر عن زملائك ؛ هنا ومساعدة المشاريع الجانبية.
أنا لا أتحدث عن ثورة في الصناعة - تطوير إطار عمل مع ملايين المستخدمين. اكتبه إذا أردت ، لكنني أتحدث عن نسخ مشاريع شخص آخر للتعلم منهم. أتحدث أيضًا عن المساهمة في مشاريع الآخرين ، وإصلاح الأخطاء وإضافة الوظائف.
يمكنك كتابة مشاريع جانبية لتجربة جوانب أخرى من التنمية لا تلمسها عادة. إذا كنت تكتب اختبارات وحدة 8 ساعات في اليوم ، فقد تفكر في كتابة شيء ما من الصفر أو تطوير بعض الوظائف. إذا مللت من العمل بمفردك ، فساهم في مشروع قائم للآخرين واختبر معنى تنسيق عملك مع الآخرين. يمكنك كتابة مشروع جانبي لتحسين مستوى مهاراتك من خلال معالجة نقاط الضعف. ولكن مرة أخرى ، لا تشعر أنك بحاجة إلى العمل عليها باستخدام شريط نشاط Github الأخضر ليتم اعتباره مطورًا جادًا. هذا مجرد سخيف.
استنتاج
إليكم 9 دروس صعبة كمطور على مدار الـ 18 عامًا الماضية. آمل ، من خلال مشاركة تجربتي ، أن ألقي بعض الضوء على مستقبلك أو حياتك المهنية الحالية. هل تعلمت شيئًا آخر تود مشاركته؟ أود أن أسمع منك في التعليقات ، أود أن أتعلم منك شيئًا.
