-
المقالة الأخيرة في هذه السلسلة مكتوبة للمبرمجين العاديين. إذا لم تكن مهتمًا، يمكنك فقط قراءة الفقرات القليلة الأخيرة من هذه المقالة.
قبل البدء في تصميم بنية التعليمات البرمجية، دعونا نراجع ما أعددناه من قبل: لدينا خادم ويب متوازن التحميل، وخادم قاعدة بيانات رئيسي وعبد، وربما تقسيم، وذاكرة تخزين مؤقت، وتخزين قابل للتطوير. ترتبط جميع جوانب تنظيم التعليمات البرمجية ارتباطًا وثيقًا بهذه الاستعدادات، وسأدرجها واحدًا تلو الآخر، واثنين ثلاثة، وسيبدأ كل منها بالجملة الكلاسيكية "المذكورة أعلاه" لسهولة المقارنة.
لا تتعجل في قراءة أنماط الجملة الكلاسيكية، فقد قفز ذهني وسأقوم بإدخال فقرة. في التطوير الفعلي، نقوم دائمًا بالتسوية بين الأداء وأناقة التعليمات البرمجية. بالنسبة لأجهزة الكمبيوتر ومترجمي اللغات اليوم، فإن مسألة عدد طبقات استدعاءات الكائنات وعدد طبقات استدعاءات الكائنات وما إذا كان سيتم الإعلان عن المتغيرات كـ Map أو HashMap هو آخر شيء يجب مراعاته دائمًا من الجزء الأبطأ. على سبيل المثال، تحقق مما إذا كان ORM الذي تستخدمه يقوم بالكثير من الأشياء التي لا تحتاج إليها، وما إذا كانت هناك مكالمات بيانات متكررة. ما نقوم به هو تطوير تطبيقات الويب، وليس واجهة برمجة التطبيقات (API) الخاصة بالإطار الأساسي. يعد الكود سهل القراءة والفهم جانبًا مهمًا للغاية لضمان الجودة. ما هو الغرض من برنامجك؟ ستتم مناقشة هذه المقالة بشكل منفصل. إذا كنت تريد التواصل، يمكنك متابعة حسابي على Weibo : http://t.sina.com.cn/liuzhiyi .
كما ذكرنا سابقًا، يجب أن يكون خادم الويب متوازنًا في التحميل، ويجب فصل خادم الصور. فيما يتعلق بهذه النقطة، عندما يتعامل الكود مع حالة العميل، لا تضع الحالة على جهاز واحد، على سبيل المثال، لا تستخدم جلسة الملف. إذا كان ذلك ممكنًا، فمن الأفضل تطوير واجهة موحدة لمصادقة المستخدم ذات النقطة الواحدة من البداية، بما في ذلك كيفية تحديد الحالة عبر المجالات، وكيفية تحديد الحالة على الصفحات الثابتة، وتعريف معلمات الانتقال والعودة عند تسجيل الدخول توفير واجهة جيدة في الطبقة السفلية وتطبيقها. يتم استخدام الطبقة مباشرة (راجع خدمة مستخدم GAE). يجب أن يأخذ تصميم تسجيل الدخول في الاعتبار خصائص الأجهزة المحمولة. على سبيل المثال، يمكن لأجهزة الكمبيوتر استخدام نوافذ ذات طبقة عائمة، لكن متصفح NOKIA أو UCWEB لا يمكنه التعامل مع هذا النوع من التعبير. يجب أن يكون البرنامج قادرًا على التعامل مع طلبات Ajax ومباشرة من خلال عنوان URL . بسأل. يتم فصل خادم الصور، ومن الأفضل وضع ملفات الموارد على خادم الصور، أي أن خادم الويب يخدم البرامج الديناميكية فقط. على الرغم من أن التطوير والاختبار معقد بعض الشيء (نظرًا لأنه يلزم وجود URI مطلق للوصول إليه)، سيكون من الأسهل كثيرًا تحسين الواجهة الأمامية للصفحة في المستقبل، كما أن تحسين الإدخال والإخراج لخادم الويب الخاص بك سيعمل أيضًا يكون أسهل بكثير. عندما يشير البرنامج إلى ملفات الموارد، يجب أن تكون هناك طريقة معالجة موحدة يمكن إكمال العديد من الأشياء تلقائيًا داخل الطريقة، مثل دمج CSS/js في ملف، أو إضافة QUERYSTRING تلقائيًا بعد عنوان URI الذي تم إنشاؤه عند استخدام خدمة ذاكرة التخزين المؤقت، فإن إنشاء QUERYSTRING هو أبسط طريقة لتحديث ذاكرة التخزين المؤقت للخادم وذاكرة التخزين المؤقت للعميل.
كما ذكرنا سابقًا، سيتم نسخ قاعدة البيانات، وقد تحتوي على العديد من الأساتذة والعبيد، وقد يتم تقسيمها. في عملية معالجة البيانات في برنامجنا، من الأفضل تجريدها ووضعها في طبقة منفصلة. خذ نموذج MVC الشائع كمثال، وهو وضع طبقة بيانات أسفل الطبقة M. طبقة البيانات هذه ليست JDBC/PDO/ActiveRecord المعروفة، وما إلى ذلك، ولكنها طبقة بيانات الوصول الخاصة بك، والتي تعرض الأساليب فقط. إخفاء تفاصيل الوصول إلى البيانات. لا تخف من الكتابة القبيحة داخل طبقة البيانات هذه، ولكن يجب أن توفر جميع وظائف تخزين البيانات، ولا ترى الكلمات التي تتناول قاعدة البيانات على أي مستوى آخر. والسبب في ذلك هو أنه في حالة قاعدة بيانات علائقية واحدة، يمكنك تحديد...انضمام...أو مباشرة INSERT...INTO...، ولكن يمكنك تخزين بعض الجداول في قاعدة بيانات ذات قيمة رئيسية، أو بعد ذلك، يجب تغيير جميع البيانات والأساليب الأصلية. إذا كانت متناثرة للغاية، فسيتم بذل الكثير من الجهد أثناء عملية الزرع، أو سيتم الحصول على نموذج كبير جدًا. فيما يتعلق بالتصميم على مستوى البيانات، حاول تجنب استعلامات JOIN، حيث يمكننا إجراء المزيد من التكرار والتخزين المؤقت، حيث يحتاج كل نوع من البيانات إلى استعلام واحد فقط ثم دمجه في برنامجك. بالنسبة لمجموعات البيانات الأكثر تعقيدًا، عندما لا تكون المتطلبات في الوقت الفعلي عالية، يمكن استخدام المعالجة غير المتزامنة، ولا يحصل المستخدمون على النتائج المعالجة إلا عند الوصول. عند التعامل مع المفاتيح الأساسية، تجنب استخدام المعرفات المتزايدة تلقائيًا واستخدم القيم الفريدة التي تم إنشاؤها بواسطة قواعد معينة كمفاتيح أساسية. هذا المفتاح الأساسي هو أبسط استراتيجية توزيع للمشاركة. حتى إذا كنت تستخدم معرف الزيادة التلقائية، فمن الأفضل استخدام منشئ معرف الزيادة التلقائية. وإلا، إذا تمت كتابة قاعدة البيانات التابعة عن طريق الخطأ، فسوف يتعارض المفتاح الأساسي بسهولة.
كما ذكرنا سابقًا، هناك بعض ذاكرات التخزين المؤقت التي تحجب الجزء الأمامي من قاعدة البيانات الخاصة بنا. لا تعامل ذاكرة التخزين المؤقت لاستعلام MySQL كذاكرة تخزين مؤقت. عندما يكون التطبيق معقدًا بعض الشيء، ستصبح ذاكرة التخزين المؤقت للاستعلام عبئًا. يتكامل التخزين المؤقت بشكل وثيق مع قاعدة البيانات والأعمال، نظرًا لارتباطه الوثيق بالأعمال، لا يوجد نهج واحد يناسب الجميع. ولكن لا يزال لدينا بعض القواعد التي يجب اتباعها. القاعدة 1: كلما اقتربنا من الواجهة الأمامية، زادت دقة ذاكرة التخزين المؤقت. على سبيل المثال، يتم تخزين الصفحة بأكملها مؤقتًا في الواجهة الأمامية للويب، ويتم تخزين جزء من الصفحة مؤقتًا في المستوى التالي، ويتم تخزين سجل واحد في المنطقة مؤقتًا في المستوى التالي. لأنه كلما اقتربنا من الواجهة الخلفية، زادت مرونة قابلية التشغيل لدينا، كما أصبحت كتابة كود الواجهة الأمامية الذي يتغير كثيرًا أسهل. من الناحية العملية، نظرًا لأن متطلبات المنتج تتغير بسرعة كبيرة وأن دورة التكرار تصبح أقصر فأقصر، فمن الصعب أحيانًا التمييز بوضوح بين وحدة التحكم والنموذج، وهو أمر لا مفر منه على مستوى وحدة التحكم، ولكن من الضروري التأكد من ذلك إذا حدث ذلك، يجب ألا تؤثر ذاكرة التخزين المؤقت التي يتم تشغيلها على وحدة التحكم على الأطراف الأخرى التي تطلب البيانات، أي أنه يجب التأكد من أن هذه البيانات المخزنة مؤقتًا يتم استخدامها بواسطة وحدة التحكم هذه فقط. القاعدة الثانية: لا يمكن للبرنامج أن يرتكب أخطاء دون التخزين المؤقت. عند عدم مراعاة تأثير الانهيار الجليدي الناتج عن إبطال ذاكرة التخزين المؤقت، يجب أن يحتوي برنامجك على ذاكرة تخزين مؤقت وأن يكون كما هو بدون ذاكرة تخزين مؤقت افسدت. عندما يكون التخزين المؤقت ضروريًا، فإن إعطاء رسالة خطأ للمستخدم أفضل من إعطاء رسالة مضللة. القاعدة 3: يجب أن تكون تحديثات ذاكرة التخزين المؤقت ذرية أو آمنة لمؤشر الترابط، خاصة عند استخدام التخزين المؤقت السلبي، فمن المحتمل جدًا أن يتم تحديث نفس ذاكرة التخزين المؤقت عندما يصل إليها مستخدمان، وعادةً لا تكون هذه مشكلة كبيرة ويمكن إعادة بناء ذاكرة التخزين المؤقت بعد انتهاء صلاحيته، قد يكون هذا أحد أسباب التفاعل المتسلسل. القاعدة 4: التخزين المؤقت له تكلفة أيضًا. ليس فقط تكلفة التكنولوجيا، ولكن أيضًا تكلفة وقت العمل. إذا كانت الوظيفة تستخدم التخزين المؤقت ولم تستخدمه، فإن الفرق في حجم الوصول المتوقع صغير، ولكن استخدام التخزين المؤقت سيزيد من التعقيد، فلا داعي لإضافة علامة TODO وإضافة معالجة التخزين المؤقت في التكرار التالي.
كما ذكرنا سابقًا، تخزين الملفات مستقل، لذا فإن جميع عمليات الملف تتم عن بعد. يمكنك توفير واجهة RESTful بسيطة جدًا على خادم الملفات، أو يمكنك توفير خدمة xmlrpc أو json. يتم إخطار جميع الملفات التي تم إنشاؤها ومعالجتها بواسطة خادم WEB إلى خادم الملفات من خلال الواجهة، ولا يحتاج خادم الويب نفسه إلى ذلك لتوفير أي تخزين للملفات. ستجد أن رفع الصور وحفظ المقالات على العديد من المواقع الكبيرة يتم في خطوتين، لهذا السبب.
ما ورد أعلاه قد قيل بالفعل من قبل عدد لا يحصى من الأشخاص، وقد كررته للتو بكلماتي الخاصة بناءً على المقالات السابقة. إن جوهر التحليل الحقيقي بسيط للغاية - بالإضافة إلى الطبقات المنطقية الوظيفية الجيدة، نحتاج أيضًا إلى التصميم واجهات منفصلة لاستدعاءات الموارد الخارجية مثل تخزين قاعدة البيانات، والتخزين المؤقت، وقوائم الانتظار، وخدمات الملفات. يمكنك أن تتخيل أن برنامجك يعمل على Amazon EC2 ويستخدم جميع خدمات الويب الخاصة به التخزين هو S3 الخاص به والفرق الوحيد هو أن واجهة Amazon عبارة عن مكالمة عن بعد، وواجهةك عبارة عن مكالمة داخلية.
إن ربط خدمة الدعم يعني أن استبدال MySQL بـ PostgreSQL لا يتطلب تغييرات في برنامج معالجة الأعمال، ولا يحتاج فريق الترحيل إلى التواصل كثيرًا مع فريق تطوير الأعمال، بل يعني أن فريق تطوير الأعمال يقوم ببرمجة الواجهة بدلاً من ذلك من برمجة قاعدة البيانات، فهذا يعني أن الأداء لن يتباطأ بسبب خطأ مطور الأعمال.
إذا لم تكن مهتمًا بمحو الأمية البرنامجية، فما عليك سوى إلقاء نظرة هنا——
بعد الانتهاء من تصميم المنتج وبناء إطار عمل البرنامج، قد تنشأ تعارضات في هذه المرحلة. هناك شكاوى مستمرة من مصممي المنتجات من أن أفكارهم لا تحقق النتائج المرجوة، كما يشتكي المبرمجون من أن تصميمات المنتجات غير واقعية. يرجع هذا النوع من الشكاوى في الغالب إلى حقيقة أن موظفي المنتج لا يفهمون التكنولوجيا وأن الموظفين الفنيين لا يفهمون المنتجات. بالمعنى الواسع، تشمل المنتجات استراتيجيات السوق، وأساليب التسويق، والتصميم الوظيفي. عند الجدال حول المنتجات والتقنيات، غالبًا ما يكون التركيز على الوظيفة، ولكن التركيز الفعلي يكون على تكلفة تحقيق هذه الوظيفة والفوائد التي توفرها هذه الوظيفة. يمكن أن تجلب ما إذا كان يمكن تحويلها وما إذا كان يمكن أن تؤخذ بعين الاعتبار. إذا كان ذلك ممكنا، حل النزاع. إذا لم يكن الأمر كذلك، اقلب العملة المعدنية وشاهد الحظ. هناك العديد من الأمثلة على المؤشرات التي تتلاشى بسبب تحسين الوظيفة، أو التأخير في القتال بسبب تأخير المشروع. يركز صناع القرار الراديكاليون على الفوائد، ويركز صناع القرار المحافظون على الخسائر، وسوف يفكر صناع القرار الأذكياء في ما إذا كانت المشكلة خطيرة حقًا.
لا أحد يستطيع التنبؤ بما سيحدث في المستقبل، وإلا فإن نصف بدء مشروع تجاري يعتمد على الحظ. ولكن هناك دائمًا أشياء يمكن قولها بدقة، وعليك الاعتماد على البيانات لتتحدث عن نفسها.
ليس 100٪، ولكن 99.9٪ من مواقع الويب قامت بتثبيت كود إحصائيات الوصول، حتى http://zhiyi.us الخاص بي ليس استثناءً، وتتحدث شبكة Xinwen دائمًا عن اتخاذ القرار العلمي والتطور العلمي. مع الإحصائيات، هناك أشياء كثيرة يمكن تحديدها. على سبيل المثال، يمكنك تحليل القنوات التي تتمتع بأقل تكلفة اكتساب للفرد استنادًا إلى معدل تحويل المصدر المستهدف، وتخمين أسباب معدلات ارتداد المستخدم استنادًا إلى الوصول إلى محتوى المصدر، وتحديد ما إذا كان موضع الارتباط معقولًا استنادًا إلى نقر المستخدم سلوك. اجمع البيانات بطرق مختلفة للعثور على الروابط الداخلية، وتحليل العوامل الداخلية والخارجية، وصياغة الاستراتيجيات المقابلة، وتقليل القرارات المزعجة. يعد الاعتماد على البيانات لدعم العمليات أمرًا احترافيًا للغاية، على الرغم من أنني لا أفهم النماذج الرياضية العميقة وحسابات الصيغ المعقدة، إلا أنني تعلمت تدريجيًا أن B بسبب A، وC بسبب A وB. ولا يزال الأمر بسيطًا نسبيًا. .
مؤلف المقال: Liu Zhiyi (يرجى الإشارة إلى رابط المصدر والمؤلف عند إعادة الطباعة)
مصدر المقال: http://zhiyi.us/