كيفية تجنب التعقيد العرضي في تصميم البرمجيات

أندرو ساردوني
نائب رئيس الهندسة ، باختصار

"هناك مشكلتان صعبتان في علوم الكمبيوتر: إبطال ذاكرة التخزين المؤقت ، تسمية الأشياء ، والأخطاء الفاصلة." - ليون بامبريك

في عام 1986 ، نشر مهندس الكمبيوتر فريد بروكس ورقة بعنوان "No Silver Bullet" ، لاحظ فيها أن هندسة البرمجيات لا تنتج نفس المكاسب الإنتاجية مقارنة بهندسة الأجهزة.

جادل بروكس أنه عندما يتعلق الأمر بصنع البرامج ، كان هناك عائقان رئيسيان يجب التغلب عليهما: التعقيد العرضي والتعقيد الأساسي.

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

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

بينما يشير Brooks إلى التعقيد وكيفية ارتباطه بالصياغة وتغيير الكود ، فإنه ينطبق على المنتج النهائي أيضًا.

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

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

الرمز الخاص بك هو منظمتك

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

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

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

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

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

لا مكان للأبطال

هناك طريقة أخرى للحد من التعقيد العرضي وهي الحد من عدد "أبطال الفريق" قدر الإمكان.

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

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

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

قوة التركيز

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

لكن الشيء الذي نفعله هو الذي له أكبر الأثر هو مجرد تضييق الخناق على أهم شيء.

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

واحدة من القيم الأساسية ل Nutshell هي التركيز. في دوري ، يعني ذلك إيجاد أوسع تداخل بين الأشياء الأساسية التي يجب أن يقوم بها البرنامج وقول "لا" للأشياء التي تقع خارجها.

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

فكّر في كيفية تسويق شركة: لا يُفترض أن يكون لمراسلتك صدى مع كل إنسان على الإطلاق - عليك اختيار الأسواق والشخصيات المستهدفة التي من المرجح أن تستخدمها وتستفيد منها.

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

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

تم نشر هذه القصة في The Startup ، أكبر منشور لريادة الأعمال في Medium ، يليه 271.813 شخصًا.

اشترك لتلقي أهم الأخبار هنا.