لقد طُلب مني كتابة هذا المفهوم من خلال مشكلة واجهتها مرارًا وتكرارًا عندما أتيت إلى مشروع جديد: لمدة 5 سنوات من التطوير التجاري ، كنت دائمًا "محظوظًا" بالوصول إلى مشروع يغادره المطور الرئيسي. وفي كل مرة ورثت فيها قاعدة رمز ضخمة - لم يتم فهم قوانين عملها إلا من قبل خالقها. أنا ، بدوره ، بعد السنة الأولى بالفعل ، اكتسبت عادة التطوير من خلال التصميم والتصميم من خلال التعليقات. ما أريد أن أشاطركم تحت الخفض:
نموذج التنمية من خلال التعليق
الفكرة: التصميم من خلال التعليقات. التعليمات البرمجية.
- فكرة
يمكن أن يكون بادئ الفكرة إما أنت أو أي شخص آخر - على سبيل المثال ، PM (TimLead).
مثال على فكرة: "تحتاج إلى مسح رقم الهاتف من أحرف مثل" + و - ، بين قوسين ومسافات "، بحيث يكون الإخراج مجرد مجموعة من الأرقام. الميزة مطلوبة لتنفيذ البحث عن طريق رقم الهاتف - تم إدخالها بأي طريقة."
- تصميم من خلال التعليقات
كتابة التعليقات التي تصف منطق البرنامج.
مثال التصميم من خلال التعليقات:
المفسد<?php namespace App\Services; use App\Entity\Users; use Doctrine\ORM\EntityManagerInterface; use Doctrine\ORM\EntityManager; class PhoneService {
- كتابة التعليمات البرمجية
نحتاج الآن إلى تحويل إسقاط تعليقنا إلى رمز:
على سبيل المثال:
المفسد <?php namespace App\Services; use App\Entity\Users; use Doctrine\ORM\EntityManagerInterface; use Doctrine\ORM\EntityManager; class PhoneService {
ما هذا؟
لماذا أحتاج إلى التعليقات ، الكود ، ولذا فمن الواضح؟
سيقول الكثيرون أن الكود هو النص - وهو سهل القراءة. ويجب أن أذكر أن هذا الرمز هو وسيلة للتعبير عن أفكارك من خلال بناء جملة اللغة التي تستخدمها. وعندما نكتب منطقًا معقدًا - نستخدم أسلوبنا الخاص ، من نواح كثيرة ، أسلوبًا فريدًا لاستخدام بناء الجملة هذا. ولكن إذا كنا في مرحلة التصميم - فسوف نصف منطقنا بلغة مقبولة بشكل عام ، ثم نعود إلى الرمز بعد 3 سنوات ، وسنتفهم كيفية عمله ورمزنا. وريث ، تماما كما غير قادر على معرفة ذلك. باستخدام التصميم من خلال التعليقات - يقلل من إنتروبيا مشروعك ويجعل الكود أكثر جمالا.
لماذا أحتاج إلى تصميم ، هل يمكنني الجلوس وكتابة كل شيء مرة واحدة؟
إذا كنت تطرح هذا السؤال ، فأنت بحاجة فقط إلى قراءة " الكود المثالي " بشكل عاجل لستيف مكونيل . هناك ، هذا المفهوم هو أكثر من الكشف عنها.
سأقدم اقتباس صغير:
في مرحلة تصميم الكود ، عادة ما يتم العثور على 75 ٪ من الأخطاء. إذا لم يتم العثور عليها ، وأود أن refactor.
في الواقع ، في مرحلة التصميم ، يمكنك أن تفهم أن منطق الأعمال المتصور لن يعمل كما هو مخطط له ، أو يمكنك أن ترى طريقة أفضل لحل مشكلة معينة. ولن تحتاج إلى العودة لاحقًا وإعادة تكوين قطعة من المنطق - والتي لا تعمل تمامًا كما هو مقصود.
هل أحتاج إلى التعليق على كل شيء؟
أعطيت أمثلة الابتدائية أعلاه. إنها مفهومة تمامًا وبدون تعليق ، لكنني ما زلت استخدم نهج IC-DC لتنفيذها. لأن لا أريد أن ينمو الكود الخاص بي. لقد زرت العديد من المشاريع حيث كان من الضروري إعادة كتابة معظم المشاريع من البداية على وجه التحديد بسبب الانتروبيا الهائلة فيها. فكر فيما إذا كنت تريد حذف المشروع الذي أمضى شهورًا أو سنوات من حياتك. إذا كانت الإجابة "لا" ، فأعتقد أنه من المفيد استخدام هذا النهج دائمًا. لأن إذا تركت المشروع أو بعد بضع سنوات ، تظهر تقنية جديدة يمكنها تلبية الاحتياجات بشكل أفضل من الحل القديم الخاص بك - سوف تساعدك IC-DC على تنفيذ التغييرات على النحو الأمثل ، لتصل إلى الحد الأدنى من الوظائف ، لأن الموظف الجديد أو الموظف الجديد سوف يفهم كيف يعمل ولماذا.