في هذه المقالة ، يحلل المؤلف مقدار الوقت الذي يقضيه في كتابة الكتب أو رمز البرنامج ، ويصل إلى نمط مثير للاهتمام. يمكن استخدامه لجدولة عمل المشروع.قانون هوفستادتر: أي عمل يستمر دائمًا لفترة أطول من المتوقع ، حتى إذا كنت تأخذ في الاعتبار قانون هوفستادتر.
- دوغلاس هوفستادتر ، جودل ، آشر ، باخ
تشترك كتابة النثر والرمز في الكثير. لكن التشابه الأكثر وضوحًا هو على الأرجح أنه لا يمكن للكتاب ولا المبرمجين إنهاء عملهم في الوقت المحدد. الكتاب سيئون السمعة بسبب كسر المواعيد النهائية. اكتسب المبرمجون سمعة الأشخاص الذين تختلف نتائجهم دائمًا بشكل خطير عن الحسابات الأولية. السؤال الذي يطرح نفسه: لماذا؟
اليوم كانت لدي فكرة عن كيفية الرد عليها. وأذهلني ما توصلت إليه من نتائج.
دراسة كتبي
كل من كتبي ،
Hello و startup و
Terraform: أطلقنا ونعمل ، كتبت في بيئة إنشاء كتب
Atlas ، والتي توفر إدارة جميع المحتوى باستخدام Git. هذا يعني أن كل سطر من النص وكل تحرير وكل تغيير تم الالتزام به في سجل الالتزام Git.
دعونا نتحقق من مقدار الجهد المبذول لكتابة كتابين.
مرحبا بدء التشغيللنبدأ بكتابي الأول. يحتوي على 602 صفحة وحوالي 190 ألف كلمة. لقد قمت بتشغيل
cloc في مستودع
Hello، Startup git وحصلت على النتائج التالية
(من أجل البساطة ، يتم التخلص من الأجزاء الكسرية):
تحتوي 602 صفحة على 26.571 سطرًا من النص. حصة الأسد مكتوبة في
AsciiDoc ، على غرار
Markdown . يستخدمه أطلس لكتابة أي محتوى تقريبًا. باستخدام HTML و CSS ، يحدد Atlas تخطيط الكتاب وبنيته. بالإضافة إلى ذلك ، هناك لغات برمجة أخرى (Java و Ruby و Python وليس فقط) ، حيث تتم كتابة أمثلة مختلفة للمواضيع التي تمت مناقشتها في الكتاب.
لكن 602 صفحة و 26.571 سطرًا هي النتيجة النهائية. فهي لا تعكس حوالي 10 أشهر من الكتابة والتغيير والتحرير والتدقيق والتعديلات الأسلوبية والبحث والملاحظات وغيرها من الأعمال التي تساهم في نشر الكتاب. لذلك ، للحصول على المزيد من الأفكار المفيدة ، استخدمت
git-quick-stats لتحليل سجل التزام الكتاب بالكامل.
لذا ، أضفت 163،756 سطرًا وحذفت 131،425 خطًا ، مما يعطي إجماليًا 295،181 سطرًا من المواد المعالجة. أي ، اتضح أنني كتبت أو حذفت ما مجموعه 295 181 سطرًا ، بقي منها 26 571 سطرًا. هذه النسبة تزيد قليلاً عن 10: 1. للحصول على كل سطر منشور ، كان علي أن أكتب 10 آخرين أولاً!
أعترف أن حساب عدد الأسطر التي تمت إضافتها وإزالتها من Git لا يمكن اعتباره مقياسًا مثاليًا لعملية التحرير. ولكن ، على الأقل ، يسمح لنا هذا بفهم أن الحساب البسيط لا يكفي لتقييم العمل المنجز. لم ينعكس جزء كبير من العملية على الإطلاق في سجل التزام Git. على سبيل المثال ، تمت كتابة الفصول القليلة الأولى في محرر مستندات Google قبل أن أنتقل إلى أطلس ، وتم إجراء العديد من التعديلات على جهاز الكمبيوتر الخاص بي دون التزامات.
على الرغم من حقيقة أن هذه البيانات أبعد ما تكون عن المثالية ، أعتقد أن النسبة الإجمالية لـ "المواد النصية الأصلية" إلى المنشورة هي 10: 1.
Terraform: نبدأ ونعملدعونا نتحقق مما إذا كانت هذه النسبة تنطبق على كتابي الثاني
Terraform: أطلقنا وعملنا ، والذي يحتوي على 206 صفحات وحوالي 52 ألف كلمة.
الناتج المبسط
cloc :
تتكون 206 صفحات من 8410 سطر من النص. مرة أخرى ، معظم النص مكتوب بلغة AsciiDoc ، على الرغم من أن هذا الكتاب يحتوي على المزيد من الأمثلة البرمجية المكتوبة بشكل رئيسي في HCL ، اللغة الرئيسية لـ Terraform. إلى جانبه ، هناك العديد من Markdowns التي استخدمتها لتوثيق أمثلة HCL.
سنستخدم
git-quick-stats للتحقق من تاريخ المراجعة لهذا الكتاب:
لمدة خمسة أشهر تقريبًا ، أضفت 32،209 وحذف 22،402 صفًا ، بإجمالي 54،611 صفًا معاد تدويره. تعاني دقة تقييم عملية تحرير هذا الكتاب أكثر من ذلك ، حيث بدأ العمل
كسلسلة من مشاركات المدونة التي مرت بمراجعة ملموسة قبل نقلها إلى Atlas و Git. يستغرق حجم مشاركات المدونة هذه نصف الكتاب على الأقل ، لذلك سيكون من المنطقي زيادة المعدل النهائي للنص المعالج بنسبة 50٪. أي أنه سيظهر 54611 * 1.5 = 81 916 سطرًا من النص القابل للتحرير ، مما ينتج عنه 8410 سطرًا.
ومرة أخرى ، نسبة حوالي 10: 1!
ليس من المستغرب أن الكتاب لا يلتزمون بالمواعيد النهائية. إذا كان من المفترض أن يقوم الجدول بتسليم كتاب من 250 صفحة ، فعندئذٍ يتبين عمليًا أنه في هذه العملية سنكتب 2500 صفحة.
ماذا عن البرمجة؟
كيف تسير التنمية؟ قررت التحقق من العديد من مستودعات git مفتوحة المصدر بمستويات نضج مختلفة: من بضعة أشهر إلى 23 عامًا.
terraform-aws-couchbase (2018)terraform-aws-couchbase عبارة عن مجموعة من الوحدات لنشر Couchbase وإدارتها على AWS ، والتي تم فتح شفرة المصدر الخاصة بها في 2018.
الناتج المبسط
cloc :
وإليك نتيجة التحقق
git-quick-stats :
نحصل على ما يصل إلى 37 693 سطرًا من كود العمل ، مما ينتج عنه 7481 سطرًا من الرمز النهائي بنسبة 5: 1. حتى في المستودع أقل من 5 أشهر ، كان علي إعادة كتابة كل سطر خمس مرات! ليس من المستغرب أن يكون تقييم تطوير البرامج معقدًا: لا نتخيل حتى أنه من أجل الحصول على 7.5 ألف سطر من الرمز النهائي ، يجب علينا بالفعل كتابة 35 ألف
دعونا نرى كيف تسير الأمور مع المنتجات القديمة.
Terratest (2016)Terratest هي مكتبة مفتوحة المصدر تم إنشاؤها في عام 2016 لاختبار رمز البنية التحتية.
الناتج المبسط
cloc :
نتائج
git-quick-stats :
هذه هي 49 126 سطر عمل من التعليمات البرمجية ، والتي تحولت إلى 6140 سطرًا من النص النهائي. بالنسبة إلى مستودع لمدة عامين ، كانت النسبة 8: 1. لكن Terratest لا يزال صغيرًا جدًا ، لذلك دعونا ننظر إلى المستودعات القديمة.
Terraform (2014)Terraform هي مكتبة مفتوحة المصدر تم إنشاؤها في عام 2014 لإدارة البنية التحتية باستخدام طرق البرمجة.
الناتج المبسط
cloc :
نتائج
git-quick-stats :
نحصل على 12،945،966 خط عمل من التعليمات البرمجية ، مما ينتج عنه 1،371،718 سطر من النتيجة النهائية. 9: 1 نسبة. توجد Terraform منذ ما يقرب من 4 سنوات ، ولكن لم يتم إصدار المكتبة حتى الآن ، لذلك حتى مع هذه النسبة ، لا يمكن تسمية قاعدة الرموز الخاصة بها حتى الآن ناضجة. دعونا ننظر إلى أبعد من ذلك في الماضي.
Express.js (2010)Express هو إطار JavaScript شائع مفتوح المصدر تم تطويره لتطوير الويب في عام 2010.
الناتج المبسط
cloc :
نتائج
git-quick-stats :
نحصل على 224 211 خط عمل من الكود ، يتم تخفيضه إلى 15 325 خطًا نهائيًا. النتيجة 14: 1. يبلغ عمر Express حوالي 8 سنوات ، وأحدث إصداراتها هي رقم 4.x. يعتبر إطار الويب الأكثر شيوعًا واختبارًا للمعركة لـ Node.js.
يبدو أنه بمجرد أن تصل النسبة إلى مستوى 10: 1 ، يمكننا القول بثقة أن قاعدة الكود "ناضجة" بالفعل. دعونا نتحقق مما يحدث إذا تعمقت أكثر في الماضي.
مسج (2006)jQuery هي مكتبة جافا سكريبت شعبية مفتوحة المصدر تم إصدارها في عام 2006.
الناتج المبسط
cloc :
نتائج
git-quick-stats :
مجموع 730،146 سطر عمل من التعليمات البرمجية ، مما أدى إلى 47،559 سطرًا من النتيجة النهائية. نسبة 15: 1 لمستودع عمره 12 عامًا تقريبًا.
دعنا نذهب قبل عشر سنوات أخرى.
MySQL (1995)MySQL هي قاعدة بيانات علائقية مفتوحة المصدر شائعة تم إنشاؤها في عام 1995.
الناتج المبسط
cloc :
نتائج
git-quick-stats :
نحصل على 585629999 خط عمل و 3666869 سطرًا من الرمز النهائي ونسبة 16: 1 لمستودع عمره ثلاثة وعشرون عامًا تقريبًا. واو! تم إعادة كتابة كل سطر من كود MySQL 16 مرة.
الاستنتاجات
النتائج العامة لكتبي هي كما يلي:
العنوان
| خطوط العمل
| خطوط الملخص
| النسبة
|
مرحبا بدء التشغيل
| 295 181
| 26،571
| 11: 1
|
Terraform: نبدأ ونعمل
| 81 916
| 8410
| 10: 1
|
وهنا جدول ملخص لمشاريع البرمجة المختلفة:
العنوان
| سنة الصنع
| خطوط العمل
| خطوط الملخص
| النسبة
|
terraform-aws-couchbase
| 2018
| 37693
| 7481
| 5: 1
|
مرعب
| 2016
| 49126
| 6140
| 8: 1
|
Terraform
| 2014
| 1294596969
| 371 718
| 9: 1
|
صريح
| 2010
| 224 211
| 15 325
| 14: 1
|
مسج
| 2006
| 730،146
| 559 47
| 15: 1
|
MySQL
| 1995
| 58562998
| 3666269
| 16: 1
|
ماذا تعني كل هذه الأرقام؟
القاعدة 10: 1 في النثر والبرمجةبالنظر إلى أن مجموعة البيانات الخاصة بي محدودة ، يمكنني فقط تقديم بعض الاستنتاجات الأولية:
- تبلغ نسبة المادة الأولية إلى "المنتج النهائي" للكتاب حوالي 10: 1. ضع هذا الرقم في الاعتبار عندما تناقش مع المحرر جدولًا زمنيًا لإرسال المواد. إذا كنت بحاجة إلى كتابة كتاب من 300 صفحة ، فعليك في الواقع كتابة حوالي 3 آلاف صفحة.
- يمكن استنتاج قاعدة مماثلة للبرامج الناضجة وغير العادية: نسبة حجم الشفرة المعالجة إلى الإجمالي هي 10: 1 على الأقل. ضع ذلك في الاعتبار عندما يطلب منك مدير أو عميل تقدير تكاليف الوقت. يتطلب تطبيق 10 آلاف سطر كتابة ما يقرب من 100 ألف سطر.
يمكن تلخيص هذه النتائج كقاعدة
10: 1 للكتابة والبرمجة :
تتطلب كتابة برنامج أو نص جيد إعادة كتابة كل سطر بمعدل 10 مرات.
الخطوات التالية
بالطبع ، لا يمكن اعتبار أسطر التعليمات البرمجية وأسطر النص مقياسًا مثاليًا. ولكن ، أعتقد ، إذا قمت بجمع كمية كافية من البيانات ، يمكنك تحديد ما إذا كانت قاعدة 10: 1 عالمية ومفيدة لتحديد الموعد النهائي لإكمال المشروع.
بعض الأسئلة التي أود تلقي إجابة عليها:
- هل من الممكن استخدام نسبة أسطر التعليمات البرمجية المعالجة إلى الأسطر النهائية كمقياس سريع لتقييم نضج برنامج معين؟ على سبيل المثال ، هل يمكننا الوثوق في حل مشاكل البنية التحتية الرئيسية لقواعد البيانات أو لغات البرمجة أو أنظمة التشغيل إذا وصلت هذه النسبة بالنسبة لهم على الأقل 10: 1؟
- هل يعتمد حجم نص العمل على نوع البرنامج؟ على سبيل المثال ، اكتشف بيل سكوت أنه في Netflix فقط حوالي 10 ٪ من كود واجهة المستخدم يصل إلى عام واحد ، ويتم إعادة كتابة 90 ٪ المتبقية في هذا الوقت بالكامل. ما هي سرعة استبدال الرمز للواجهة الخلفية وقواعد البيانات وأدوات سطر الأوامر وأنواع البرامج الأخرى؟
- ما النسبة المئوية من التعليمات البرمجية التي تتم معالجتها بعد الإصدار الأولي؟ أي ما هي نسبة العمل التي يمكن اعتبارها "دعم برمجيات"؟
إذا كنت مؤلفًا للكتب ويمكنك إجراء تحليل مماثل ، فسيسعدني معرفة نتائجك. وإذا كان لدى شخص ما الوقت لأتمتة مثل هذا التحليل ، فسيكون من الرائع التعرف على العلاقات الموجودة في مختلف المشاريع مفتوحة المصدر.
تحديث 13 أغسطسكشفت مناقشة
منشور على
Hacker News و
Red / R / برمجة نقطتين مهمتين أخريين:
- على ما يبدو ، تنطبق قاعدة مماثلة 10: 1 على الأفلام والصحافة والموسيقى والتصوير الفوتوغرافي! من كان يظن؟
- ترك القراء الكثير من التعليقات التي تفيد بأن تغيير حتى حرف واحد يمكن أن يحسب في Git كإدراج أو حذف خط ، لذلك فإن مؤشر 100 ألف خط متغير لا يعني أن كل سطر قد خضع للمعالجة.
الملاحظة الأخيرة صحيحة ، ولكن ، كما كتبت أعلاه ، لا تأخذ بياناتي في الاعتبار أنواعًا أخرى من التغييرات:
- لا أقوم بالتزام لكل سطر منفصل. يمكنني تغييره عشر مرات ، لكني ارتكب واحد فقط.
- الحالة الموصوفة في الفقرة السابقة هي أكثر صلة بالبرمجة. أثناء اختبار التعليمات البرمجية ، يمكنني تغيير سطر واحد 50 مرة ، أثناء تنفيذ التزام واحد فقط.
- تم إجراء العديد من دورات التحرير والكتابة خارج Git (تمت كتابة بعض الفصول في محرر مستندات Google أو متوسط ، وتم إجراء تعديلات أسلوبية في PDF).
أعتقد أن كل هذه العوامل تعوض خصوصية المحاسبة لإدراج أو حذف الخطوط في Git. بالطبع ، قد تكون تقديراتي غير دقيقة ، وستكون النسبة الحقيقية 8: 1 أو 12: 1. لكن بشكل عام ، الفرق ليس كبيرًا ، و 10: 1 يسهل تذكره.
تحديث 14 أغسطسأنشأ Github
Decagon مستودعًا يسمى
hofs-churn مع نص bash لحساب كمية الشفرة التي تم وضعها في المستودعات الخاصة بك بسهولة. استخدمه أيضًا لتحليل عدد من المستودعات ، مثل React.js و Vue و Angular و RxJava وغيرها الكثير ، وكانت النتائج مثيرة للاهتمام.
