كيف ريفاكتور القديم الخاص بك رمز PHP?[مغلقة]

Question

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

المشكلة مع هذا الرمز (و الكثير من التعليمات البرمجية PHP بشكل عام أظن) هي التي تطورت إلى ما هي عليه و لا منظم بشكل جيد جدا, لديه الكثير من تقريبا متطابقة قص/لصق قطعة من التعليمات البرمجية ، و يجعل الاستخدام المكثف من globals حتى حيث الوظائف المعنية.وليس وحدة واحدة اختبار في أي مكان ، بالطبع ، هو رمز الثابت ترميز لاستخدام معين DB وتعتمد على $_REQUEST سلاسل من صفحة الويب التي تدعو رمز.

الصواب أن سحب قطعة من التعليمات البرمجية كما sub-وظائف مرتبة لهم وإضافة بعض وحدة الاختبارات للتأكد من أنها لا تزال تعمل ، إضافة بضع كائنات وهمية على طول الطريق.غير أن القيام بذلك كليا باليد مملة عرضة للخطأ و أتساءل كيف يمكنك أن تفعل هذا - هل هناك IDE أو الأداة التي يمكن أن تساعد, على سبيل المثال ؟ أود أن يكون أداة يمكن أن تساعد في إنتاج وظيفة من تعريف قطعة من التعليمات البرمجية التي تشير إلى المتغيرات ينبغي أن المعلمات من حيث القيمة أو إشارة تلقائيا إضافة $this-> المراجع ، إلخ.

هل هذا طلب كبير, أم أن هناك حل جيد ؟

وذلك بفضل!

Answer 1

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

1.الحصول على الأشياء فصلها. استخراج db و نموذج الاشياء ذات الصلة واستخراج لهم بعيدا عن البرمجية الرئيسي.بعض وجوه التمثيل من شأنه أن يساعد.تحقق السجل النشط أو DAO نمط أي ORM العمل.كود HTML يمكن أن تؤخذ بعيدا من البرمجية الرئيسي وانتقلت إلى ملفات القالب.تحقق من قالب لطيف محرك قوي مع دعم عرض منطق المعالجة هندى.

2.وضع الأمور في إطار MVC. MVC هو قوي العمارة التي تناسب تطبيقات الويب بشكل جيد للغاية.استخدام واحدة من أطر PHP إلى التعادل فضفاضة ملفات PHP في وحدة تحكم الأساليب.أطر تجعل من السهل إدارة عناوين المواقع, طلبات HTTP ، تمرير معلمات وإدارة معلومات تسجيل الدخول و عادة لا تقدم بعض آليات الرقابة.

ولكن الأكثر أهمية هو:لا كسر أشياء لا يمكن إصلاحها.إنها إعادة بيع ديون وليس التجديد ;-)

Answer 2

هذا المقال يسلط الضوء على مخاطر إعادة بيع ديون/تطوير القبيح القديم رمز:

http://www.1729.com/blog/EconomicsOfTestingUglyCode.html

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

Answer 3

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

وأود أن أقترح عليك أن ميناء على كريمة إطار MVC.في القيام بذلك, قد لا تكون سيئة الوقت للقيام الهيكلية كتابة كل فئات هي الأمثل (وهو الأمر الذي نادرا ما يحدث بشكل طبيعي مع تطور القانون).فإنه سوف يستغرق وقتا طويلا لن يكون هناك ألم عندما لا تسير الأمور كما هو متوقع.

إنها خطوة كبيرة ولكن هذا ما يحدث عندما رمز تركت لتتعفن.

الخيارات الأخرى:

1. هل جزئي هيكلة ، حيث كل جديد مدونة يلي مجموعة النظام القديم هو رمز ببطء إعادة بنائه.
2. فقط إصلاح الخلل و لا إعادة الهيكلة.

Answer 4

أشعر الألم الخاص بك.ومع ذلك ، لم أسمع مثل هذه الأداة ، على الأقل ليس من أجل PHP.

Answer 5

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

Answer 6

كنت أبحث هذا الشيء جدا وجدت مثيرة للاهتمام بلوق من قبل العملاء من Accurev.

http://blog.accurev.com/2008/09/17/dr-strangecode-or-how-i-learned-to-stop-worrying-and-love-old-code/

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

Answer 7

في تجربة كتابة كاملة هو أكثر اقتصادا في هذه الحالة.