التزامات تقليدية لن تنقذ رسائل الالتزام الخاصة بك

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

من المبكر جدًا التحدث عن الالتزامات التقليدية#

لا أقول إن الالتزامات التقليدية سيئة. لديهم العديد من الفوائد المعروفة:

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

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

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

التفكير الأساسي لكتابة رسائل الالتزام الجيدة#

يجب أن تقوم تغييرات الكود بشيء واحد في كل مرة#

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

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

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

رسائل الالتزام توجد قبل كتابة الكود#

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

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

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

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

1. إعادة بناء مكون النموذج الموجود ليكون أكثر عمومية وقابلة لإعادة الاستخدام
2. إنشاء نموذج تسجيل المستخدم
3. تنفيذ تكامل API لتسجيل المستخدم
4. إضافة اختبارات وحدات لميزة تسجيل المستخدم
5. تحديث الوثائق لميزة تسجيل المستخدم

قد تكون رسائل الالتزام المقابلة لهذه الخطوات كما يلي:

1. refactor: تعزيز مكون النموذج الموجود لإعادة الاستخدام
2. feat: إنشاء نموذج تسجيل المستخدم
3. feat: تنفيذ تكامل API لتسجيل المستخدم
4. test: إضافة اختبارات وحدات لتسجيل المستخدم
5. docs: تحديث الوثائق لميزة تسجيل المستخدم

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

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

الالتزامات التقليدية تصبح خيارًا طبيعيًا#

عندما نطور العقلية الصحيحة للتطوير، يصبح استخدام الالتزامات التقليدية خيارًا طبيعيًا. في هذه المرحلة، ستجد أن اختيار البادئة النوع الصحيحة (مثل feat، fix، refactor، إلخ) يصبح سهلًا لأن رسائل الالتزام الخاصة بك تعكس بالفعل خطوات المهام الخاصة بك بوضوح.

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

الخلاصة#

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

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

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