عندما نُشرت الطبعة الروسية الأولى من كتاب "كيف ترعى القطط" المعروف ، والمخصص للموضوع الصعب المتمثل في إدارة الضالعين من قبل مطوري الطبيعة المحترفين وليس مطوري البرمجيات ، لاحظ زميلي الأكثر خبرة ، مدير المشروع: "سيكون من الأصح أن أسميها" كيف ترعى الماشية " . تم تذكر هذه العبارة ، وكما تظهر الخبرة المتراكمة منذ ذلك الحين في التفاعل مع المبرمجين - كان الزميل على حق.
كيف يرى المبرمجون في نينا زملائهم
على Habré ، هناك قدر لا بأس به من المقالات المكرسة لمنهجيات تطوير البرمجيات والاتصال والتفاعل في فريق المشروع ، واختيار وتعيين المبرمجين. بدون مبالغة ، تجمع كل مقالة الكثير من التعليقات الغاضبة من المبرمجين ، والتي يلقون باللوم فيها على "المعجزات" ، والمختبرين ، وموظفي إدارة شؤون الموظفين ، والمحللين ، والعملاء - لكل من لا يحب نفسه بسبب أوجه القصور في منهجية معينة أو الفشل في المشاريع. في المقالات والتعليقات عليها ، الرأي السائد هو أن المطور دائمًا على صواب. يعود سبب هذا الرأي ، في جملة أمور ، إلى حقيقة أن المبرمجين يشكلون غالبية الجمهور في هبر. في الوقت نفسه ، يعمل المتخصصون الذين ليسوا مبرمجين في المنظمات وفرق المشاريع. تعبر هذه المقالة بشكل خاص عن وجهة نظر جانب أو آخر تم تشكيلها على الجانب الآخر من "المتاريس".
اليوم ، يا صديقي الشاب ، سوف أصف العالم لك من خلال عيون زملائك وأخبركم كيف تظهر لهم ، في هذا العالم ، مطور البرامج ، المبرمج العظيم والصحيح دائمًا. هل أنت متأكد من أنك مركز الكون ، مثل قطتك ، وأن الجميع مدين لك
نعش قبل نهاية المشروع. يتم دعم هذا الرأي ، من بين أشياء أخرى ، من خلال التفوق الكمي لفوجك في فريق المشروع ، ولكن في الواقع في نصف جيد من المشاريع التي كنت فيها ، شابًا أو شابًا بالفعل ، ولكن ما زلت لا تحصل على ما يكفي من صديق العقل ، فإن بقية الفريق هادئ يكره كلي العلم الخاص بك والغرور المفرط. يتم حظر التطفل الخاص بك فقط من قبل snobbery المفرطة والمفرطة بشكل مفرط للمهندس المعماري ، ولكن الحديث عن هذه
الطبقة سوف يذهب بعض الوقت.
يكرهك محلل الأعمال بالنسبة لأجزاء المواصفات الأكثر استهلاكا للوقت والتي يزعم أنها لم تتحقق بسبب الرقابة.
يكره المختبرون على طرح النسخة النهائية بالتصحيحات قبل 5 دقائق من نهاية يوم العمل والعودة إلى المنزل بهدوء ، ولا يزال يتعين عليهم قضاء ساعات إضافية في المساء لفحص خمسين تصحيحات واختبار الانحدار قبل إصدار الغد.
يكرهك مدير المشروع لأنه يبصق عليه من أعلى برج جرس ، لأن مستقبلك ، وكذلك الراتب في الشركة ، لا يعتمدان على رأيه وتعليقاته ، بل يعتمدان فقط على رئيسك المباشر ، الذي سيجد دائمًا طريقة لحمايتك من أي فشل لك. حسنًا ، بالطبع ، يكرهك أكثر من المختبرين ، لأنه بعد الانتهاء من الاختبار وإعطاء الضوء الأخضر لإصدار الإنشاء النهائي ، سيظل عليه في تمام الساعة 11 مساءً استكمال إعداد تقارير الإصدار النهائي لـ فرق نشر وصيانة للعميل.
تكره خدمة الدعم لك شفرة "التوثيق الذاتي" والتهرب المستمر من الإجابات على أسئلتهم ، حتى لو تم تخصيص ساعات دعم الكود المعزول بشكل خاص في الجدول الزمني الخاص بك في المشروع الجديد الذي تم تعيينك له.
ومع ذلك ، أول الأشياء أولا.
مسار حياة مبرمج عادي
بطريقة ما ، بعد أحد المشاريع
الناجحة ، قمت ، بموافقة رئيس قسم التطوير ، بإعداد عرض تقديمي لمجموعة البرمجة ، والذي تضمن ، من بين أشياء أخرى ، "رسمًا بيانيًا" يصور مسار حياة المبرمج ، من بدايته الأولى ، الترميز في المفكرة في سن المدرسة من خلال تطوير بيئات التطوير المتكاملة (20 عامًا) ، وإدارة العيوب (25 عامًا) والتفاعل مع مجموعات أخرى من المتخصصين والمقاولين الخارجيين (30 عامًا) ، قبل تطبيق ممارسة التكامل المستمر والتطوير التلقائي حققت النشرات yvaniya
ظهور الشيب 35 عاما (معالم العمر، بالطبع، الشرطي، وتخدم فقط لتوضيح طريقة الحياة في المتوسط). مبرمج ، مثله مثل أي شخص آخر في العالم الحديث ، مجبر على التعلم باستمرار وتحسينًا تقنيًا ومهنيًا ، وينجح كثيرون جدًا في ذلك. في الوقت نفسه ، يبدأ معظم من يكتبون أول برنامج لصف
المخالفات "Hello، World" وينشرون سيرة ذاتية على hh.ru / monster.com على الفور في نشر أصابعهم في المقابلات ويصفون أنفسهم بفخر بأنهم "محترفون حقيقيون" ، - هذه ليست في الواقع.
في ذلك المشروع ، تمكن أحد المطورين من نسيان وضع الشفرة المحدثة في مستودع مشترك ، وحاول اثنان من زملائه نصف يوم في الوضع المتطرف تحديد سبب عدم عمل الوظيفة كما هو مذكور؟ أخطأ مطور آخر في البرنامج النصي للنشر ، وإذا لم يكن قد لاحظه مدير المشروع (!) ، فسيتم تأجيل تنفيذ نتائج تعاون الفريق للتكرار بأكمله حتى الدورة القادمة لإصدار الكود في بيئة المنتج ، أي لمدة 2 أسابيع.
كان لدى كلا المتخصصين أكثر من عام واحد خلفهما ، حيث كانا محترفين في تطوير البرمجيات ، أي حصل على تعويض نقدي عن عملهم ، لكنه لم يرمز "لأنفسهم" أو في مشروع مجاني مفتوح المصدر. ومع ذلك ، ارتكبوا أخطاء "صبيانية" بغض النظر عما ينظرون إليه. إنه أمر مشهور ، حيث يعاني الجميع من عيوب ؛ فقط الشخص الذي لا يفعل شيئًا لا يجزأ. ولكن هذا هو السبب في أنني أردت أن أقدم عرضًا تقديميًا للمطورين للعرض ، على أساس تجربتي في تقديم المشورة لمختلف فرق المشروع ، ما هي المشكلات التي يواجهها أي مبرمج تقريبًا وما لا يكمن في مجال المعرفة بتكنولوجيا برمجة معينة ، ولكن في المجالات ذات الصلة ، حيث تنتهي حبيبك ، MUD ، المصممون والمدمرون ، وتبدأ المهارات في العمل مع المتطلبات ، الأدوات ، العيوب ، التخطيط ، إلخ. لذلك ، إذا كنت في مكان ما أثناء قراءة مقال في أي من الأمثلة المذكورة أعلاه ، فأنت تتعرف على نفسك عن طريق الخطأ ، وبعد قراءتها تستخلص استنتاجات مناسبة وتنجح في "أن تنمو فوق نفسك" - سيرى الآخرون بحقك كمحترف في مجالهم وسنفرح بذلك هذا العمل معك في نفس المشروع والفريق.
التفاعل مع غير المبرمجين
فليعلمك ، يا صديقي الماهر ، أن المتخصصين الآخرين الذين تعمل معهم جنباً إلى جنب في فريق المشروع ، مثل المختبرين والمحللين والكتاب التقنيين والمصممين وغيرهم ، ليسوا أقل مسؤولية عن نجاح المشروع منك
، يا معجزة الكون . كل هؤلاء الأشخاص من غير البشر يلعبون دورًا لا يقل عن ذلك ، وفي بعض المشاريع أكبر من دورك كجهاز تشفير ، وبالتالي فإن التفاعل الكفء والخير معهم جزء لا يتجزأ من عملك ، حيث تتلقى الكثير من المال من جهاز صراف آلي مرتين في الشهر (إلى في كلمة واحدة - المال أكبر
بكثير مما يحصل عليه هؤلاء الأشخاص من أجهزة الصراف الآلي نفسها). غالبًا ما تنظر إليهم واحتياجات تصميمهم من أعلى أو من خلال أصابعك ، دون الاهتمام الذي يطلبونه بحق. ولهم احتياجات وتوقعات مهنية ، ومختلف ، حسب أدوارهم.
المحلل ، على سبيل المثال ، يتوقع أنك لن تكتفح فقط حول كل حرف في المواصفات وبدونه ، ولكن أيضًا ستترجمها بضمير إلى رمز البرنامج. وأنك لن تقوم بحماية نظارات عندما يسألونك أثناء الاختبار عن سبب عدم قيامك بتنفيذ الوظيفة الأساسية التي تم تضمينها في إصدار الغد والموضحة في المتطلبات قبل تعيينك في فريق المشروع قبل عام ، دائمًا هناك ومنذ ذلك الحين لم يتغير حرف واحد.
يمتلك المختبر الحق في أن يتوقع منك نتيجة خالية من الأخطاء في عملك. عندما تم تعيينها ، تم وعدها ، وبالتالي فهي تتوقع ألا تكون جزءًا من منهجية تطوير TDD ، والتي بموجبها تقوم أنت MUD "بطرح" المنتج غير المكتمل للاختبار ، واستناداً إلى نتائجها ، أكمل الأجزاء المفقودة من الوظائف وتصحح العيوب الواضحة. ومن المؤكد أن المختبر يتوقع أنك لن تنشر تعفنًا لحقيقة أنها لا تعرف كيفية اختبار المنتج بطريقة غير يدوية ، أو أن مهاراتها في العمل مع لغة استعلام قاعدة البيانات أقل بكثير من مهاراتك. في النهاية ، لا تنسوا أنها تدفع لها مقابل الاختبار اليدوي عدة مرات أقل مما تفعله للبرمجة ، وأنها إذا كانت تعرف لغة SQL تمامًا كما فعلت ، فستجلس في مقعدك أمام شاشتك ، وليس أنت ، لأنه بمؤهلات متساوية بينكما ، سيكون لها هي التي تفضل تركها في الفريق والمنظمة ، لأنه ، على عكسك ، بعد أن اجتازت الطريق الصعب للاختبار ، فإنها لن تنتشر على زملائها مثلك.
المعرفة الهندسية للتكنولوجيا
هل انتهيت بالفعل من معهد
رياض الأطفال وفي المقابلات التي قمت بتوضيحها بنجاح كيف يختلف المصمم عن المدمر؟ سأخبرك سراً بأن العالم الاحترافي لإنشاء البرامج لا يقتصر على هذه المعرفة ، وإذا كنت لا تزال تعتقد أن التعليمات البرمجية المكتوبة والقابلة للتنفيذ بطريقة ما هي نتيجة كافية لعملك
لعدم حصولك على كلمة lyu
من مدير المشروع / العميل لتلقي sn مرتين في الشهر ، فأنت في في حياتك المهنية المستقبلية ، ستشعل الكثير من المشكلات على رأسك ، والأهم من ذلك ، ستكون مصدر صداع دائم لكل من ليس محظوظًا بما يكفي للعمل بجانبك.
"الإصدار؟ التعليق على الكود؟ الالتزام بمعايير الترميز والتسمية؟ لا ، لم اسمع! " لذلك قل لزملائك هنا وهنا في مجموعة متنوعة من فرق المشروع والمؤسسات. صديقي الشاب ، أنت تشكو من كل ما لا يرتبط مباشرة بـ "jabbing code": حول الحاجة إلى إضافة تعليقات ، قم بتغطية الكود باختبارات البلوك وفقًا للمعايير المحددة في الشركة أو القسم ، ودمج فروع المستودع ... ماذا يمكننا أن نقول عن أشياء أكثر تعقيدًا تتطلب متطورة أو مؤهلة حقًا: اختبار التشغيل الآلي ، ودعم ودعم التكامل المستمر ، وإنشاء حزم Bamboo-Cucumber-Maven-Puppet ، وساعات طويلة من الحفر في سجلات النظام في البحث دليل على وجود أخطاء في البرنامج - كل هذا بالنسبة لك هو الملل والتقليد الذي لا يسمح لك بتحسين مهارات الترميز الخاصة بك مباشرةً والتي تجد أنك تستخف بها في الأسئلة الشائعة. علاوة على ذلك ، برفضك استخدام أجهزة معينة ، فأنت غالبًا ما تخفي ببساطة عدم قدرتك على استخدامها. أتذكر رد فعل ووجه أحد المبرمجين ، كمحاولة للكشف عن عيب "عائم" يصعب العثور عليه ، اقترح استخدام ملف تعريف مدمج في IDE: قيل لي إنه ليس من مهام كلب مدير المشروع تقديم المشورة للأدوات التي ينبغي للمبرمج استخدامها في عمله.
مهارات الأداة
كيف الآلي هو عملك داخل محطة العمل الخاصة بك؟ هل ضخت مهاراتك في العمل باستخدام التعبيرات المعتادة ، وإنشاء ملفات دفعية وتنفيذها؟ بناءً على طلب أحد الزملاء أو المختبرين أو المحللين أو العملاء ، هل يمكنك تحليل بضع مئات من أسطر السجلات على خادم بعيد في 3 دقائق ، والعثور على الإدخال الضروري للمعلمة الرئيسية ، وحزم المخرجات ، وإعادة توجيهها إلى العنوان المحدد والعودة إلى المهمة التي تمت مقاطعتها؟ كيف بسرعة ، الطين ، هل تعرف كيفية إجراء العمليات الروتينية التي تتطلب التكرار المتكرر خلال يوم العمل؟
كما تعلمون ، يمكن بدء التجميع في بيئات التطوير الحديثة عن طريق الضغط على F5 (أو F6؟ أو F13؟ .. في النهاية ، لماذا أحتاج ، كمدير للمشروع ، إلى معرفة مثل هذه الأشياء؟ لا تعرف يا MUD ، بالسرعة ، خلال دقيقتين قم بالتفريغ من Jira ، وقم بتنسيقه بشكل صحيح في Excel ، وأرسل بريدًا إلكترونيًا إلى العميل حول تقرير العيوب باستخدام
blackjet والمخططات والاتجاهات
العاهرات ، لكنك لن تفشل أبدًا في تثبيت "piem" في غرفة التدخين بين زملائك على أنه ليس من الغباء يعرف كيف يختلف المدمر عن المنشئ). لكن بالنسبة لمهنة طويلة إلى حد ما ، لم أقابل الكثير من المبرمجين الذين يستخدمون اختصارات لوحة المفاتيح على لوحة المفاتيح لاستدعاء بعض الإجراءات القياسية - معظمهم يستخدمون مناور الماوس الأبطأ في هذا. شرطي "Tab - 1000 - علامة تبويب - 1 - علامة تبويب - 0 - علامة تبويب - مسافة للخلف - 2 - Ctrl + S - Ctrl-F6 - Enter ، و Alt-Tab ، و F5" في 6 ثوانٍ ، يسمح للمحترف الحقيقي بالقيام بما يفعله عن طريق النقر بالماوس والدس بأصابع الفهرس على لوحة المفاتيح ، يعمل البطيء خمس دقائق طويلة. وعندما يتم تنفيذ هذه العمليات مئات المرات في اليوم ، في سياق اقتراب الموعد النهائي ، يريد مدير مشروع آخر في بعض الأحيان
أن يأخذ و ...... نقل مثل هذا "احترافي" بعيدًا عن لوحة المفاتيح وإجراء تغييرات / ترجمة / وضع التعليمات البرمجية القابلة للتنفيذ وإعطاء الضوء الأخضر لمجموعة الاختبار البنية الجديدة جاهزة أخيرًا.
لذلك ، MUD ، لا تكون كسولًا وقضاء وقتًا في إتقان الطباعة العشرية الأعمى وأساليب العمل الفعال بالأدوات وتعتقد أشخاصًا أكثر خبرة ، حتى لو كان بعضهم غير محبوبين من قِبل مديري المشاريع - هذه المرة ستؤتي ثمارها جيدًا. في غضون ذلك ، أنت ، شاب شاب أخرق ، لم تصل إلى الكمال في هذا - اذهب ودفن نفسك في الشاشة واكتب الرمز ، Bl ..!
تقييم العمل
لا يمكنك الوقوف عندما يتدخل مدير المشروع في العملية المقدسة المتمثلة في "كتابة التعليمات البرمجية". ولكن في الوقت نفسه ، لن تحرم نفسك أبدًا من سرورك بإعطاء تعليق كافي حول المواعيد النهائية "غير الواقعية" ، والمتطلبات "المتسربة" ، وطلبات التغييرات في الوقت المناسب ، ومديري المشاريع غير الأكفاء. عندما يلجئون إليك ، في إطار منهجية معينة ، للحصول على رأي خبير بشأن تقييم تكاليف العمالة للتكرار التالي أو للمشروع بأكمله ، فإنك تجعل وجهًا مفاجئًا وتبدأ في "تقديم أعذار" بشأن المواصفات غير المفهومة أو غير المكتملة ، والتكنولوجيات غير المعروفة ، وهذا ليس عملك على الإطلاق للتخطيط ، ليس لديك وقت لـ "هراء" وأنه من الأفضل أن تذهب وتفعل الشيء الحقيقي - كتابة التعليمات البرمجية. "تقدير تكاليف العمالة حسب طريقة النقاط الوظيفية؟ عن طريق القياس بناء على النتائج السابقة؟ بناءً على عدد نماذج الشاشة وطلبات الإدخال / الإخراج لقاعدة البيانات؟ لا ، لم اسمع! "
لذلك ، أيها الصديق الشاب ، إما أن تبقى هادئًا عندما لا يكون عملك هو العمل في المشروع ، أو تحسين مهاراتك في إصدار تقييمات خبراء حقيقية ، وليس بإصبعك في السماء. وحتى تتقن آخر -
IPKB !
كود هندوسي
أحد وسائل التسلية المفضلة لديك هو انتقاد رمز البرنامج الذي تم إنشاؤه بواسطة المطورين الهنديين. لا تطعم الخبز ، ولكن فقط دعنا نسخر من أسلوب "المعكرونة" في البرمجة. أكثر من مناقشة الكود "الهندوسي" ، فأنت تحب الدردشة حول التكنولوجيا (انظر أدناه). وكل هذا على الرغم من حقيقة أنك تطلق على نفسك اسمًا فخورًا باسم kolbasa () ، قم بنسخ أجزاء من الشفرة لا تنسى إلى أماكن مختلفة في البرنامج وإنشاء فئات بحجم عشرات أو شاشتين.
بسبب عدم كفاية تجربتك المهنية الخاصة بك ، MUD ، أنت لا تدرك أن
القرف الذي تكتبه بنفسك في كثير من الأحيان ليس أفضل ، وأحيانًا أسوأ من الكود الذي ينشئه زملاؤك الجنوبيون. يوجد مبرمجون محزنون في أي بلد ، "لا نحكم ، لا نحكم علينا" ، والمحترفون الحقيقيون ، وسأخبركم بسرية ، MJD ، لا تتراجع عن تعبير زملائهم على أساس وطني ، وتعمل على تحسين مؤهلاتهم ووقتهم ببطء ، المخصص لإنشاء منتج برنامج ، ينفقون بشكل مباشر على البرمجة ، وليس على البحث عن
قش في عيون الآخرين في عيب في رمز شخص آخر.
مناقشة التكنولوجيا التي لا نهاية لها
أنت تناقش بلا نهاية مع المبرمجين الآخرين ما هو Java ++ المتفوق على C ## أو ما هو رقم الإصدار مائة وتسعة وعشرون جزء من أي مكتبة Javascript أفضل من الإصدار مائة وتسعة وعشرون جزء ثلاثة عشر. لن تشعر بالأسى أبدًا لهذه المناقشات حتى في تلك الأيام التي تظل فيها 2-3 أيام أو أسابيع قبل نهاية التكرار أو مشروعًا لعدة أشهر ، ويزيد عدد العيوب الخطيرة غير المصححة المخصصة لك عن خمسين.
يمكنك القيام بذلك دون وخز الضمير أثناء ساعات العمل ، وليس في ليالي الجمعة أو في عطلات نهاية الأسبوع لتناول كوب من البيرة. أنت منخرط في مثل هذه الثرثرة على الرغم من أن مسألة اختيار واستخدام تقنية أو أخرى في منتج ما تقع خارج نطاق اختصاصك (لأن حجم اختصاصك ، MJD ، لم ينمو بعد) ، لكنك لا تزال تقضي وقتًا مع صاحب العمل و مشروع على trepot غير منتجة.
الأنين حول المسيرات "غير الضرورية"
لذلك ، عندما
قضيت للتو
وقتك في التحدث ، تحدثت لمدة ساعتين في غرفة المطبخ / التدخين مع نصف دزينة من نفس المبرمجين
الخراء حول أحدث مؤتمر / مؤتمراً صحفياً / إطار عمل Google-Microsoft-Apple-Linus Torvalds أمس ، بدلاً من سرقة زوجين - أيام من التطوير ، فجأة ، عند تحليل التكرار المكتمل ، تعلن أن عددًا كبيرًا جدًا من الاجتماعات غير الضرورية تعقد في المشروع وتحتاج إلى تقصيرها - ردًا على هذا ، فأنت تريد أن تصيح بشيء واحد فقط: اخرس و
IPKB !!!
تعلم الروسية
حسنًا ، في النهاية ، كما يقولون ، الأخير ، لكنه بعيد عن الأكثر أهمية. , , , C## — - ( - , XXI ). , , , -
— , ..! ,
_ — , .
tsya.ru , «» — , "
" «» — , «
», ..!!111
خاتمة
, , , , , . ! , , , - ,
.
: ? , , , .
, , , . , - 10 . 3 , , , , , “” 3 .
: 1 3 3 1. , . , “
” ( “”). , , , , , .
“
” , , , “”, , . , , , , “, , , , , XYZ , , ( / / )!”.
, “”, “
”, , : , , , , ( ), “”.
.