لم ارتح لـ typescript رغم أنها تبدو قريبة للجافا و#c. أفضل كتابة ES6 مع Babel خصوصا أني أجد نفسي أغلب الأوقات أستخدم webpack. ربما أكون قد تسرعت في الحكم عليها، لكن لا أظن أني سأحتاجها يوما. بالمناسبة "تطبيق هذا المثال على javascript لن يكون بنفس التنظيم." غير صحيح, لا أظن لغة البرمجة تلعب دورا كبيرا في كون الكود منظما أو لا, بل المبرمج من يقرر .
7 نقاط السمعة
8.95 ألف مشاهدات المحتوى
عضو منذ
0
عمل جميل، لدي ملاحظتان: - التصميم غير متجاوب بنسبة 100% (لا يكفي أن تكون الـ Layout متجاوبة فقط) أتمنى أن تركز على هاته النقطة - حاول استخدام خط كتابة أجمل لتزيد من أناقة التصميم هاته بعض الروابط التي قد تفيدك: - http://www.smashingmagazine.com/2013/05/17/typographic-design-patterns-practices-case-study-2013/ - http://www.smashingmagazine.com/2013/08/06/beautiful-typography-web-design/ - http://www.smashingmagazine.com/responsive-web-design-guidelines-tutorials/ لا تنسى أيضا برمجة لوحة تحكم للقالب :)
العمل على الـ Back-end كـ web API يلزم بشكل أو بآخر تطوير الـ Front-end كموديولز بشكل منفصل (تقريبا). بعبارة أخرى، استخدام فريموورك جافاسكريبت (MV*) أمر لا مفر منه. وعند التطوير، و بحكم أننا نتعامل مع وظائف الموقع كـ API، فالإستعانة بفريموورك للـ Front-end سيمكننا من التوسع لاحقا و بنية التطبيق ككل ستكون مستجيبة لهذا التوسع دون مشكلة (Scalable Architecture). الإعتماد على jQuery فقط لا يجدي، فحتى عمليات بسيطة كـ Dom Manipulation سينتج عنها آلاف من الأسطر و الدوال المرتبطة بينها،
جواب شافي و كافي، ربما أستطيع إضافة بضع نقاط.. - Open Close Principle: بحيث تصبح الكلاسات، الموديولز، الدوال وغيرها قابلة للتغيير، التطوير، المراجعة، سهلة أثناء الـ (Unit Tests) ليس فقط بالإعتماد على الـ Interfaces لكن كذلك باستغلال أنماط التصميم المختلفة. - Separation of concerns: تحدثت عنها بقولك: "جعل الدوال والكلاسات لديك مسؤولة عن شيء واحد فقط".. ولا يتعلق الأمر بالدوال و الكلاسات فقط، لكن يمكن تعميمه على طبقات و أجزاء التصميم ككل، بحيث تصبح "المعمارية؟" (Architecture) Multi Layered بحيث يتم