1/ الاسبوع الماضي ساعدت صديق انه يعمل refactoring في بروجكت شغال عليه (PHP & Laravel) . و هكتب في الثريد ده اللي احنا عملناه يمكن حد يستفيد او حد يفيدنا برايه في اللي عملناه
2/ الاول هتكلم في حاله المشروع قبل ما نبدا اي حاجه و بعدين هتكلم في اللي غيرناه و ظبطناه علشان شكل الكود يبقي افضل و احسن
3/ البروجكت عقارات و فيه فورم بيسجل كل انواع العقارات بمختلف انواعهم. وطبعا ده معناه ان فيه نوع بيطلب بيانات معينه و نوع تاني بيطلب بيانات مختلفه تماماً مع وجود بعض البيانات المشتركه زي اسم العقار و عنوانه مثلا
4/ بيانات العقارات بيتم حفظها في جدول واحد بمختلف انواعها. ف ده معناه ان فيه nullable fields كتير و و بيانات متجمعه مع بعضها بشكل خاطئ (وممكن يتم فصلهم علي عدة جداول).
5/ الحاجات اللي مش هنقدر نعملها هي اننا نقسم في الجدول لان ده هيحتاج وقت كتير جدا. و بردو اننا نعمل اكثر من view لكل نوع form كان هياخد وقت كتير. كمان انا شكل الفورم كان شئ مجهول بالنسبالي.
6/ ف احنا هنركز علي اننا نظبط الكنترولر و الـvalidation بدل ما فيه if conditions علي الـ category id و هتلاقي نفسك بتعمل سكرول في الكود كتير علشان توصل لجزء معين كمان الزياده و التعديل كان شئ مجهد جدا في كود زي دا فوق ال٥٠٠ سطر في ميثود واحده بس
7/ اول مشكله بدانا بيها هي اننا نظبط الـ Category ids و نخليها اسهل في التعديل و الفهم لانها مكانتش متسجله في قاعدة بيانات و علشان تعرف ايه الـ categories المتاحه كنت لازم تبص علي الـ view file زي كدا
8/ طبعا المشكله هنا ان سهل جدا يحصل خطأ و تستخدم id غلط او اي تغير في شكل الفورم ممكن يادي لفقدان بيانات معينه و كان الحل اننا نستبدل الكلام ده بـ Enum class ونسميه Category
9/ وكدا بقي سهل علينا نوصل لاي نوع عقار و سهل اننا نغير اسمه في وقت او نعتمد حتي الـ localiztion و غيرنا استخدامه في الـ view للشكل ده
10/ بعد كدا الـ validation rules كان فيها تكرار كتير جدا و كانت اشبه بالمتاهه لاي حد هيبص علي الكود من اول مره.
طبعا في الصوره انت مش فاهم رقم 1 و ٢ في الكاتيجوري بيعبر عن ايه و تكرار title and description
طبعا في الصوره انت مش فاهم رقم 1 و ٢ في الكاتيجوري بيعبر عن ايه و تكرار title and description
11/ هنا احنا اكتفينا اننا نقلل التكرار و نوضح الارقام من غير ما نعمل inheritance و يبقي لكل كاتيجوري كلاس للفاليديشن. و شكلها بقي مقبول شويه و افضل من الاول
12/ بعد كدا دخلنا علي الـ Controller و اللي كان مليان if conditions حسب نوع العقار و inputs كتير لكل نوع منهم.
13/ استخدمنا Factory pattern علشان نرجع Object علي حسب نوع العقار و هو المسئول عن البيانات اللي هنحتاج نسجلها.
14/ و بقي عندنا الـ Factory بيرجع دايما Property فيها create بتاخد request object و منه بتسجل البيانات اللي محتاجاها
15/ و في النهايه الكنترولر بقي بيستخدم سطرين فقط علشان يسجل بيانات العقار -و عدة سطور اخري لاشياء لا داعلي لذكرها في الثريد -
16/ طبعا ده مش احسن ريفاكتورينج. لكن ده اللي قدرنا نظبطه قدر المستطاع حسب الوقت المسموح فيه للتاسك مع صديقي.
17/ الملخص اننا استخدمنا Factory pattern و Open/Close principle علشان نخزن البيانات لان دلوقتي اي نوع عقار جديد هيستخدم Property Interface اللي فيها create ميثود بتاخد request ومنها يسجل البيانات اللي محتاجها فقط من غير التعديل في اي حاجه تاني
18/ في الاخر حابب اعرف رايكم في اللي خلصناه و لو فيه حاجه احسن كانت ممكن تتعمل في اللي كاتبناه يا ريت تتكرم و تعرفهالنا
جاري تحميل الاقتراحات...