سر الكفاءة هو كود الجودة، وليس المدير الفعال

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

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

أولئك الذين هم الأغلبية.

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

لقد اصطدموا بإدارة المبرمجين لسبب واحد بالضبط: هناك الضجيج والمال والسوق ومجموعة من نفس البلهاء. هناك مكان لتضيعه.

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

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

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

لزيادة الكفاءة، تحتاج إلى حل المشكلات بشكل أسرع دون فقدان الجودة. لحل المشكلات بشكل أسرع، يجب أن تكون قادرًا على كتابة تعليمات برمجية عالية الجودة على الفور. و"عالية الجودة"، و"أكتب"، و"فوراً". اسمحوا لي أن أشرح مع استعارة.

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

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

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

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

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

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

لتلخيص: مهارة كتابة تعليمات برمجية عالية الجودة تعمل على تسريع حل المشكلات بشكل كبير.

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

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

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

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

ماذا علي أن أفعل؟ أرى وأقترح طريقين يمكن الجمع بينهما.

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

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

إذا لم يتم تسليم العمل بعد، أو قد بدأ للتو، فإن صب القرف على الكود (أو مشروعه، فكرته) يمكن أن يكون له معنى عملي تمامًا - سيقوم الشخص بذلك بشكل طبيعي.

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

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

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

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

المصدر: www.habr.com

إضافة تعليق