تتبع عمليات إعادة البناء في قاعدة بيانات الأخطاء

Question

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

• اكتب تقريرًا عن الأخطاء واربط عملية إعادة البناء به.
• اكتب طلب ميزة واربط عملية إعادة البناء به.
• تسلل إلى عمليات إعادة البناء أثناء العمل على التعليمات البرمجية المرتبطة بتقرير الأخطاء/طلب الميزات.
• فقط لا تفعل أي إعادة هيكلة.
• آخر

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

Answer 1

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

Answer 2

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

Answer 3

طريقة عملنا هي:يجب أن يكون هناك سبب وجيه لإعادة بناء الكود، وإلا لماذا؟

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

إذا كان الأمر يتعلق بجعل شيء ما أسرع، فقم بإنشاء طلب ميزة لـ "xyz" الأسرع واربط التغييرات بذلك - ثم يرى العملاء أنك تقوم بتحسين المنتج.

إذا كان الأمر يتعلق بتصميم خطأ ما، فقم بتسجيل الخطأ.

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

Answer 4

دعونا نلقي نظرة على كل خيار:

• اكتب تقريرًا عن الأخطاء واربط عملية إعادة البناء به.

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

• اكتب طلب ميزة واربط عملية إعادة البناء به.

قد يكون من الصعب كتابة كود المفاعل بناءً على طلب الميزة.ولكن يمكنك استخدام طلب ميزة صالح للقيام بذلك مما يقودني إلى النقطة التالية ...

• تسلل إلى عمليات إعادة البناء أثناء العمل على التعليمات البرمجية المرتبطة بتقرير الأخطاء/طلب الميزات.

إذا كان هناك خطأ أو ميزة صالحة، فاذكر أنه يجب تغيير الوظيفة x قليلاً لإصلاح الخطأ أو إضافة الميزة.

• فقط لا تفعل أي إعادة هيكلة.

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

• آخر

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

Answer 5

• آخر

إذا كنت تعمل في مكان يتبع هذا النوع من السياسات غير المرنة (والسخيفة)، فإن الحل الأفضل هو العثور على وظيفة أخرى!