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

تطور مبرمج

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

مبتدئ

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

أخصائي

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

المهنية

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

أسباب الخوف

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

لا أستطيع أن أفعل ما هو أفضل

المبتدئين حقا لا يمكن. يجب عليه توجيه جهوده لشرح جوهر وأهمية المشكلات التي يراها بنظرة جديدة للزملاء ومطوري المكتبات الأكثر خبرة.

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

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

لن يكون هناك أحد لإصلاح العيوب

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

لا أحد سوف يتحسن ويتطور

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

لا يمكنني استخدامه في أي مكان آخر

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

سيتم إهدار الوقت والمال

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

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

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

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

سوف أكون لعن كما لعنت سلفي

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

1. وجود ميزة واضحة ومهمة للمشروع.
2. واجهة استخدام بسيطة حتى لا تضطر إلى القيام بأغلفةك.
3. واجهة برمجة تطبيقات مرنة حتى لا تضطر إلى رؤية دراجة جديدة مع تغيير بسيط في المتطلبات.
4. تغطية اختبار جيدة ، والتي سوف تسمح أقل من وميض في تقارير الأخطاء وتسترجع إعادة بناء جيدا.
5. وثائق شاملة بحيث لا تحتاج للبحث عن مؤلف الدراجة لفهم كيفية ركوبها.

لا أريد تحمل المسؤولية

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

توصيات

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

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