في مجال تطوير البرمجيات ، غالبًا ما تكون هناك أطروحات مثل "
لا أحد يهتم بشفرتك " (الترجمة - "
الكود لا يهم أي شخص ") ، "الكود هو مجرد أداة" وحالات سوء الفهم الكامل من جانب العمل لماذا يجب أن نأخذ الوقت و المال لنوع من "إعادة بيع" الكود الذي يعمل بالفعل.
أريد أن أخبرك بما يمكن أن يؤدي إليه "التركيز على الخصائص" ، بدلاً من الاهتمام بجودة الشفرة ، ولماذا لا يحتاج المبرمجون فقط إلى رمز جيد.
دعم
الأطروحة الرئيسية ، والتي بدونها سيكون المقال الحالي ، من حيث المبدأ ، بلا معنى:
إن ما يحدث في عالم البرمجة لعقود من الزمن ، من أجله يتم إنشاء لغات ونماذج ونُهج أكثر تقدماً ، والتي يميزون فيها القوالب المختلفة والعناية بتصميم الكود ، هما في الواقع شيئان - زيادة سرعة التطوير وتسهيل دعم قاعدة الشفرة (والتي أساسا سرعة تطوير وظائف جديدة).
وهذه هي الأشياء التي يحتاجها العمل.
بالطبع ، يمكن للمرء أن يجادل بأنهم أنفسهم بحاجة إلى المنهجيات التي تزيد من كفاءة عمل المبرمجين من أجل بيع عملهم أكثر تكلفة ، والقدرة على القيام بالمزيد لكل وحدة زمنية ، ولكن لأن الموقف عندما يطلب المبرمجون مشروعًا كبيرًا منتهيًا على الفور دون الحاجة إلى مزيد من الدعم هو أمر بالغ الصعوبة هذا أمر نادر الحدوث ، وعادةً ما يتم طلب الوظيفة تدريجياً ، في بداية المشروع لن تشعر بالآثار الضارة للتصميم السيء ، بل هو استثمار في المستقبل.
توجد صورة من
مدونة Martin Fowler حول هذا الموضوع ، توضح سرعة إدخال وظائف جديدة في المشروع اعتمادًا على وقت وجوده (أي حجمه كبير).
المحور الأفقي هو عمر المشروع ، المحور الرأسي هو الوظيفة الكلية.
يوضح الخط الأحمر سرعة تطوير المشروع بتصميم جيد ، ويوضح الخط الأزرق المشروع المكتوب دون أي قيود في شكل متطلبات لنوعية الكود.
وبالتالي ، إذا كنت تعتقد أن تطبيقك محكوم عليه بالفشل ولن يتطور ، أو أنه يستعد حصريًا لبعض الأحداث القادمة ، فلن تحتاج إلى التفكير في تصميم النظام. في الوضع المعاكس ، من المحتمل أن يؤتي ثمار التصميم الجيد ثماره عدة مرات.
في بعض الأحيان يمكنك سماع رأي مفاده أنه في بداية أي مشروع ، لا يتعين عليك التفكير في جودة الكود وإعادة كتابته مرة أخرى بعد عرض تقديمي ناجح للعملاء / المستثمرين ، ولكن في الغالبية العظمى من الحالات ، يكون هذا خطأ في بدء المشروعات ، وأسهل طريقة لكسب
الديون الفنية لسنوات قادمة.
الكود ليس أداة ؛ الكود هو المنتج النهائي
لا تستخدم
شركة البرمجيات الكود كأداة. هذا هو المنتج الرئيسي للشركة ، إنه الرمز النهائي للبرنامج الذي يحدد الجودة والسرعة والامتثال لمتطلبات الوظيفة. لا يمكن أخذها واستبدالها تمامًا دون تكبد خسائر مؤقتة ومادية ، كما يمكن القيام بذلك باستخدام منهجيات الكمبيوتر / IDE / Development ، والتي ستكون بالفعل أدوات أساسية لإنشاء المنتج.
حول "التركيز على الأداء"في المقالة التي أشرت إليها ، تم التعبير عن الفكرة التالية: تحتاج إلى التواصل مع العميل / مدير المشروع على مستوى جاهزية المشروع ، والمثال التالي كان عكس ذلك:
تخيل أن المصمم سيبدأ في إخبارك بالطبقات التي استخدمها في Photoshop ، وعن عدد الكائنات الموجودة لديه ، وما هي التدرجات المستخدمة في الفرش ، وما هي البرامج النصية للرسوم المتحركة الرائعة التي كتبها. لا يهمك. هل أنت مهتم بما إذا كان من الممكن بالفعل التقاط الصور.
لذلك هنا. هناك اختلاف واحد لأنه
لا يمكن ببساطة عرضه على الموقف بدعم من أحد منتجات البرمجيات - كل هذه الطبقات والفرش في Photoshop تصبح عديمة الفائدة لأي شخص مباشرة بعد نتيجة العمل (الصور) ، والشيء نفسه مجرد أداة لتحقيق النتيجة ، وليس المنتج النهائي.
وبالتالي ، عند إعداد متطلبات الصور النهائية ، لا يمكن للعميل القلق بشأن ما سيتم استخدامه في هذه العملية. في حالة البرنامج ، إذا كان العميل (الأعمال) سيطلب وظيفة فقط من التطبيق ، فإنه يخاطر بالحصول على ما يريده بالضبط - وظائف جديدة ، ولكن لم يكن هناك شك في أنه سيتعين الحفاظ عليه وتطويره.
لسوء الحظ ، هذه مشكلة شائعة إلى حد ما في الاستعانة بمصادر خارجية ، عندما تبيع الشركة فقط وقت مطوريها ، ولا يمكن للعملاء تقييم موضوعي لجودة النظام ، والوقت الذي تستغرقه لحل مشاكلها. عندما تزداد تكلفة تغيير الكود بشكل كبير ، لن يفيد الشركة نفسها في الاستعانة بمصادر خارجية - حيث يمكن استثمار عدد أكبر من ساعات العمل البشرية ، وستكون الشركة التي تطلب المنتج بالفعل قيد التنفيذ - لقد فات الأوان لإعادة كتابة النظام المرهق وغير المناسب ، لأنه يتطلب استثمارات ضخمة ووقف تقديم وظائف جديدة لا يمكن السماح بذلك.
رمز - مكان العمل للمبرمج
طوال الوقت الذي كانت فيه المقالة في نسخ مسودات ، فكرت كثيرًا فيما إذا كان ينبغي إدراج هذا البند في ذلك ، ولكن بعد ملاحظة صغيرة لأولويات المرشحين الذين يبحثون عن عمل ، أدركت أن هذه اللحظة مهمة حقًا.
Code هو شيء سيتعين على المبرمج التعامل معه كل يوم ، ومنتجه الإبداعي ، وما يقوم بإنشائه ، ولكنه لا ينتج فقط منتجًا واحدًا ، ولكن في فريق ، وغالبًا لا يعمل من نقطة الصفر. يحتاج إلى قبول الجزء الموجود بالفعل من المشروع ، وتطويره استنادًا إلى الوظيفة التي تمت كتابتها قبله. من المرجح أن يكون الموظف غير سعيد للعمل في منتج تم إنشاؤه بشكل سيء.
في المقام الأول ، في رأيي ، هو أن الفريق يعمل سويًا في المشروع. تعتمد جودة المنتج الناتج مباشرة على كيفية بناء فريق العمل ، وعلى القواعد الداخلية والمتطلبات الموضوعة بداخله.
في المرتبة الثانية هي التكنولوجيا. إطار غير مريح تم اختياره أو ورثته ، وأدوات قديمة وعالية الجودة ، والمكتبات مسمرة إلى مكان المشروع مع كل عكازاتها وأخطاءها التي يجب عليك تحملها ، ونقص الأشخاص ذوي الكفاءات والوقت الكافيين للتخلص من الأساليب القديمة يمكن أن يخيفوا بسهولة إمكانات جديدة عمال. بالإضافة إلى الأسباب المذكورة أعلاه ، يعد هذا أيضًا عددًا أقل من الفرص والفرص لتطوير المبرمجين ، لأنه بدلاً من دراسة الأدوات الحديثة والأكثر فعالية ، من الضروري تطوير أدوات ملائمة لتكييف الحلول مع المهام الحالية التي تم تلقيها لأسباب تاريخية.
لماذا هذا كل شيء
لسوء الحظ ، نادراً ما يتم تشكيل متطلبات التطبيقات الحقيقية بنسبة 100٪ ، ولا تتطلب مراجعة أثناء التطوير. علاوة على ذلك ، فإن الموقف مستحيل تقريبًا عندما لا يتعين تعديل المشروع وفقًا للمتطلبات الجديدة بعد الإطلاق. توسع العمل ، ويتطور ، ويتطلب وظائف لم تناقش من قبل ، ويدخل في أسواق جديدة.
يكاد يكون من المستحيل بناء بنية مثالية مدروسة لكل التفاصيل الصغيرة في مثل هذه الظروف ، وفي كثير من الأحيان ، ليست هناك حاجة ، لأن تكلفتها في هذه الحالة مرتفعة بشكل غير معقول بالنسبة للمرحلة الأولية من المشروع.
بالتأكيد ، لا ينبغي أن تكون كتابة الكود الجيد بمثابة صداع لأولئك الذين يطلبون البرامج من المبرمجين ، ومن غير المرجح أن يتمكن أي شخص لا يكتبها من التحقق منها.
ومع ذلك ، يجب على الشركة التي تقوم بتطوير منتج برنامج ، إذا كانت ترغب في جعله نوعيًا ، أن تفهم أن هذا الجزء المهم من المنتج ككود المصدر الخاص به يؤثر بشكل مباشر على نجاحه ، ويجب أن تتضمن أيضًا أشياء مثل إعادة إدخال التعليمات البرمجية المصدر وتعديل البنية وفقًا للمتطلبات الجديدة تكون ميزانية ، يجب تخصيص وقت للمبرمجين. إذا كان شخص ما مهتمًا بجودة المنتج ، بالطبع.
ومع ذلك ، فإن صناعة تكنولوجيا المعلومات في تطور ، والمنتجات ، والشركات ، والأدوات قيد التطوير ، وأصبح المستخدمون أكثر انتقائية ، والمنافسة آخذة في الازدياد ، وهناك أمل في أن يظل المستقبل مع منتجات عالية الجودة.
استنتاج
في الحقيقة ، موضوع المقال مثير للجدل للغاية.
لا يجيب الرسم البياني أعلاه على السؤال في أي وقت يبدأ تصميم النظام في الدفع.
الدين الفني لذلك والدين ، الذي يتيح لك الحصول على مزيد من الوقت الآن وإعادته باهتمام لاحقًا ، ومشكلته الرئيسية بسيطة للغاية ، وتشبه بقوة ظاهرة مماثلة في الاقتصاد ، تتمثل في عدم القدرة على سداد الديون وعدم القدرة على تقدير الدخل المستقبلي بدقة.
تعد جودة الشفرة أيضًا أمرًا ذاتيًا للغاية ، ولسوء الحظ ، لا تتشكل من الناحية العملية ، وإلا يمكن استبدال المبرمجين بالفعل بروبوتات.
على أي حال ، فإن أهم شيء هو تحقيق حلول توفيقية مناسبة وإيجاد تلك الوسيطة ، مما سيتيح لنا عدم إغراق المشروع في حفرة الديون التقنية سعياً وراء الوظيفة ، وعدم التخلي عن مكانة مثيرة للاهتمام للمنافسين ، والقيام بتصميم النظام بدلاً من الوظيفة.