تطبيق فن الحرب على تطوير البرمجيات
نشرت: 2022-03-11إذا كنت تعمل في صناعة البرمجيات ، فمن المحتمل أنك سمعت عن نموذج التصميم بفارق تسد ، والذي يتكون أساسًا من تقسيم المشكلة بشكل متكرر إلى مشكلتين فرعيتين أو أكثر ( قسمة ) ، حتى تصبح هذه بسيطة بما يكفي ليتم حلها مباشرة ( قهر ).
ما قد لا تعرفه هو أن هذا النموذج ينشأ من استراتيجية سياسية قديمة (الاسم مشتق من القول اللاتيني فرق وإمبرا ) التي تشير إلى أنه من الممكن الحفاظ على السيطرة على مرؤوسيهم أو رعاياهم من خلال تشجيع الاختلاف بينهم.
تم استخدام هذه الإستراتيجية من قبل عدد لا يحصى من السياسيين والقادة العسكريين عبر التاريخ ، مثل يوليوس قيصر (الذي استخدمها خلال حروب الغال لهزيمة الغالس الأقوياء عسكريًا) ونابليون (خبير المدفعية الفرنسي سيقسم قوات العدو لذلك لم يكن أي جزء أقوى من قواته ، ثم قطع اتصالاتهم ، مما يعيق جهود العدو لتنسيق وتنفيذ الهجمات).
فن الحرب: المبادئ القديمة المطبقة على التنمية
ومع ذلك ، فإن قاعدة فرق تسد ليست الإستراتيجية السياسية الوحيدة التي يمكن تطبيقها على تطوير البرمجيات. على الرغم من أن السياسة والحرب لا علاقة لهما بتطوير البرمجيات ، تمامًا مثل السياسيين والجنرالات ، يجب على المطورين قيادة المرؤوسين ، وتنسيق الجهود بين الفرق ، والعثور على أفضل الاستراتيجيات لحل المشكلات ، وإدارة الموارد.
فن الحرب هو مقال عسكري قديم كتب في القرن الخامس قبل الميلاد وينسب إلى صن تزو ، وهو استراتيجي عسكري صيني قديم ، كان لنظرياته تأثير عميق على الفلسفة الشرقية والغربية.
على الرغم من عمره ، لا يزال النص مدرجًا في المنهج الدراسي في العديد من المدارس العسكرية في شرق آسيا ، وهو مدرج كقراءة موصى بها في بعض الأكاديميات العسكرية في الغرب. ينقسم النص إلى 13 فصلاً ، كل فصل مخصص لجانب مختلف من الحرب.
ومع ذلك ، بالإضافة إلى الحرب ، فإن مبادئ وتعاليم Sun Tzu لها تطبيقات عملية في السياسة ، والأعمال التجارية ، والرياضة ، وصدق أو لا تصدق ، تطوير البرمجيات. في الواقع ، ربما تقوم فقط بتطبيق بعض هذه المبادئ في روتينك اليومي ، دون معرفة أصولها.
بالتفصيل أدناه ، ستجد قائمة مختصرة بالتكتيكات الأساسية والنصائح الموضحة في فن الحرب. من المحتمل أن يتم تطبيقها على وظيفتك في صناعة البرمجيات ، أو أي عدد من الصناعات الأخرى.
الوقت حاسم في أي حملة
الفصل الثاني ، الفقرة 2
عندما تنخرط في قتال حقيقي ، إذا كان النصر طويلاً ، فإن أسلحة الرجال ستضعف وستضعف حماستهم.
يمكن تطبيق هذا المبدأ على تطوير البرمجيات ، كقاعدة تصف العلاقة بين طول دورات التطوير ومعنويات المطور.
إذا عملت مجموعة من المطورين على نفس المشاريع لأشهر ، بدون أهداف واضحة أو نهاية في الأفق ، فقد يصابون بالإحباط وقد تنخفض إنتاجيتهم.
تطوير البرمجيات هو مسعى فكري ، لذا فإن الدافع هو الوقود الرئيسي للإنتاجية. العمل كل يوم دون إدراك أن عملك يولد نتائج حقيقية يمكن أن يكون محبطًا للغاية.
كما هو موضح في بعض منهجيات أجايل ، يجب تقسيم خارطة طريق التطوير إلى عدة أهداف ومعالم ، والتي قد يتمكن الفريق من تحقيقها في أطر زمنية قصيرة ، وسوف تمنحهم إحساسًا بالتقدم والإنجاز.
الفصل الثاني ، الفقرة 18
إذن ، في الحرب ، اجعل هدفك العظيم هو النصر ، وليس الحملات الطويلة.
يمكن تفسير هذه العبارة بطريقتين:
أولاً ، يمكن اعتباره مقدمة لفلسفة UNIX: اكتب البرامج التي تقوم بشيء واحد وتقوم به بشكل جيد . عند تطوير البرنامج ، يجب أن تضع في اعتبارك دائمًا الهدف الرئيسي للبرنامج ، أو الميزة الرئيسية التي يوفرها ، أو أكبر مشكلة يحلها ، وتضمن التنفيذ السليم.
في بعض الأحيان قد تستلهم الأفكار وتفكر في ميزة رائعة حقًا يمكنك إضافتها ، ولكن لا تنس أن التطبيقات التي تحتوي على الكثير من الميزات المستخدمة بشكل غير متكرر لها اسم مهين: bloatware .
ثانيًا ، يمكن أيضًا اعتبار البيان بمثابة مقدمة لأحد مبادئ تطوير البرامج الهزيلة: التسليم بأسرع ما يمكن .
كلما قدمت البرنامج بشكل أسرع بدون عيوب كبيرة ، كلما حصلت على تعليقات من العميل بشكل أسرع ، وستتمكن من دمج التغييرات في التكرار التالي.
من ناحية أخرى ، إذا قدمت برنامجًا لا يعمل ، فستفقد تعليقات قيمة ، لأن العملاء لن يحصلوا على فرصة لاختباره بشكل صحيح. سيؤدي ذلك إلى جعل المرحلة التالية من التطوير أكثر صعوبة أو مستحيلة في المواقف التي يعتمد فيها التكرار التالي على ملاحظات العملاء.
لا قيادة ، لا نتائج
الفصل الثالث ، الفقرة 11
الآن الجنرال هو حصن الدولة. إذا اكتمل الحصن في جميع الأوقات ، ستكون الدولة قوية ؛ إذا كان الحصن معيبًا ، ستكون الدولة ضعيفة.
يصف هذا الاقتباس أهمية دور المدير في فريق التطوير: يعتمد نجاح المشروع على قوة جميع الأشخاص المعنيين ، والمدير هو حصن المشروع. تبدأ المسؤولية من القمة.
على الرغم من أن المطورين يعملون في كثير من الأحيان بمفردهم (كل منهم جالس خلف جهاز كمبيوتر ، مع اتصال محدود بزملاء العمل) ، فإن هذا لا يعني أنهم لا يحتاجون إلى قيادة جيدة. يتحمل مديرو المشروع مسؤولية إبقاء الفريق على المسار الصحيح ، وضمان التواصل الفعال وتسوية المنازعات ، ومن الواضح أن القادة يحددون أولويات المشروع (من بين المهام الأخرى) ، لذلك لا ينبغي الاستهانة بدورهم. ولا ينبغي أن تكون مسؤوليتهم إذا حدث خطأ ما. تخيلوا ماذا سيحدث لقائد عسكري أخفقت وحدته في أداء واجبها في ميدان المعركة؟
يمكن للفريق أن ينتج برامج رائعة حتى لو كان لديه عدد قليل من التفاح الفاسد في مناصب التطوير ، ولكن من غير المحتمل أن يحدث ذلك إذا كان مدير المشروع هو التفاحة السيئة ، بغض النظر عن عدد مطوري موسيقى الروك لدى الفريق.
الفصل السادس ، الفقرة 28
لا تكرر التكتيكات التي أكسبتك انتصارًا واحدًا ، ولكن دع أساليبك تنظمها مجموعة لا حصر لها من الظروف.
في بعض الأحيان ، عند بدء مشروع ما ، يكون من المغري استخدام نفس مجموعة التقنيات التي استخدمناها في المشاريع الناجحة سابقًا (نفس لغة البرمجة ، نفس المكتبات ، نفس الخادم ، إلخ). ومع ذلك ، ما لم تكن متطلبات المشاريع الجديدة متطابقة تمامًا مع المتطلبات السابقة ، فقد يكون هذا هو النهج الخاطئ.
في البرمجة ، كما هو الحال في معظم المجالات ، لا يوجد الدواء الشافي (علاج مفترض قادر على علاج جميع الأمراض). لا توجد مجموعة واحدة من التقنيات التي يمكنك استخدامها لحل جميع المشكلات ؛ كل تقنية لها جوانبها الإيجابية والسلبية.
بالطبع ، قد يكون تعلم لغة برمجة جديدة أو استخدام واجهة برمجة تطبيقات غير معروفة مكلفًا في البداية ولكن على المدى الطويل ، ستكون جودة البرنامج أعلى وستصبح مطورًا أفضل.
الفصل الثالث عشر ، الفقرة 27
ومن ثم فإن الحاكم المستنير والجنرال الحكيم فقط هما اللذان سيستخدمان أعلى ذكاء للجيش لأغراض التجسس ، وبالتالي يحققان نتائج عظيمة. الجواسيس هم العنصر الأكثر أهمية في الحرب ، لأنهم يعتمدون على قدرة الجيش على التحرك.
يمكن تفسير هذه العبارة على أنها أهمية استخدام أدوات المراقبة ومكتبات التسجيل أثناء مرحلة الصيانة.
على الرغم من أن العملاء قد لا يعتقدون ذلك في بعض الأحيان ، إلا أن التطوير لا ينتهي عندما تحصل على إصدار مستقر ومختبر بالكامل. تتطور البرامج دائمًا ، إما عن طريق إصلاح الأخطاء أو إضافة ميزات جديدة أو تحسين الكفاءة.
ولا يوجد مصدر معلومات أفضل لمعرفة التغييرات التي يجب إجراؤها من وجود جواسيس يراقبون البرنامج في بيئات الإنتاج ، والتحقق من الميزات الأكثر استخدامًا والأخطاء الأكثر شيوعًا والعمليات الأطول.
تعد تقارير الأخطاء وإدخالات التسجيل وبيانات الاستخدام أساسية لاكتشاف الأخطاء وتحديد الاختناقات والمشكلات الأخرى نظرًا لأنه ليس من الممكن دائمًا إعادة إنتاج نفس الظروف في بيئات الاختبار الخاضعة للرقابة.
العمل الجماعي والتحفيز
الفصل العاشر ، الفقرة 24
من يتقدم دون طلب الشهرة ، ومن يتراجع دون أن يفلت من اللوم ، ومن غايته حماية شعبه وخدمة سيده ، فإن الرجل جوهرة المملكة.
في الأساس ، هذه هي النسخة الصينية القديمة من "ليس هناك أنا في الفريق" . من المهم العمل مع الآخرين بدلاً من السعي لتحقيق مكاسب شخصية.
يعد تطوير البرمجيات نشاطًا معقدًا يتطلب من المطورين العمل بكفاءة كفريق. المطور الجيد ليس هو الشخص الذي يصلح معظم الأخطاء أو ينفذ معظم الميزات أو ينهي المهام قبل الموعد المحدد ؛ المطور الجيد هو الذي يساعد الفريق على تحقيق أهدافه.
قد تخدع المطالبة بالائتمان عن كل ما قمت به ، أو عدم التعرف على أخطائك أو إلقاء اللوم على الآخرين عليها ، أو تسمية نفسك بـ Code Ninja بعض المديرين عديمي الخبرة وقد تحصل على علاوة ، لكنك ستصبح عضوًا بنتائج عكسية في فريقك.
الفصل السابع ، الفقرة 21
تأمل وتدبر قبل أن تتحرك.
تشير هذه العبارة إلى أهمية اجتماعات تطوير الفريق ، مثل تلك التي تقترحها منهجيات أجايل.
عند العمل ضمن فريق ، من المهم مناقشة أي تغييرات رئيسية قبل تنفيذها. لا يهم إذا كنت قائد الفريق ، أو إذا كنت الشخص الأكثر خبرة في الموضوع ، يجب عليك دائمًا التحدث مع بقية الفريق ، أو على الأقل إبلاغهم.
تذكر أنه يمكن للمطورين الآخرين إعطائك رؤى حول الأجزاء غير المألوفة من البرنامج. هذا يعني أنه يمكنهم البدء في تنفيذ التغييرات بشكل أسرع من المتوقع ، لأنهم يمكن أن يكونوا على دراية كاملة بآثار التغييرات المذكورة.
الفصل العاشر ، الفقرة 25
اعتبر جنودك أطفالك وسيتبعونك في أعمق الوديان ؛ انظر إليهم كأبنائك المحبوبين ، وسوف يقفون إلى جانبك حتى الموت.
يشير هذا الاقتباس إلى أهمية التحفيز ، وهو مبدأ إدارة يتجاهله المديرين وقادة الفريق أحيانًا. سيكتب المطورون المتحمسون كودًا أفضل ويعملون بشكل أسرع ويرتكبون أخطاء أقل ويكونون أكثر استعدادًا لوضع ساعات إضافية.
يجب أن يتم توليد الدافع من قبل المديرين ، من خلال الاهتمام الحقيقي بمرؤوسيهم ، والاستماع إليهم ، والاهتمام بالتوازن بين العمل والحياة الخاصة بهم ، وبناء بيئات عمل إيجابية ، والاهتمام بمساراتهم المهنية.
أيضًا ، يجب ألا تخلط بين الدافع والأجر. تظهر الدراسات الحديثة أن المال لا يحفز معظم العمال ، فالأموال في الغالب جيدة في جذب الموظفين والاحتفاظ بهم ، ولكن ليس في إسعادهم بوظائفهم. لذلك لا ينبغي اعتبار الزيادات والترقيات على أنها أدوات تحفيزية.
التفكير خارج الصندوق
الفصل الخامس ، الفقرة 7 و 8 و 9
لا يوجد أكثر من خمس نوتات موسيقية ، ومع ذلك ، فإن مجموعات هذه النوتات الخمس تؤدي إلى مزيد من الألحان أكثر مما يمكن سماعه في أي وقت مضى.
لا يوجد أكثر من خمسة ألوان أساسية ، ولكنها مجتمعة تنتج درجات ألوان أكثر مما يمكن رؤيته في أي وقت مضى.
لا يوجد أكثر من خمسة مذاقات أساسية ، ولكن مزيج منها ينتج نكهات أكثر مما يمكن تذوقه في أي وقت مضى.
من الأشياء الجيدة في البرمجة أن الاحتمالات لا حصر لها ؛ يمكنك التطوير بشكل أساسي أينما تريد (على الأقل ، طالما أنها ليست مشكلة NP كاملة).
تطبيقات الجوال والمواقع الإلكترونية والألعاب وتطبيقات سطح المكتب ... إذا كنت تعرف البرمجة ، فجميعها في متناول يدك.
الفصل الثالث ، الفقرة 1
في فن الحرب العملي ، أفضل شيء على الإطلاق هو أخذ دولة العدو كاملة وسليمة ؛ لتحطيمها وتدميرها ليست جيدة. لذا ، أيضًا ، من الأفضل الاستيلاء على جيش بأكمله بدلاً من تدميره ، والاستيلاء على فوج أو مفرزة أو شركة بأكملها بدلاً من تدميرهم.
عند العمل في مشروع بقاعدة رموز كبيرة ، من الشائع العثور على وحدات أو أقسام من التعليمات البرمجية التي تم تنفيذها بممارسات سيئة أو باستخدام مكتبات مهملة. على الرغم من أنه قد يكون من المغري محو (أو إتلاف) هذا الرمز ، إلا أنه قد لا يكون أفضل فكرة لعدة أسباب:
الكود القديم ليس بالضرورة سيئًا ، في بعض الأحيان يكون رمزًا جيدًا تمت كتابته عندما تم اعتبار المنهجيات والتقنيات الأخرى هي الطريق الصحيح. ومع ذلك ، لمجرد أنها قديمة لا يعني أنها لا تعمل.
قد تضيع الوقت في إصلاح التعليمات البرمجية التي لا تزال تعمل بدلاً من التركيز على إصلاح أجزاء أخرى أكثر أهمية من الكود.
ما لم تكن متأكدًا حقًا مما تفعله ، فإن استبدال جزء من التعليمات البرمجية يعمل يعني أنك تخاطر بإدخال أخطاء أو أخطاء جديدة.
هذا لا يعني أن عبارة "إذا لم يتم كسرها ، لا تقم بإصلاحها" هي إستراتيجية جيدة ، ولكن لكل مشروع أولويات وأهداف وقيود زمنية. لذلك ، إذا وجدت رمزًا يمكن تحسينه ، فناقشه مع بقية الفريق أو مع مدير المشروع لمعرفة وقت تحسينه.
الفصل الثامن ، الفقرة 3
هناك طرق يجب عدم اتباعها ، وجيوش لا يجب مهاجمتها ، ومدن لا يجب محاصرتها ، ومواقع لا يجوز التنازع فيها ، وأوامر من الملك لا يجب طاعتها.
حتى لو لم يقل ذلك بشكل مباشر ، يمكننا تفسير هذا المبدأ على أنه تحذير لتجنب الأنماط المضادة.
على الرغم من أن استخدام نمط مضاد قد يحل مشكلة قصيرة المدى ، يجب أن تتذكر أنه على المدى الطويل سيكون له نتائج عكسية. لذلك ، بغض النظر عن مقدار الوقت الذي توفره ، أو عدد الأخطاء التي تصلحها أو مدى ملاءمتها لك ، تجنبها.
ومع ذلك ، هناك أوقات قد تميل فيها إلى استخدام نمط مضاد لحل مهمة عاجلة ، واعدًا نفسك بأنك ستنفذ إصلاحًا مناسبًا عندما يكون لديك المزيد من الوقت ، ولكن تذكر أحد قوانين مورفي: تصبح جميع الإصلاحات السريعة تغييرات دائمة.
خاتمة
على الرغم من أن تطوير البرامج يختلف عن قيادة الجنود في الحرب أو قيادة دولة ، إلا أن كل ما يجب عليهم فعله هو حل المشكلات التي تتطلب العمل الجماعي والقيادة الجيدة والكفاءة والحلول طويلة المدى.
ومع ذلك ، فإن فن الحرب ليس الكتاب الوحيد الذي يحتوي على مبادئ يمكن تطبيقها على تطوير البرمجيات. ومن الأمثلة على ذلك رواية "الأمير نيكولو مكيافيلي".
في الواقع ، فيما يلي قائمة باقتباسات من مكيافيلي لا تزال ذات صلة. جرب تخمين المبادئ المقابلة في عالم تطوير البرمجيات.
- لا يستطيع الأسد أن يحمي نفسه من الفخاخ والثعلب لا يستطيع أن يدافع عن نفسه من الذئاب. لذلك يجب أن يكون المرء ثعلبًا حتى يتعرف على الفخاخ وأسدًا لتخويف الذئاب.
- لا تحاول أبدًا أن تكسب بالقوة ما يمكن كسبه بالخداع.
- لم يتحقق أي شيء عظيم بدون خطر.
- من يرغب في النجاح المستمر يجب أن يغير سلوكه مع الزمن.
- الرجال بشكل عام يحكمون على الظاهر أكثر من الواقع. كل الرجال لديهم عيون ، لكن القليل منهم لديهم موهبة الإيلاج.
- من يرغب في أن يُطاع يجب أن يعرف كيف يأمر.
- تتكون الحكمة من معرفة كيفية التمييز بين طبيعة المتاعب واختيار أهون الشرين.
- لا مفر من الحرب. لا يمكن تأجيلها إلا لصالح عدوك.
- الطبيعة تخلق القليل من الرجال الشجعان ؛ الصناعة والتدريب يجعل الكثير.