كيفية تنفيذ التعليمات البرمجية بطريقة تقلل من إمكانية إعادة استخدام كاملة [مغلق

Question

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

ما هي بعض مبادئ النصائح / التصميم الجيدة التي تبقي هذه الأشياء من الحدوث؟

أو لتقليل مقدار إعادة العمل إلى التعليمات البرمجية اللازمة من أجل تنفيذ طلبات الميزات أو تغييرات التصميم في منتصف التنفيذ؟

Answer 1

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

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

Answer 2

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

نقاط...

1. الحفاظ على اتصال مفتوح
2. أن تكون مفتوحة وصادقة مع تقدم المنتج
3. تكون على استعداد للتغيير يوميا لاحتياجات عمل العملاء ومواصفات تغيير المنتج.

Answer 3

تتغير متطلبات البرامج، وليس هناك الكثير يمكن أن يفعله الأمر حيال ذلك باستثناء التفاعل الأكثر تكرارا مع العملاء.

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

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

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

Answer 4

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

• المكتبات الصغيرة التي تفعل أشياء محددة مسبقا بشكل جيد
• الحد الأدنى من التبعيات بين الوحدات النمطية

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

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

أخيرا، أوصي بأنني "مبرمج براغماتي" من قبل أندرو هانت وديف توماس كاملة من النصائح. المفضل الشخصي الخاص بي هو جاف - "لا تكرر نفسك" - أي رمز يقول نفس الشيء رائحة مرتين.

Answer 5

• تكرار صغير

• تكرار في كثير من الأحيان

• اختبار بين التكرارات

• احصل على منتج عامل بسيط خارج اسرع وقت ممكن حتى يمكن للعميل إعطاء المدخلات.

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

Answer 6

g'day،

بالنظر إلى الإجابات الأخرى هنا لاحظت أن الجميع يذكر ما يجب القيام به في مشروعك المقبل.

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

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

قد يكون الأمر بسيطا مثل التواصل السيئ أو ربما زحف متطلبات العملاء.

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

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

هذر

في صحتك،

Answer 7

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

لم يكن إعادة كتابة كاملة لوظائف جديدة في دور جديد فكرة سيئة دائما.

Answer 8

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

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

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

Answer 9

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

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

لا يعمل دائما فورا.