المطور يوميات أو قرارات سيئة

الصورة



من الغد نبدأ في العيش بطريقة جديدة. سيكون لدينا سكروم وسيكون هناك سعادة. ديمقراطية كاملة: لا يوجد رؤساء ، يقرر الفريق ما يجب القيام به ، يتم إلغاء البيروقراطية ، الشيء الرئيسي هو القيام بعمل جيد للعميل.

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

حسنا حسنا. انتظر وانظر.



نبدأ مشروع جديد. حسنًا ، الحمد لله!

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


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

اسألها سؤالًا بسيطًا ، لذا تبدأ خطابًا لمدة نصف ساعة. أنت تنظر إليها وتفكر: "آه ، أنت لا تفهم شيئًا ملعونًا!"

بعد خمس دقائق ، تبدأ في الشك: "لا ، يبدو الأمر كما يقول".

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

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

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



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



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

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



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

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

التقيت بهم في الممر بعد نصف ساعة: كان كوليا يمشي ، وكانت الفتيات تتابعه ، وكان الجميع يتلاعبون: "نموذج جديد ... نموذج قديم ... متطلبات العملاء ...".

الفقراء ...



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

أنا أسأله:

- ماذا يعني هذا المعامل؟
"وهذا ،" يقول ، "لقد التقطت". الآن كل شيء سيكون على ما يرام.

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

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



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

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



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

من الجيد ألا نبني طائرات ...



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

فجأة يقفز Vruma سيدهم scrum وكيفية الصراخ لشخص ما:
- ماذا تكتب لي كل شيء! قلها شفهيا!

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

وقفت لدقيقة ، وسعلت ، وصمت الجميع وحدقوا بي. شعرت فجأة بعدم الارتياح.

فيكتور يقول:

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

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

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



جمعنا الرئيس اليوم ويقول:

- يجب أن يكون لدينا ملحمة. نحن نريد أن نقدم التعلم الآلي لتخصيص نتائج البحث.

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

- لا يوجد وصف كامل حتى الآن ، وسأرميك روابط إلى ما هو. فكر الآن ، - الإجابات. واليسار.

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

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


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

Vitya ينظر بعيدا ويقول:

- لا ، لم يتم العثور حتى الآن. لا يوجد ما يكفي من الوقت على الإطلاق ...

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

نعم ، هنا تحولت بوابتنا الجديدة إلى كرة ضيقة من المعكرونة ، ومن المستحيل بالفعل العثور على النهايات. بسرعة ، تمكنا!


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

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



أعترف: اخترعت هذه اليوميات. جميع الشخصيات وهمية ، والصدف عشوائية. هذه مجرد مزحة.

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

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

تضارب المصالح


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

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

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

ماذا تفعل؟

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

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

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

هل النجاح ممكن؟


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

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

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

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

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

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

ما هو أكثر أهمية: جودة المنتج أو مهارات البيع؟


منتج عالي الجودة ، للأسف ، ليس ضمانًا للنجاح.

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

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

قرارات سيئة


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

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

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

قواعد التراخي


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

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

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

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

انتهاك القواعد


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

الاستعداد للمشاكل في النظام الخاص بك والتي سوف تحدث في أماكن غير متوقعة.

إعدادات التعقيد


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

عدم تحليل المشكلة


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

القرارات السياسية


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

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

الخاتمة


, . , . . , , . , . , , , , , .

. , , , .

, , . , , , .

!

Source: https://habr.com/ru/post/ar438992/


All Articles