كمطور ، سوف تسمع العديد من النظريات مجنون ، لا تصدق عن معنى "خطوط التعليمات البرمجية". لا تصدق واحد واحد. خطوط الشفرة هي مقاييس سخيفة. في حالات نادرة جدًا ، تقول شيئًا ، لا شيء عادة. استخدام أسطر التعليمات البرمجية لاتخاذ القرارات يشبه تقييم جودة الكتاب حسب عدد الصفحات.
قد يقول البعض أنه كلما قلت سطور التعليمات البرمجية في التطبيق ، كلما كانت القراءة أسهل. هذا صحيح جزئيا فقط. إليك مقاييس الشفرة القابلة للقراءة:
- يجب أن يكون الرمز ثابتًا
- يجب أن يكون الرمز غني بالمعلومات.
- يجب أن تكون الشفرة موثقة جيدًا.
- يجب أن يستخدم الكود وظائف حديثة مستقرة.
- الرمز لا يجب أن يكون معقدًا جدًا
- يجب ألا يكون الرمز غير فعال (لا تعمد كتابة رمز بطيء)
إذا كان تقليل عدد أسطر التعليمات البرمجية يناقض أيًا من هذه المقاييس ، فستصبح هذه مشكلة. في الممارسة العملية ، سوف تتدخل دائمًا تقريبًا ، وبالتالي ، فهي دائمًا ما تكون مشكلة. ولكن هذا هو الشيء ، إذا كنت تسعى جاهدة للوفاء بالمعايير المذكورة أعلاه ، فسيحتوي الرمز الخاص بك على عدد مثالي من الأسطر -
ولن تحتاج إلى حسابها .
اللغات ليست بالضرورة "جيدة" أو "سيئة"
باستثناء فب ، بطبيعة الحال (نكتة). مصدرأرى الناس يقولون مثل هذه الأشياء في كل وقت:
- C أفضل من X بسبب الأداء
- بيثون أفضل من X بسبب الإيجاز
- هاسكل أفضل من X بسبب الأجانب
فكرة أن المقارنات اللغوية يمكن تخفيضها إلى جملة واحدة هي فكرة مسيئة. هذه لغات وليست بوكيمون.
لا تفهموني خطأ ، هناك بالتأكيد اختلافات بين اللغات. لا يوجد عمليا أي لغات "عديمة الفائدة" (على الرغم من وجود العديد من اللغات القديمة / الميتة). كل لغة لديها مجموعة فريدة من التسويات. في هذا الصدد ، فإنها تبدو وكأنها مربع الأدوات. يمكن لمفك البراغي القيام بما لا تستطيع المطرقة فعله ، لكن هل سيقول أحدهم أن مفك البراغي أفضل من المطرقة؟
(من الواضح أن المطرقة أفضل)
قبل أن أتحدث عن تقييم اللغة ، أريد توضيح شيء ما.
اختيار لغة نادرا جدا ما يهم . بالطبع ، لا يمكن القيام ببعض الأشياء في بعض اللغات. إذا كنت تكتب لواجهة أمامية ، فلا خيار أمامك. هناك سياقات محددة يكون فيها الأداء مهمًا ، ولغة X غير مناسبة ببساطة ، ولكن مثل هذه المواقف نادرة جدًا. بشكل عام ، يعد اختيار اللغة عادةً واحدة من أقل القضايا أهمية للمشروع.
فيما يلي الجوانب الرئيسية بالترتيب ، والتي ، في رأيي ، يجب أن تؤثر على اختيار اللغة (بدون مقاييس محددة):
- كثافة الموارد المتاحة عبر الإنترنت (كثافة StackOverflow)
- سرعة التنمية
- خطأ الاستعداد
- جودة وتغطية النظام البيئي للحزمة (نعم ، npm ، الحديث عن الجودة)
- الأداء (المزيد من النقاط)
- فرص العمل (عذرا ، كوبول)
بعض العوامل المهمة وراء نفوذك. إذا كنت تعمل في مجال علم البيانات ، فأنت بحاجة حقًا إلى استخدام Python أو R أو Scala (ربما Java). إذا كان هذا مشروع هواية ، فاستخدم ما تريد. لدي قاعدة واحدة لا جدال فيها. أرفض استخدام اللغات إذا لم يتم حل معظم المشكلات المحتملة مع هذه اللغة بالفعل على StackOverflow. ليس الأمر أنني لا أستطيع حلها ، إنه لا يستحق الوقت.
قراءة رمز شخص آخر أمر صعب
من الصعب قراءة رمز شخص آخر. يتحدث روبرت ك. مارتن عن ذلك في Pure Code: "في الواقع ، فإن نسبة الوقت لقراءة وكتابة الكود تتجاوز 10 إلى 1. نقرأ باستمرار الكود القديم عندما نحاول كتابة كود جديد. ... [لذلك] ما يبسط قراءتها ، يبسط كتابتها أيضًا. "
لفترة طويلة ، اعتقدت أنني كنت ضعيفًا في قراءة كود شخص آخر. مع مرور الوقت ، أدركت أن كل مبرمج تقريبًا يواجه هذه المشكلة كل يوم. تشبه قراءة رمز شخص آخر قراءة نص بلغة أجنبية. حتى إذا كنت مرتاحًا لاختيار لغة البرمجة لمؤلف الكود ، فلا يزال عليك التكيف مع الأنماط المختلفة وخيارات الهندسة المعمارية. كما أنه يفترض أن المؤلف قد كتب رمزًا ثابتًا وموثوقًا ، والذي قد يكون أو لا يكون صحيحًا. هذا صعب حقا. هناك بعض الأشياء التي ساعدتني جدًا.
مراجعة كود شخص آخر ستحسن مهاراتك بشكل كبير. على مدى العامين الماضيين ، قمت بعمل عدد قليل من المراجعات لطلبات التجمع على جيثب. مع كل واحدة جديدة ، أشعر بثقة أكبر في قراءة رمز شخص آخر. تكون طلبات تجمع GitHub مفيدة بشكل خاص للأسباب التالية:
- هنا يمكنك إجراء مراجعة في أي وقت ، فقط ابحث عن مشروع مفتوح المصدر تريد المساهمة فيه.
- القراءة في سياق محدود (وظيفة واحدة أو خطأ).
- يتطلب الاهتمام بالتفاصيل ، مما يجعلك تقدر كل سطر.
الأسلوب الثاني ، الذي سيساعد على قراءة رمز شخص آخر ، فريد من نوعه قليلاً. هذه تقنية اخترعتها ، وقد قللت حقًا مقدار الوقت الذي أحتاجه لتشعر بالراحة في قاعدة الرموز الخاصة بشخص آخر. بعد النظر في نمط الشفرة التي أريد قراءتها ، قمت أولاً بفتح vi وبدء كتابة التعليمات البرمجية بنفس النمط. عندما تكتب الشفرة بأسلوب جديد ، فإنها تعمل أيضًا على تحسين مهارات القراءة لديك. سوف يصبح النمط أقل غرابة عندما تكون قد جربته أنت بنفسك. حتى لو شاهدت مشروعًا عشوائيًا على جيثب ، إلا أنني طبقت هذه التقنية بسرعة. جربه بنفسك.
لن تكتب رمزًا "مثاليًا" أبدًا
كنت أبرمج وحدي لمدة أربع سنوات قبل أن أبدأ العمل في فريق. خلال معظم هذا الوقت ، افترضت ببساطة أن كل مبرمج في الصناعة كتب رمزًا مثاليًا. قررت أن الأمر كان مجرد مسألة وقت وجهد قبل أن أكتب الكود "المثالي" أيضًا.
هذا شيء كنت قلقًا جدًا منه من قبل. بمجرد انضمامي إلى الفريق ، سرعان ما أصبح واضحًا أنه لا أحد كان يكتب رمزًا "مثاليًا". لكن الكود الموجود في النظام كان دائمًا "مثاليًا". كيف؟ الإجابة: مراجعة الكود.
أنا أعمل مع فريق من المهندسين الرائعين حقًا. هؤلاء هم بعض المبرمجين الأكفاء والأكثر ثقة الذين يمكنك شراؤهم مقابل المال. سيبدأ كل عضو من أعضاء فريقنا (بمن فيهم أنا) بنوبة ذعر حقيقية إذا عرض شخص ما الالتزام بالشفرة دون مراجعة. حتى لو كنت تعتقد أنك بيل غيتس القادم ، فسوف ترتكب أخطاء بالتأكيد. أنا لا أتحدث عن الأخطاء المنطقية ، بل أتحدث عن الأخطاء المطبعية والشخصيات المفقودة. أن عقلك ببساطة لا يلاحظ. ما زوج آخر من العيون ل.
حاول العمل مع أشخاص آخرين يهتمون بالتفاصيل ويرغبون في انتقاد عملك. إن الاستماع إلى النقد صعب في البداية ، ولكنه الطريقة الوحيدة الثابتة لتحسين الوضع. أبذل قصارى جهدك حتى لا تتخذ موقفًا دفاعيًا أثناء مراجعة الكود ، ولا تأخذ أبدًا أي تعليقات بشكل شخصي. أنت لست رمزك.
في مراجعة الكود ، إذا كان المؤلف قد اخترت أنني لست معتادًا عليه ، فسأذهب على الفور إلى Google إذا كان اختياره مختلفًا عن الرأي العام. ليس الرأي العام دائمًا على حق ، بل الرأي العام هو الخيار الافتراضي. إذا قرر شخص ما عدم قبول الخيار الشائع ، فهذا جيد ، أريد فقط أن أعرف أنه مبرر. عند مراجعة الكود ، من المهم للغاية أن تفهم الأساس المنطقي للقرارات التي اتخذت. بالإضافة إلى ذلك ، عند النظر إلى نفس المشكلة من
منظور المبتدئين ، يمكن للمرء أن يلاحظ في كثير من الأحيان أشياء لم يكن الشخص قد اهتم بها أبدًا.
عمل مبرمج لا يعني 8 ساعات من البرمجة في اليوم الواحد
هذا سؤال شائع جدًا ، لكن الناس لا يقدمون إجابة واضحة أبدًا. كم ينفق المطور العادي أو المطور "الممتاز" كتابة التعليمات البرمجية كل يوم؟
عدد قليل جدا من التعليمات البرمجية أكثر من أربع ساعات في اليومأولئك الذين يختلفون مع هذا إما أن يكونوا استثناءات للقاعدة أو يعملون لصالح شركات تستغلهم أكثر من اللازم. البرمجة مهمة مرهقة عقلياً ومكثفة. من غير المعقول تمامًا أن نتوقع من شخص ما كتابة الكود 8 ساعات في اليوم ، خمسة أيام في الأسبوع. هناك أوقات تحتاج فيها إلى الالتزام بالمواعيد النهائية أو القيام بأكثر من ذلك بقليل في كل جلسة ، ولكن هناك القليل منها والتي نادرة. عندما أقول "نادرا" ، أقصد أبدا تقريبا. تجنب سير العمل الذي يسيء إليك ويجعلك تعمل ساعات إضافية بسبب نقص التخطيط / نقص الموظفين.
بالنسبة للبروتوكول ، حتى الشركة نفسها ليست مربحة بالنسبة لك لبرمجة 8 ساعات في اليوم بنشاط. قد يعتقد رئيسك أن الأمر كذلك ، لكنه قصير النظر ويتجاهل العواقب طويلة الأجل ، لأنه يؤثر على الإنتاجية والصحة العقلية.
فقط من أجل الوضوح ، لا أقترح عليك أن تعمل سوى أربع ساعات في اليوم. من الأفضل عادة قضاء الساعات الأربع المتبقية في:
- البحوث ، سواء المتعلقة بالعمل وليس ذات الصلة
- مناقشة عملك مع الزملاء
- ساعد الزملاء الذين لديهم مشاكل في عملهم
- تخطيط العمل في المستقبل
- رمز الاختيار
- اجتماعات
كما أوصي بشدة بأخذ فترات راحة منتظمة خلال اليوم وممارسة الرياضة (على الأقل ليس لفترة طويلة). يتم توثيق فوائد ممارسة الرياضة لمكافحة التعب العقلي بشكل جيد. لقد وجدت شخصيا أن التمرينات مفيدة بشكل خاص إذا كانت هناك مشاكل في التركيز.
هذه بعض الأشياء التي أود أن أتعلمها في الجامعة بدلاً من النظرية البحتة. في عملية الكتابة ، فكرت في الكثير من الفروق الدقيقة ، لكن هذا موضوع لمقال منفصل!