ماذا تفعل مع المطورين النجوم الذين لا يوثقون أعمالهم؟[مغلق]

Question

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

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

ربما يكون هذا أحد هؤلاء الأشخاص الذين يعتقدون "إذا كنت الشخص الوحيد الذي يعرف هذا، فلن يتمكنوا من التخلص مني"؟

أي اقتراحات بشأن ما يجب القيام به؟

إدارة BTW على علم بالوضع وتحاول تغيير الأمور.

Answer 1

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

أعدك أنه حتى بعد نصف عام لن يعرف كيف يعمل الكود الخاص به!اطرده ويمكنك توفير الكثير من الوقت والمال.

Answer 2

جزء CVS سهل - فشل القرص الصلب "العرضي" سيعلمه درسًا مدى الحياة (تأكد من أن لديك نسخة احتياطية حتى لا تفقد الكود فعليًا)

Answer 3

هذا يبدو وكأنه موقف صعب.

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

Answer 4

يعد الفشل في التوثيق طريقة (سيئة للغاية) لضمان الأمن الوظيفي.

يمكنك القيام بعدة أشياء لمواجهة ذلك:

• إضافة الوثائق كشرط لمراجعات الأداء الشخصي.
• لا تقبل البرامج غير الموثقة.
• تحدث مع المطور واكتشف سبب عدم توثيقه.
• قم بشراء أداة توثيق رائعة.

Answer 5

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

Answer 6

التحدث معه؟

إذا كان "مطورًا مميزًا" حقًا، فسوف يأخذ في الاعتبار ما تقوله.

قد لا يغيره ذلك بين عشية وضحاها، ولكن ربما يكون غير مدرك تمامًا أن الآخرين لا يفهمون الأمر تمامًا كما يفعل.

---

يحرر:

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

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

Answer 7

ربما كنت تركز على المنطقة الخاطئة هنا، حيث يتم منحك فرصة لرؤية بعض نقاط الضعف في عمليتك.

• يعمل في منطقته الصغيرة في الدليل الرئيسي الخاص به بدلاً من مستودع CVS المشترك

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

• لا يوثق الكود الخاص به

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

• لا يعلق على الكود الخاص به، على سبيل المثال.3500 SLOC من C بدون تعليقات ولا أسطر فارغة لتوضيح الأمور

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

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

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

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

Answer 8

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

Answer 9

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

Answer 10

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

Answer 11

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

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

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

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

على أية حال، أعتقد أن هذا سؤال ممتاز، والإجابة ليست بسيطة على الإطلاق.

Answer 12

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

فكر في الأمر بجد.

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

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

Answer 13

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

Answer 14

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

أخشى أنك ستخسر مطورًا جيدًا.

Answer 15

"مرحبًا مطور النجوم،

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

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

Answer 16

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

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

Answer 17

من غير المرجح أن تتخلص منه الإدارة إذا كان ذكيًا حقًا.

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

لن تقوم أي إدارة بطرد مبرمج جيد فقط لتوظيف مبرمج سيئ.

أخبره أنه سيساعد له ليتخلص من الإدارة متى أراد ذلك.

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

Answer 18

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

Answer 19

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

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

يمكن أن يكون وجود "خبير" منقذًا مطلقًا للحياة - أو على الأقل كان كذلك، أو هل جعل StackOverflow هذا الدور زائدًا عن الحاجة؟

Answer 20

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

يحرر اذكره في تقديره.يمكن منحه رمز التوثيق/التعليق على "مجالات التحسين" الخاصة به.

:-)

Answer 21

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

هذا إذا كان بإمكانك إقناعه بتسجيل الوصول في المقام الأول!(وهو أمر ضروري، المنظمة البحرية الدولية)

Answer 22

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

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

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

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

Answer 23

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

يبدو لي أنه عديم الخبرة ويحتاج إلى بعض الخبرة والتوجيه.

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

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

Answer 24

توثيق الكود مبالغ فيه.تدريب CVS سهل.

يجب أن يكشف الفصل الجيد عن غرضه من خلال أساليبه وخصائصه.

يعد توثيق النموذج خارج التطبيق أسهل أيضًا في التدفق والفهم.

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

يحرر:عفوًا - تم استخدام ملف CSV بدلاً من CVS للعديد من الواردات وأنا أستخدم svn heh.

Answer 25

1. اجعله يستخدم أدوات التحقق من التنفيذ الآلية.(انظر إجابتي في ""كيف تطرح أسئلة على المعوق؟")

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

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

4. استخدم كود التحليل الثابت لفهم الكود الخاص به وتنظيفه.

Answer 26

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

Answer 27

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

شخصيًا، قد لا أتذكر الكود الذي كتبته منذ 6 أشهر أو أكثر، وأقدر كثيرًا تاريخ التغييرات في نوع ما من التحكم بالمصادر.

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

Answer 28

وأنا أتفق مع معظم الناس في هذا الموضوع.إحدى الطرق لوضعه في مركز الاهتمام هي إجراء مراجعات لقواعد الفريق.

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

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

Answer 29

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

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

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

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

Answer 30

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

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

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

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

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