🥟 🍭 👩🏾‍🎨 ثمانية عادات مهمة للمبرمج 🚞 🛀🏼 📧

"يمكن للشخص أن يصبح شخصًا فقط من خلال التعليم. إنه ما يصنعه التعليم منه. ”
أولا كانط

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

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

لذا ، دعنا ننتقل إلى العادات الثمانية المفيدة للمبرمج التي ستجعلك أفضل محترف.

1. لا تكرر (جاف - لا تكرر نفسك)

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

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

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

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

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

هناك قائمة كاملة من المبادئ المماثلة المفيدة جدًا التي يجب الالتزام بها. ولكن ، في رأيي ، DRY أساسي لكل شيء آخر في عمل المبرمج.

2. بمجرد أن تقرر أن كل شيء يتم ، ريفاكتور

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

هل يعمل الرمز بشكل صحيح؟ نعم! إذن ما هو الاتفاق؟

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

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

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

3. التركيز على مهام العمل

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

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

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

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

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

ولكن ، كما ترى ، من وجهة نظر مبرمج ليس على دراية بمهام العمل ، ستبدو هاتان المهمتان متكافئتين.

لفهم أفضل ، أنصحك بقراءة كتاب "ابدأ مع لماذا" لسيمون سينك .

4. تلتزم الصغيرة

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

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

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

بصفتي أدبًا ، أوصي بشدة بقراءة الفصل الأول على الأقل من كتاب "Git for a Professional Programmer" للمخرج سكوت شاكون وستراوب بن. عندما تكتشف الوظائف الرائعة الموجودة في Git وما هي قادرة عليه ، يبقى فقط الالتزام في كثير من الأحيان ، ويمكن تسوية الباقي بالأدوات اللازمة.

5. عد الوقت

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

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

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

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

ثم حاول موقع wakatime.com. واتضح أن هذه الرصاصة الفضية. هذه الخدمة لديها القدرة على الاندماج في جميع IDEs الشعبية ، وكذلك التكامل مع github. ونتيجة لذلك ، يمكنك تحديد عدد الدقائق المفيدة التي قضيتها في البرمجة بدقة تصل إلى دقيقة. بالإضافة إلى ذلك ، هناك ملزم للالتزام. إنه لأمر رائع عندما يمكنك رؤية ليس فقط ارتكاب أنفسهم ، ولكن أيضًا معرفة الوقت الذي يقضيه في هذا الالتزام.
مجموعة مذهلة من الوصفات للتنظيم الصحيح للوقت والعمل على المشاريع في كتاب "تقنيات جدي" لمكسيم دوروفيف .

6. الاستقرار هو علامة على إتقانها.

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

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

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

إذن ما الذي يجب القيام به للالتزام بمبدأ الثبات؟

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

أيضا دراسة الأدبيات حول كيفية تسمية الفئات والأساليب والمتغيرات. أوصي بكتاب "كود مثالي" لستيف ماكونيل.

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

7. افعل ذلك مرة واحدة

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

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

8. لا تتوقف عن التعلم

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

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

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

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

استنتاج

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

في مثل هذه التجارب الصغيرة ، ستقوم بتدريب مهاراتك وتطوير جميع العادات المهمة.

ثمانية عادات مهمة للمبرمج