اليوم هو يوم مشمس. أنت تقود السيارة على طول الطريق المؤدي إلى قريتك حيث يعيش جميع أصدقائك وعائلتك وكلبك الحبيب. يوم رائع! فجأة تسمع صرخة فظيعة مروعة تمزق المحيط. هيدرا مثيرة للاشمئزاز ضخمة تقترب من القرية لتدميره! انت تمسك سيف (بالطبع ، لديك سيف!) ومحاولة حماية كل من تحب. ولكن هناك مشكلة صغيرة: الوحش لديه العديد من الأهداف ، وعندما تقطع أحدها ، ينمو هدف جديد بسرعة!
يبدو أنك لا تستطيع الفوز بهذه المعركة. ربما يمكنك أن تلعب مع هيدرا لفترة كافية بحيث يكون للقرية بأكملها الوقت لتطير بعيدا عن تهديد رهيب؟ وأخيرا ، سوف تصبح بطلا حقيقيا للعالم كله! من لا يريد هذا؟
دور Hydra هو الانتروبيا في البرنامج: إنه عدوك ، إنه مرهق لك ، لكن لا يمكنك التخلص منه أبدًا. ولكن لا يزال يتعين عليك القتال معه حتى تظل تطبيقاتك (وزملائك) في صحة جيدة وعقلانية.
سنكتشف:
- ما هو الانتروبيا في البرنامج وكيفية ملاحظته في الكود.
- ما هي أسبابه المحتملة وكيفية الحفاظ على انخفاض الكون.
الحديث بما فيه الكفاية ، إلى هذه النقطة!
تعرف عدوك
ما هو الانتروبيا وكيف انتهى بي الأمر في طلبي؟
من المفيد في بعض الأحيان معرفة أصل الكلمات المستخدمة ، خاصة تلك المحددة مثل إنتروبيا. ترجمت من اليونانية ، وهذا يعني "التحول". التغيير. شيء يجب أن تعتاد عليه كمطور برامج.
الانتروبيا يشير إلى القانون الثاني للديناميكا الحرارية. تقول أنه في نظام مغلق ومعزول ، لا تقل كمية الفوضى بمرور الوقت. يبقى مستقرا أو متزايدا.
جاءت فكرة الانتروبيا في البرمجيات من خلال كتاب
هندسة البرمجيات الموجهة للكائنات . كلما تغير البرنامج ، زاد عدد الفوضى ، زاد الانتروبيا.
أول ما يحتاجه المطورون الفقراء لتوضيح لنا هو الحقيقة المأساوية: يمكننا محاربة مقدار الانتروبيا في برامجنا ، لكن لا يمكننا التخلص منها أبدًا.
قم بإنشاء أفضل فريق (بمشاركتك ، بالطبع!) ، أفضل بيئة ، أفضل إدارة ، أفضل ثقافة في الشركة ، أفضل مشروع. ماذا سيحدث مع مرور الوقت؟
- سوف تهمس كل صباح ، "هذا هو أفضل مشروع!" مشروع أخضر يبدو كحقل جميل ، مضاء بواسطة شروق الشمس الرائع.
- ستقوم أنت والفريق بإضافة المزيد والمزيد من الميزات. نظرًا لأنك الأفضل من الأفضل ، فكل شيء يبدو رائعًا.
- أشهر أو سنوات سوف تمر. لا أحد يريد العمل في مشروع بعد الآن. حتى لو تم تصميمها جيدًا ، فقد عفا عليها الزمن ، يتطلب المشروع الكثير من الجهد والوقت لفهمه ، وهو مكلف للغاية. من الصعب للغاية بناء نموذجه العقلي الجيد.
كيف خلق هذا التعقيد؟ تحتاج فقط إلى توسيع نطاق المشروع. أكثر العناصر غالبا ما تعني المزيد من التبعيات وتعقيد أعلى. لقد كتبت بالفعل مقالا
مفصلا حول هذا الموضوع.
إذا قمت بشرح هذا ليوكا ، زميلك المطور ، فسوف يجيب:
"Nifiga! هل أنت مجنون الفوضى والاضطراب ليس لهما مكان في تطبيقي الجميل! لن تشوه سمعتي من قبل بعض الهراء! أنا سيد مصيري! إذا لم أغير برنامجي ، فلن ينمو التعقيد ، وفيما يتعلق بهذا الدليل على التناقض ، أعلن أنك مخطئ ، وأنا أفضل! "
يمكنك أن تشرح بهدوء وإقناع وحزم لـ Lyokha أنه حتى لو لم تقم بتغيير البرنامج ، فسيتغير كل شيء من حوله. إذا كانت لديك مكتبات تابعة لجهات خارجية لا يتم تحديثها ، فستحدث مشكلات أمنية. وإذا قمت بتحديثها ، فسوف تفتح الباب للتغيير والانتروبيا.
علاوة على ذلك ، إذا كنت
بحاجة إلى تغيير شيء ما في البرنامج يومًا بعد وقت طويل ، فلن تتذكر كل التفاصيل. وحتى أفضل الوثائق لن تساعدك. لقد تغير العالم ، وما كان صحيحًا بالأمس قد لا يكون حقيقيًا ، سواء على المستوى التكنولوجي أو على مستوى الأعمال.
هذه التغييرات في وقت واحد تجلب كمية كبيرة من الانتروبيا.
لذا فإن السؤال ليس في التخلص منه ، بل في الاعتدال. هذه معركة حقيقية نطرحها نحن المطورين.
تعريف الانتروبيا في البرمجيات
جودة البرمجيات
كيف تعرف أن التطبيق الخاص بك يحتوي على مستوى عال من الانتروبيا؟ مؤشر جيد هو جودة الكود.
ما هو وكيفية قياسه؟ وفقا
لتسريع: العلم وراء Devops :
- إذا زادت نسبة التغييرات / الإخفاقات ، تنخفض الجودة. تتبع التغييرات ، والأخطاء والتعطل ، قارنها مع بعضها البعض. إذا أدى كل تغيير إلى حدوث أعطال أو أعطال جديدة ، فسوف تزداد الإنتروبيا في البرنامج.
- لعبت دورا هاما من قبل التصور الشخصي للمشروع من قبل المطورين. إذا كان لدى الجميع شعور بأنه أصبح من الصعب على نحو متزايد توسيع نطاق التطبيق دون كسره ، فربما تكون الانتروبيا مرتفعة. ومع ذلك ، يجب أن يكون هذا الإحساس شائعًا.
- إذا كان الفريق يقضي وقتًا طويلاً في إصلاح الخلل أو التعافي من حالات الفشل ، فيجب أن تكون الإنتروبيا قد صنعت عشًا في تطبيقك.
إذا كنت تستطيع الحصول على بعض المعلومات حول نسبة التغييرات والإخفاقات ، وقضاء بعض الوقت في إصلاح الخلل ، فيمكنك التوصل إلى جدول جيد لإقناع الإدارة بالحاجة إلى نوع من إعادة البناء.
شيطان الصعوبة
حتى إذا كان لديك رمز من أعلى مستويات الجودة ، يمكن أن يزيد التعقيد بسهولة عندما يتعلق الأمر بقدرات البرنامج ذاتها. النشاط التجاري بحد ذاته هو مصدر
التعقيد الضروري الذي لا يمكنك التخلص منه.
بالنظر إلى التعقيد المفرط للعمل ، سيتعين على المطورين بذل الكثير من الجهد لبناء
نموذج عقلي جيد لأعمال الشركة. لذلك ، سوف يرتكبون أخطاء في محاولة ترجمة متطلبات العمل إلى رمز.
دعونا نتحدث بمزيد من التفصيل عن مدى تعقيد العمل: هل نحتاج حقًا إلى كل هذه الميزات المعقدة التي تخذلنا؟
سبب الانتروبيا ، وكيفية التعامل معها
انتروبيا الشلال
المشكلة
أكثر أو أقل وضوحا ، السبب الرئيسي للانتروبيا في البرمجيات هو للمطورين أنفسهم. إنهم كسولون ، يفتقرون إلى المؤهلات ، خاصة سانكا ، الذين تعمل معهم. يسأل الكثير من الأسئلة!
أنا أعارض بشدة هذا الرأي. في تجربتي ، السبب الرئيسي للانتروبيا هو القيادة ، خاصة في الشركات التي لديها أسلوب لإدارة الشلال.
كما لاحظ
جيرالد وينبرغ في
سر الاستشارات :
حتى إذا كانت هذه مشكلة فنية بحتة ، فيمكن دائمًا تتبع أصلها إلى العمل أو تقاعس الإدارة.
أنا أعرف ما كنت تعتقد: "أنت مخطئ! الإدارة ليست دائما مسؤولة عن كل شيء! إنه من المناسب للمطورين أن يلوموا الرؤساء على كل شيء! "
أنا لا أقول أن القيادة هي المسؤولة عن كل شيء ، لكنه دائمًا ما
يتحمل قدرًا من المسؤولية . هل قام المطور بعمل شيء سيء؟ تحتاج إلى مراجعة عملية التوظيف. تم تنفيذ مواصفات سيئة؟ ربما لا يعرف بعض القادة ما يريدون حقًا ، وبالتالي فإن المواصفات لا تهمه.
لذلك ، من الصعب جداً أن تكون قائداً! كلما كنت في التسلسل الهرمي ، كلما كان الأمر أصعب.
كمطورين ، إلى أي مدى تؤثر على صنع القرار؟ إذا 100 ٪ ، ثم تهانينا ، أنت المسؤول عن كل شيء. إذا كان عند 0 ٪ ، ثم خطأك ليست كذلك. بين هذين القطبين يكمن الطيف الكامل للتأثير. والشلال لا يعني وجود عدد كبير منه.
باستخدام Scrum و Kanban و Poker Planning؟ بالطبع أنت لا تستخدم الشلال! يمكنك استخدام Agile تمامًا مثلما يقوم الطفل ببناء منزل به مفك البراغي.
بالطبع ، الأدوات مهمة ، لكن أهميتها
أقل بكثير من أهمية طريقة تفكيرك ، وهي ضرورية لتطوير البرمجيات الصحيح. لاقتباس بيان Agile:
الشخصيات والتفاعلات أكثر أهمية من العمليات والأدوات.
لا يعني استخدام Scrum أنك تستخدم Agile ، خاصةً إذا لم يكن لديك طريقة للتفكير بأن هذه المنهجية تحاول التدريس.
مع إدارة الشلال ، يقوم شخص أعلى منك باتخاذ قرار ، وأعلى ، وأشخاص آخرون يتخذون قرارات جديدة ، وما إلى ذلك.
في المستويات الأدنى من التسلسل الهرمي ، هناك موظفون لعنتهم هي اتباع جميع القرارات المتخذة. ما هي مهمتهم؟ لجعل ، كما لو العمال على خط التجميع من مصنع للسيارات. لا يحتاجون إلى التفكير ،
بل يجب عليهم صنع سيارات .
الأخبار السيئة: كمطور ، سوف تكون في أسفل التسلسل الهرمي.
إذا اتخذ شخص ما في القمة قرارات بشأن وظائف التطبيق ، ولم يكن لديك عملياً فرصة للتأثير على عملية صنع القرار ، فمرحباً بك في الشلال! لسوء الحظ ، لا ترى الإدارة العليا في الغالب أنه
في عالم تطوير البرمجيات لا توجد مرحلة إنتاج . يشارك المطورون في
تصميم النظام ، وهذه المهمة بعيدة كل البعد عن تجميع ناقل المقصورة.
لماذا؟ لأنه ، على عكس السيارة ، تتغير التطبيقات باستمرار! تحتاج إلى
تصميمها بشكل صحيح بحيث تعمل ، وتفي باحتياجات المستخدمين ، وأن التطبيقات لها أداء مقبول ، وأن تكون قابلة للتطوير ومقاومة للتغييرات ، مع الحفاظ على الانتروبيا على مستوى منخفض. للقيام بذلك ، تحتاج إلى اتخاذ العديد من
القرارات حول كيفية
التعبير عن المعرفة التجارية في التعليمات البرمجية الخاصة بك.
إذا لم تؤثر على التعقيد الذي تنزل به القيادة لك ، فسيتعين عليك إنفاق الكثير من الجهد في إدارتها في الكود. سيعتبر هذا تعقيدًا "ضروريًا": تعقيد لا يمكن تجنبه.
النتيجة المحتملة؟ يمكن أن تنمو مستويات الانتروبيا بسرعة كبيرة جدًا.
حل ممكن
تحتاج الشركة إلى ممارسة اتخاذ القرارات المشتركة والمسؤولية بأكبر قدر ممكن من النشاط.
إذا كنت تتعرف على شركتك في نموذج الشلال الذي وصفته ، فأنت بحاجة إلى التحدث مع من يتخذ القرارات:
- قدم بيانات وحجج قوية عن سبب وكيفية تبسيط الميزة X أو Y. وضح السعر المحتمل لتطوير ميزة معقدة الآن وفي المستقبل .
- اشرح لماذا تطوير البرمجيات Agile يعني أن الناس بحاجة إلى العمل معًا. يجب أن يكون المديرون والمصممون والمطورون وكل شخص آخر جزءًا من عملية صنع القرار وفقًا لمتطلبات العمل.
- إذا رفضت قيادتك العرض تلقائيًا ، فأنت بحاجة إلى فهم السبب وراء ذلك. طرح الأسئلة.
- تحدث عما يعتبره صناع القرار الأكثر أهمية: المال والوقت. أظهر لهم أن التفكير في أسلوب Agile (وليس الأدوات فقط) يمكن أن يوفر لك كليهما.
ومع ذلك ، من الصعب محاولة حل المشكلة إذا لم يتم سؤالك عنها. كثير من المديرين سعداء للغاية بنموذج الشلال ، وغالبا ما لا يعرفون أنهم يتبعونه. سوف تحتاج إلى الكثير من الدبلوماسية واللباقة.
بالنظر إلى كل هذا ، إذا كنت تشعر أن حلول الأعمال تضيف الكثير من التعقيد إلى التطبيق الخاص بك ، وأنه لا يمكنك فعل أي شيء حيال ذلك حتى لو حاولت ، فإني أنصحك بالعثور على وظيفة أخرى. إنه أمر مرهق - العمل مع الانتروبيا العالية كل يوم ، وجعل منتجة منتفخة من المتعة ليست كافية ... أو استخدامها. قد يعطيك هذا تلميحًا بشأن النجاح الذي يتوقعه منتجك.
والأخير: ما يمكن أن يبدو معقدًا على مستوى الأعمال التجارية يمكن تبسيطه إذا كنت تعرف العمليات التجارية جيدًا. هذا مهم للغاية. لذلك ، تعرف على المزيد حول أنشطة شركتك وما الذي يقومون به وما الذي لا يقومون به ، مما سيساعد في تبسيط الميزات وقاعدة الكود.
بينما نعبر عن هندستنا المعمارية ، نوضح شيئًا للكمبيوتر. ولهذا نحتاج أن نفهم جيدًا ما نوضحه.
دونالد سوطرمز الجودة والواجب الفني
المشكلة
بالإضافة إلى التعقيد "الضروري" الذي أدخلته الشركة ، يرتبط الانتروبيا في البرنامج ارتباطًا وثيقًا بجودة الشفرة والديون الفنية.
ما هو الدين الفني؟ ببساطة ، هذه عبارة عن تبسيط (اختراقات) تستخدمها لتوفير الوقت ، مع العلم أنه في وقت لاحق يمكن أن يرجع إليك هذا. خاصة في الحالات التي تعتمد فيها الميزات الأخرى على هذه الاختراقات: سيتعين عليك إصلاحها باهتمام ، كما هو الحال مع الديون الحقيقية ، في شكل صعوبات وصداع.
بناءً على مهمة طلبك ، قد يكون الدين الفني مقبولاً إلى حد ما. إذا كان يجب أن يعيش البرنامج شهرين ، فلا يمكنك التفكير في الدين الفني أو الانتروبيا أو الجودة على الإطلاق. مجرد وضع القطع من التعليمات البرمجية معا والانتهاء من ذلك!
على سبيل المثال ، قد يكون هذا حلاً مؤقتًا قبل إنشاء تطبيق أكثر تعقيدًا من البداية. أو حتى يمكنك كتابة نموذج أولي بسرعة لتوضيح الفكرة ، ثم إعادة كتابة كل شيء أو التخلي عن المفهوم.
من ناحية أخرى ، عادة ما ترغب الشركات في تطوير تطبيقات طويلة العمر. هذا معقول: إعادة كتابة التطبيق يمكن أن تكون مكلفة للغاية (خاصةً إذا كانت كبيرة) ، ولا يمكن لأحد أن يضمن أن مستوى إنتروبيا سيكون أقل. النسخ هو عمل محفوف بالمخاطر للغاية.
في مثل هذه الحالات ، يجب أن تكون حذراً للغاية فيما يتعلق بالواجب الفني وجودة الرمز. هذا جزء مهم من عملك كمطور.
في الكتاب الشهير
The Pragmatic Programmer (حيث ، من بين أشياء أخرى ،
يتم تقديم
مبدأ DRY ) ،
يتم تقديم تشبيه مثير للاهتمام بالدين الفني. يوصف هنا دراسة تقارن تدمير المباني الحضرية مع ... النوافذ التي خرجت منها. يعطي الإطار المكسور انطباعًا بالتخلي عن نفسه ، مما يلهم كل تنمر في المنطقة. نتيجة لذلك ، يتم تخريب المباني ذات النوافذ المكسورة بشكل أسرع من المباني ذات النوافذ بأكملها.
الدين الفني هو تبسيط أو اختراق في التعليمات البرمجية الخاصة بك ، نافذة مكسورة. عندما يلاحظ ذلك مطور آخر ، أو حتى أنت نفسك في المستقبل ، سيكون هناك إغراء لإضافة المزيد من الديون الفنية ، لأنه "لا يزال هناك رمز سيء هنا ، فلماذا تأخذ حمام البخار؟"
مثال: لقد كتبت حلاً لخلل معقد واحد ، لأنه لم يكن هناك وقت للبحث عنه. قد يقوم مطور آخر (أو أنت نفسك لاحقًا) في مقدمة هذا الحل البديل بكتابة تعليمات برمجية مختلفة ، لحل مشكلة أخرى. ستنمو طبقات الحلول التي لن يعرفها أحد بسرعة كبيرة.
قرار
أولاً ، كيف يمكنك معرفة ما إذا كانت الكود لديه دين تقني؟
اسأل نفسك:
- هل يمكنني ببساطة وشرح منطقي ما يفعله الكود؟
- هل الأسماء الصحيحة مستخدمة هنا؟ هل يساعدون في شرح ما يفعله الكود؟
- هل الأسماء الطويلة مع "و" تنطبق ، مثل "deleteUserAndShutDown"؟ هذه علامة جيدة على أنك تحتاج إلى فصل وظيفة أو طريقة أو أي بناء آخر.
- هل تشعر وكأنه تمت إضافة بعض الرموز بسبب الكسل؟ هل ينتهك المنطق ويضعف الفهم؟
كلما زادت معرفتك وتجربتك ، زادت فضولك ، وفي كثير من الأحيان كنت تجري مناقشات صحية مع المطورين الآخرين ، كلما لاحظت أنماط الدين الفني أكثر. هذا هو
رمز مع الاختناق .
عند مواجهة هذه الأنماط ، يرجى عدم اعتبارها إذنًا لإضافة المزيد من الديون الفنية:
- زيادة في التقنية طويلة تؤدي إلى مشاكل جديدة. سيعودون وسيتبعونك (وفريقك) أكثر.
- بعد أن واجه الديون الفنية ، refactor ذلك. هذا هو الخيار الأفضل. إذا لم يكن لديك الوقت أو الطاقة ، فما عليك سوى إضافة تعليق // TODO: refactor لهذا السبب وهذا السبب. الإبلاغ عن مشكلة ، لا تتركه مخفيًا في قاعدة الشفرة.
لا تنسى أنك تحتاج إلى إعادة تكوين رد الفعل بالتوازي مع تطوير الميزات الأخرى بحيث تتوافق مع البنية الحالية. ببساطة ، لا ينبغي أن يكون إصلاح الديون الفنية مهمة مستقلة ، ولكن عملية مستمرة قد لا تكون ذات صلة بالمهمة الحالية. عند تطوير ميزة ، أعط لنفسك الحق في تصحيح الدين الفني الذي واجهتك.
Refactor أجزاء صغيرة من التعليمات البرمجية في وقت واحد وغالبا ما تقوم بإجراء اختبارات للتأكد من أن النظام يتصرف كما هو متوقع.
أخيرًا ، أثناء إعادة البناء ، قد تحتاج إلى بعض الحجج الجيدة:
- أولا ، لنفسك. من السهل أن تعتقد أن زميلك غير قادر على البرمجة وأنك تعرف أفضل من الآخرين. ولكن إذا كنت لا ترى الفوائد المحددة لإعادة البناء ، فلا ترى ذلك. ربما يكون الأمر برمته في الأنا فقط ، ويمكنك تدمير شيء ما.
- إذا كانت إعادة التنظيم متعلقة بنمط الكود ، فهذا يعني أن فريقك لم يحدده بوضوح . قم بعقد اجتماع وحدد معًا نمط الرمز الذي تريد تبنيه. يجب كتابة هذا في مكان ما ، بحيث يمكن للجميع التعامل مع الحاجة. تحرير الاتفاق وفقا لاحتياجات الفريق. خلاف ذلك ، سيتم ملء التعليمات البرمجية الخاصة بك مع تعليقات مثل "نستخدم علامات التبويب !!! لا مسافات !!!!! 11! 1 !!! ". هذا هو الضوضاء عديمة الفائدة.
- أخيرًا ، إذا سألك أحدهم عن سبب قيامك بتغيير رمزه الجميل ، فستكون لديك حجج حقيقية لشرح قرارك.
تلعب الحجج الجيدة دائمًا دورًا إيجابيًا في المستقبل. على سبيل المثال ، لف مكتبة خارجية حتى لا تتسبب في حدوث تسرب في قاعدة التعليمات البرمجية الخاصة بك. إذا كنت لا تفهم لماذا أتحدث عن تسرب ، فاقرأ ما
كتبته عن التجريدات .
يصعب علينا نحن البشر وضع توقعات على المدى المتوسط والطويل. لذلك ، ليس من السهل دائمًا إعادة بناء الأشياء أو "بيعها" بعين لمستقبل مجهول.
. , .
, . .
, , , , , . , , . .
. ,
, . , .
,
. , , .
: . , , . . , .
المشكلة
- , : .
? , , . , , . , , — .
.
:
NASA (. 5) .
, , ,
.
, , .
. .
, , — , . ? , . , , ( ), , - .
, : ,
. ,
.
, .
قرار
, , , .
.
- 1,3 . , . «» .
:
, , - ( ), :
- . , , .
- . , , - .
- . — , .
- , - . , - . !
- , . !
,
.
, . , . , .
, , .
.
, , . , , - .
, , . , , :
, . , . . , , , - , .
— , .
, .
,
:
. , , .
?
— . - , . , .
هذا كل شئ! , .
, , .
, , : « , , ? , . !».
: , . , . , .
, , , . , , . !
. :
, . , . , , .
, , . ?
, . , , .
:
- , . «, ?» — , « ! ! !».
- , . , , , , . «, , ?» « , 289 ».
, . ,
!
( !) .
. , , .
, — , , . !
!
, , , ,
. ? ? - ? ?
. , . -, . , , , .
, , . . — .
هكذا. ?
- — . . , .
- — .
- . / .
- , , .
- , . , .
- خلق جو يسهل تبادل المعرفة مع بعضهم البعض من خلال البرمجة المشتركة أو تحليل الكود أو ببساطة وضع روابط لمصادر مثيرة للاهتمام للمعلومات (مقالات ، كتب).
البرنامج المثالي غير موجود. سيكون Entropy دائمًا جزءًا من عملنا. هذا لا يعني أننا فقدنا بالفعل هذه المعركة. هذا يعني أن تقليل الانتروبيا في قاعدة الشفرة بأكملها هو بالفعل انتصار!روابط مفيدة: