أي ضجيج مضحك للغاية عندما تنظر إليه من الجانب. أقل مضحكة عندما تتورط فيه مباشرة.
سقط Hype Go في مكان ما في عام 2014 ، عندما قرر مؤلفو التطبيقات التي لديها 1000RPM (طلبات في الدقيقة) فجأة كواحد يحتاجون إليه بشكل عاجل التزامن ، لأن 1000RPM كانت على وشك أن تتحول إلى 1000RPS (وهو أيضًا ليس كثيرًا ، في الحقيقة).
كانت نتيجة الضجيج أن العديد من الأشخاص الذين اعتادوا على بنية MVC للتطبيق انضموا إلى Go ، سواء كان Spring أو Django أو Ruby on Rails. وهذه الهندسة ، مثل البومة على الكرة الأرضية ، بدأوا في التراجع. هكذا ظهرت الكوادر مثل Beego و
Revel . توفي Revel بأمان ، على الرغم من أنهم ما زالوا يحاولون التخلص منه. ولكن أريد أن أتحدث عن Beego بشكل منفصل.
قدم ريتشارد إنج إسهامًا كبيرًا في الترويج لبيجو بين الجماهير بمجموعته من المقالات
بعنوان "كلمة لبيجو" . عمليا "إنجيل ريتشارد". ومن المفارقات أنه على الرغم من حقيقة أن ريتشارد يروج لجو بشكل محموم ، فهو نفسه لا يكتب عليها.
بدوره ، عملت مع Go ، والأسوأ من ذلك ، مع Beego ، لقد عملت كثيرًا. وأستطيع أن أقول إن هذا من الواضح أنه ليس الطريقة التي يجب أن تسير بها عملية التطوير.
دعونا نلقي نظرة على بعض الجوانب الأساسية لبرنامج Beego ، ولماذا تتعارض مع أفضل الممارسات في Go ، وفي الصناعة ككل.
هيكل المجلد
أعرب روبرت سي مارتن ، المعروف باسم
العم بوب ، مرارًا وتكرارًا عن فكرة أن بنية التطبيق يجب أن تنقل جوهرها. يحب بشدة إعطاء مثال مع الكاتدرائية ، والتي يمكن رؤيتها من الأعلى ، وفهم على الفور أن هذه الكاتدرائية.
انتقد روبرت مرارا روبي أون ريلز بسبب هيكل المجلد الخاص به - وحدات التحكم ، والنماذج ، وجهات النظر ، كل هذا. تكمن المشكلة في هذا النهج في أن تطبيق جورب الأكثر مبيعًا سيبدو تمامًا مثل تطبيق طلب الطعام. ولفهم جوهر التطبيق ، ستحتاج إلى الصعود إلى مجلد بعض النماذج ومعرفة نوع الكيانات التي ينتهي بنا الأمر.
هذا هو السلوك Beego المرضى الذي يتكرر. في الوقت الذي انتقل فيه نفس Spring نحو التصميم المستند إلى المجال وجوهر بنية المجلد ، فإن تطبيق Beego يفرض استخدام هيكل أصبح مضادًا.
لكن المشكلة أكثر خطورة. بالنسبة لـ Go ، لا يوجد فصل بين بنية المجلد وهيكل الحزمة. لذلك ، في Beego و UsersController و OrdersController سيكون ضمن حزمة واحدة - وحدات التحكم. وإذا كان لديك نوعان من وحدات التحكم ، تلك التي تخدم واجهة المستخدم وتلك التي يتم استخدامها لواجهة برمجة التطبيقات ، علاوة على ذلك ، في مجتمع لائق ، هل يتم إصدارها بشكل عام؟ ثم الاستعداد لالنزوات مثل apiv1.
ORM
الغريب في الأمر ، Beego ، كونه روبي على Rails غير ناجح ، لا يستخدم نمط ActiveRecord. ORM له هو مشهد غريب للغاية. إذا كانت العمليات الأساسية تمامًا ، مثل قراءة سطر / كتابة سطر ، لا تزال مناسبة ، فعلى سبيل المثال ، تبدو كأنها عينة بسيطة (فيما يلي ، يتم أخذ الأمثلة مباشرة من الوثائق):
qs.Filter("profile__age__gte", 18)
لكن المشكلة الرئيسية في Beego ORM ليست حتى أنك تحتاج إلى التعامل مع اللغة المسجلة الملكية ، بل إنها تستخدم جميع ممارسات Go الأسوأ ، سواء كانت آثارًا جانبية على الاستيراد:
import ( _ "github.com/go-sql-driver/mysql" _ "github.com/lib/pq" _ "github.com/mattn/go-sqlite3" )
أو تسجيل النماذج في init ():
func init(){ orm.RegisterModel(new(User)) }
تفضل لنفسك ، حتى لو كنت لا تزال تقرر لسبب غير مفهوم للعمل مع Beego ، لا تستخدم Beego ORM. إذا كانت حياتك بدون ORM ليست لطيفة (وماذا تفعل في عالم Go ، عزيزي؟) ، استخدم
GORM . إنه مدعوم على الأقل. خلاف ذلك ،
"قاعدة بيانات / sql" سوف تساعدك.
أداة النحل
يتم نسخ أداة سطر الأوامر ، والتي تسمى ببساطة
Bee ، من روبي أون ريلز. ولكن فقط إذا كان هناك في عالم RoR قضبان وكان أشعل النار ، فإن النحلة مثل هذه القمامة لكل شيء. هو وتطبيق MVC لـ 'boostrap' ، وتشغيل الترحيل ، وسيبدأ مراقب الملفات. هذا الأخير هو مشكلة أخرى. بعد كل شيء ، ما هي واحدة من المزايا الرئيسية ل Go؟ ما يبدأ محليا أقرب ما يمكن إلى ما يبدأ في الإنتاج. إذا كنت لا تستخدم النحل ، بالطبع.
التوجيه التلقائي
Go هي لغة مكتوبة بشدة لا تدعم إما الوراثة أو التعليقات التوضيحية. كيفية تشكيل إطار عمل MVC على هذا؟ من خلال قراءة التعليقات وتوليد الملفات ، بالطبع.
يبدو شيء مثل هذا:
الأدلة ، كما ترون ، هي صفر. لا تتلقى وظيفة () وظيفة أو إرجاع أي شيء على الإطلاق. http.Request؟ لا ، لم يسمع.
حسنا ، كيف يعمل كل التوجيه؟ عند بدء تشغيل النحلة سيئة السمعة ، يتم إنشاء ملف آخر ، commentsRouter_controllers.go ، والذي يحتوي على مثال على هذا الرمز الرائع:
func init() { beego.GlobalControllerRouter["github.com/../../controllers:ObjectController"] = append(beego.GlobalControllerRouter["github.com/../../controllers:ObjectController"], beego.ControllerComments{ Method: "Post", Router: `/`, AllowHTTPMethods: []string{"post"}, MethodParams: param.Make(), Filters: nil, Params: nil}) ... }
انظر ، لا تنسَ تجديد و "الالتزام" بهذا الملف بعد كل تغيير. حتى وقت قريب ، كان الموقف أكثر حزنًا ، وخلال الاختبارات تم إنشاء هذا الملف تلقائيًا ، لذلك تعرفت بالفعل على مشكلات الإنتاج. يبدو في الإصدارات الأخيرة تم إصلاح هذا السلوك الغريب.
اختبار المكون
وهكذا نأتي إلى موضوع الاختبار. Go ، بخلاف معظم لغات البرمجة الأخرى ، يأتي مع إطار اختبار خارج الصندوق. بشكل عام ، فلسفة Go هي أن الاختبار يجب أن يجلس بجوار ملف الاختبار. لكننا في عالم MVC ، بصق على فلسفة Go ، أليس كذلك؟ لذا ، يرجى التفضل بوضع جميع اختباراتك في / اختبار الأب ، كما هو
وارد لنا.
وهذا ليس تافهًا ، لأنه ، على ما أذكر ، في مجلد Go package ==. وإذا كان الاختبار الموجود في الحزمة نفسها يمكنه استدعاء الطريقة الخاصة ، فإن الاختبار الموجود في حزمة أخرى لم يعد موجودًا.
لكن حسنًا ، سيكون كل شيء مقصورًا على بنية المجلد. من الصعب ، من حيث المبدأ ، اختبار شفرة Beego ، لأن كل شيء فيها تأثير جانبي.
هذه هي الطريقة التي يستعلم بها جهاز توجيه Beego:
import ( _ "github.com/../../routers" )
نفس القصة مع البرامج الوسيطة ، ومع وحدات التحكم التي ذكرتها سابقًا.
الوثائق
انها مثل مهندس البرمجيات بالنسبة لي على الكعكة. وثائق BeeGo جيدة مثل الصينية الخاصة بك. لا ، التعليقات المكتوبة باللغة الصينية داخل الكود خلال العامين الماضيين تخلصت منها.
الآن في الصينية ، لا يوجد سوى عدد قليل من طلبات السحب:
وخاصة في القضايا:
بدلا من الاستنتاج
إذا كان لديك فريق من كتاب شفرة Ruby / PHP / Python وكنت ترغب في ترجمتها على وجه السرعة ، فإن أسوأ شيء يمكنك القيام به هو جعلهم يتحولون إلى إطار عمل MVC على Go. MVC ككل هو نمط معماري جيد جدًا ، وفي Go يكون هذا غير صحيح بشكل عام. أو ، إذا كنت متأكدًا تمامًا من أن لا شيء سوى Go سيوفر لك ، فدعهم يتعلمون ويكتبون بالطريقة التي يتم قبولها بها في Go - بشكل مسطح وصريح قدر الإمكان. أو ربما يعرفون بشكل أفضل ، مع أي أداة لحل مهامهم؟