هنا اقتباس من Linus Torvalds لعام 2006 :

أنا مؤيد كبير لتطوير الشفرة حول البيانات ، وليس العكس ، وأعتقد أن هذا هو أحد الأسباب وراء نجاح git ... في الواقع ، أنا أزعم أن الفرق بين مبرمج سيئ ومفيد جيد هو ما إذا كان يفكر أكثر المهم رمز الخاص بك أو هياكل البيانات الخاصة بك. المبرمجين السيئين قلقون حول الكود. المبرمجون الجيدون يقلقون بشأن هياكل البيانات وعلاقاتهم.

يشبه إلى حد كبير "قاعدة تقديم" إريك ريموند لعام 2003 :

حول المعرفة إلى بيانات بحيث يصبح منطق البرنامج غبيًا وموثوقًا به.

فيما يلي ملخص لأفكار مثل أفكار روب بايك لعام 1989 :

يهيمن البيانات. إذا اخترت هياكل البيانات الصحيحة وقمت بتنظيم كل شيء جيدًا ، فستكون الخوارزميات دائمًا بديهية. تلعب هياكل البيانات ، وليس الخوارزميات ، دورًا رئيسيًا في البرمجة.

يقتبس من فريد بروكس من عام 1975 :

العرض التقديمي هو جوهر البرمجة

وراء إتقانها هو الإبداع الذي يجعل
برامج اقتصادية وسريعة. هذا هو دائما تقريبا النتيجة.
اختراق استراتيجي ، وليس مهارة تكتيكية. في بعض الأحيان استراتيجية جدا
الاختراق هو خوارزمية ، مثل تحويل فورييه السريع ،
اقترحه Cooley و Tukey ، أو استبدال مقارنات n ² بـ n log n عند الفرز.

في كثير من الأحيان ، يأتي اختراق استراتيجي نتيجة لهذا العرض
البيانات أو الجداول. جوهر البرنامج هنا. أرني المخططات الانسيابية دون إظهار الجداول ، وسأظل في ضلال. أرني بك
من المحتمل ألا تكون هناك حاجة للجداول ومخططات انسيابية: ستكون واضحة.

لذلك ، منذ ما يقرب من نصف قرن ، قال الأشخاص الأذكياء مرارًا وتكرارًا: التركيز على البيانات أولاً. لكن في بعض الأحيان يبدو أن هذه هي أذكى نصيحة ينسىها الجميع.

سأقدم بعض الأمثلة الحقيقية.

نظام متدرج للغاية فشل

تم إنشاء هذا النظام في الأصل مع توقع قابلية مذهلة لا يصدق مع حمولة كبيرة على وحدة المعالجة المركزية. لا شيء متزامن. عمليات الاسترجاعات والصفوف ومجمعات العمل في كل مكان.

ولكن كان هناك مشكلتين. الأول هو أن "تحميل المعالج" لم يكن مكثفًا - استغرقت مهمة واحدة كحد أقصى بضع مللي ثانية. لذلك معظم الهندسة المعمارية تضر أكثر مما تنفع. المشكلة الثانية هي أن "النظام الموزع للغاية القابل للتطوير" كان يعمل في الواقع على جهاز واحد فقط. لماذا؟ لأن كل الاتصالات بين المكونات غير المتزامنة تم تنفيذها باستخدام الملفات في نظام الملفات المحلي ، والتي أصبحت الآن عنق الزجاجة لأي مقياس. لم يرتبط التصميم الأصلي بالبيانات على الإطلاق ، باستثناء حماية الملفات المحلية باسم "البساطة". تم تخصيص الجزء الرئيسي من المشروع لكل هذه البنية الإضافية ، والتي كانت "ضرورية" للتعامل مع "الحمل الثقيل" على وحدة المعالجة المركزية.

الهندسة الموجهة للخدمة التي لا تزال موجهة نحو البيانات

اتبع هذا النظام تصميم الخدمات المصغرة من التطبيقات ذات الأغراض الفردية مع REST APIs. كان أحد المكونات عبارة عن قاعدة بيانات يتم تخزين المستندات فيها (بشكل أساسي الإجابات على النماذج القياسية والمستندات الإلكترونية الأخرى). وبطبيعة الحال ، قامت بتعيين واجهة برمجة التطبيقات لحفظ البيانات واسترجاعها ، ولكن بسرعة كانت هناك حاجة لوظائف بحث أكثر تعقيدًا. اعتبر المطورون أن إضافة هذه الوظيفة إلى مستند API موجود يتناقض مع مبادئ تصميم الخدمات الميكروية. نظرًا لأن "البحث" يختلف اختلافًا أساسيًا عن "get / put" ، يجب ألا تجمع الهندسة المعمارية بينها. بالإضافة إلى ذلك ، فقد خططوا لاستخدام أداة تابعة لجهة خارجية للعمل مع الفهرس ، وبالتالي فإن إنشاء "بحث" خدمة جديدة أمر منطقي أيضًا لهذا السبب.

نتيجة لذلك ، تم إنشاء واجهة برمجة تطبيقات للبحث وفهرس البحث ، والتي أصبحت أساسًا نسخة مكررة من البيانات الموجودة في قاعدة البيانات الرئيسية. تم تحديث هذه البيانات بشكل ديناميكي ، لذلك يجب أن يرسل أي مكون قام بتغيير بيانات المستند من خلال قاعدة بيانات API الرئيسية طلبًا لتحديث الفهرس من خلال واجهة برمجة تطبيقات البحث. باستخدام REST API ، لا يمكن القيام بذلك دون وجود شرط سباق ، لذلك فإن مجموعتي البيانات سوف تنفد متزامنة من وقت لآخر.

على الرغم من ما وعدت به الهندسة المعمارية ، كانت هناك صلة وثيقة بين واجهات برمجة التطبيقات من خلال التبعيات الخاصة بالبيانات. في وقت لاحق ، أدرك المطورون أنه يجب دمج فهرس البحث مع خدمة مستندات شائعة ، مما جعل النظام أكثر قابلية للصيانة. تعمل ميزة Doing One على مستوى البيانات ، ولكن ليس على مستوى الفعل.

مقطوع وحدات شكلي من الطين

كان هذا النظام بمثابة نوع من خط أنابيب النشر الآلي. أراد فريق التطوير الأصلي جعل أداة مرنة بدرجة كافية لحل مشكلات النشر في الشركة. لقد كتبوا مجموعة من مكونات المكونات الإضافية مع نظام ملفات التكوين الذي لم يقم بتكوين المكونات فحسب ، بل وعمل أيضًا كلغة خاصة بالمجال (DSL) لبرمجة كيفية ملائمة المكونات في خط الأنابيب.

تقدم سريعًا إلى بضع سنوات ، وتحولت الأداة إلى "البرنامج ذاته". كانت هناك قائمة طويلة من الأخطاء المعروفة التي لم يسبق لأحد إصلاحها. لا أحد يريد أن يلمس الكود خوفاً من كسر شيء ما. لا أحد استخدم مرونة DSL. قام جميع المستخدمين بنسخ ولصق نفس تكوين العمل المضمون مثل أي شخص آخر.

ما الخطأ الذي حدث؟ على الرغم من أن مستند المشروع الأصلي يستخدم غالبًا كلمات مثل "معياري" و "غير متصل" و "قابل للتوسيع" و "مخصص" ، إلا أنه لم يقل شيئًا على الإطلاق عن البيانات. وبالتالي ، تمت معالجة تبعيات البيانات بين المكونات بطريقة غير منظمة باستخدام فقاعة JSON الشائعة عالميًا. مع مرور الوقت ، قدمت المكونات افتراضات غير موثقة أكثر فأكثر حول ما تم تضمينه أو عدم تضمينه في فقاعة JSON. بالطبع ، سمحت DSL بإعادة ترتيب المكونات بأي ترتيب ، لكن معظم التكوينات لم تنجح.

الدروس

لقد اخترت هذه المشروعات الثلاثة ، لأنه من السهل شرح الأطروحة العامة باستخدام مثالهم ، دون لمس الآخرين. بمجرد أن حاولت إنشاء موقع على شبكة الإنترنت ، وبدلاً من ذلك ، علقت نوعًا ما من قواعد بيانات XML servile التي لم تحل حتى مشاكل البيانات الخاصة بي. كان هناك مشروع آخر تحول إلى ما يشبه نصف وظيفة make ، مرة أخرى لأنني لم أفكر في ما أحتاجه حقًا. لقد كتبت بالفعل عن الوقت الذي قضيته في إنشاء تسلسل هرمي لا نهاية له من فئات OOP التي كان يجب أن تكون مشفرة في البيانات .

تحديث:

على ما يبدو ، لا يزال الكثيرون يعتقدون أنني أحاول السخرية من شخص ما. يعلم زملائي الحقيقيون أنني مهتم أكثر بإصلاح المشكلات الحقيقية ، وليس في إلقاء اللوم على أولئك الذين تسببوا في هذه المشاكل ، لكن هذا هو ما أفكر به في المطورين المشاركين في هذه المشاريع.

بصراحة ، حدث الموقف الأول بوضوح لأن مهندس النظام كان مهتمًا بتطبيق العمل العلمي أكثر من اهتمامه بحل مشكلة حقيقية. يمكن إلقاء اللوم على الكثير منا على هذا (أنا أيضًا) ، لكنه يزعج زملائنا حقًا. بعد كل شيء ، سيكون عليهم المساعدة في الدعم عندما نتعب من لعبة. إذا كنت تتعرف على نفسك ، لا تتعرض للإساءة ، فالرجاء التوقف فقط (على الرغم من أنني أفضل العمل مع نظام موزع على عقدة واحدة بدلاً من أي نظام في "قاعدة بيانات XML" الخاصة بي).

في المثال الثاني ، لا يوجد شيء شخصي. يبدو أحيانًا أن كل من حولك يقول كم هو رائع مشاركة الخدمات ، لكن لا أحد يتحدث عن متى يكون من الأفضل عدم القيام بذلك. يتعلم الناس في كل وقت من تجربتهم المريرة.

حدثت القصة الثالثة في الواقع لبعض من أذكى الناس الذين عملت معهم.

(نهاية التحديث).

السؤال "ماذا يقال عن المشاكل التي تنشأ عن البيانات؟" اتضح أن هذا الاختبار مفيد للغاية لتصميم نظام جيد. كما أنه مناسب جدًا لتحديد "الخبراء" الزائفين بنصيحتهم. مشاكل في بنية النظم المعقدة والمعقدة هي مشاكل في البيانات ، لذلك يحب الخبراء الخاطئون تجاهلها. سوف يعرضون لك بنية جميلة بشكل مدهش ، لكنهم لن يقولوا أي شيء عن البيانات المناسبة لها ، و (الأهم) البيانات التي لا تناسبها.

على سبيل المثال ، قد يقول خبير خاطئ أنه يجب عليك استخدام نظام pub / sub لأن أنظمة pub / sub مترابطة بشكل فضفاض وأن المكونات المزدوجة يمكن صيانتها. يبدو جميلًا ويعطي رسومات تخطيطية جميلة ، لكنه عكس التفكير. الحانة / الفرعية لا تجعل المكونات الخاصة بك فضفاضة. يوجد pub / sub نفسه مقترن بشكل فضفاض ، والذي قد يلائم أو لا يلبي احتياجات البيانات الخاصة بك.

من ناحية أخرى ، فإن البنية الموجهة للبيانات ذات التصميم الجيد هي ذات أهمية كبيرة. البرمجة الوظيفية ، وشبكة الخدمة ، و RPC ، وأنماط التصميم ، وحلقات الأحداث ، ومهما يكن ، فإن لكل شخص مزاياه الخاصة. لكن شخصياً ، رأيت أن أنظمة الإنتاج الأكثر نجاحًا تعمل على نظم إدارة قواعد البيانات القديمة المملة .