سأقدم نفسي ، Malyugin Platon Android Lead في Dejavoo Systems. تدور هذه القصة حول "ألمنا" الذي نكافح معه لمدة عام وتطور بنيتنا المعمارية. الملف الشخصي الرئيسي هو المحطات النقدية لتجار التجزئة والمطاعم ، لذلك يرتبط الكثير بخصائص الصناعة.
على أي حال ، لا يؤدي تغيير بنية أحد التطبيقات إلى تعقيده فحسب ، بل يزيد من حجم التوثيق ويتطلب الدعم. لذلك ، يجدر النظر فيما إذا كان من الضروري القيام بذلك الآن؟ هل لديك خبرة كافية وعدد مهام الحجب؟
لماذا الان؟ يمكنك الاستمرار في معاناة هذه الشاشة ولمسها بأقل قدر ممكن ، حيث إنها تعمل ، فلماذا تحطم ما يعمل الآن؟ كل شيء بسيط ، فقد تراكم عدد كبير من مهام الحظر ، ومن الضروري إعادة تشكيل هيكل الأمر الحالي من أجل هيكل أكثر تعقيدًا ومرونة. لا يمكنك الاستغناء عن التعديلات.
وصف المشكلة
نستخدم نشاطًا واحدًا للطلب ، وهو يدعم كلاً من إصدارات الهاتف والأجهزة اللوحية. من الأسهل بالنسبة لنا العمل مع الحوارات (الحوارات الخاصة بنا هي نشاط) ، وهناك الكثير منها على هذه الشاشة ولا نريد تكرارها.
هذا ما يبدو عليه إصدار الجهاز اللوحي:
نقوم بتجميع الإصدار للهواتف من نفس العناصر ، ولكن باستخدام متصفح مختلف.
سأصف ما تتكون الشاشة:
- العناصر - شظية
- الإدارات - شظية
- البنود والمبلغ - جزء
- معلمات الطلب هي طريقة عرض منفصلة
50, , , OrderPresenter .
, Use case, . . , , , .
, , , , , . , ( Use case).
:
- ,
- ,
- , ,
- ,
- , , ""
- ,
" " — , 2- . :
- "" ( )
- ,
- ,
, , , , .
, , . :
- ( 2 ) ,
- UI
- Rx
, "" , , ( ), . .
الآن ، إذا كان المستخدم "يطرق" على الشاشة بسرعة كبيرة. عندها سنكون قادرين على معالجة جميع العمليات ، وإن كان ذلك مع تأخير بسيط (على الرغم من أن هذا سيكون أقل وضوحًا للعين من "تجميد" الشاشة)
مخطط موجز UML للمستودع:
النتيجة
ربما اخترعنا دراجة ، لكن الهندسة المعمارية ، في رأيي ، تبسط العمل وتتيح لك دعم حالات أكثر تعقيدًا. نواصل العمل على ذلك.