مبادئ KISS وYAGNI وDRY لأصحاب المشاريع: لماذا يرفض الفريق الجيد بعض الميزات؟

هذا الدليل لأصحاب المشاريع ورواد الأعمال الذين يستعدون لبدء تطبيق أو منصة أو نظام، وسمعوا من المطوّر عبارة «لا نحتاج هذا الآن». خلف هذه العبارة ثلاثة مبادئ هندسية قديمة: KISS وYAGNI وDRY. لن تحتاج إلى قراءة سطر برمجي واحد لتستفيد منها، فهي تحدد متى تطلق منتجك، وكم خطأً يواجه عملاؤك، وكم يكلّفك كل تعديل بعد الإطلاق.

ما مبادئ KISS وYAGNI وDRY؟

باختصار: KISS أي «أبقِها بسيطة»: اختر أبسط تصميم يؤدي مهمة اليوم. وYAGNI أي «لن تحتاجها»: لا تبنِ ميزة حتى يحتاجها مستخدم حقيقي، لا حين يتوقع أحد أنه قد يحتاجها. وDRY أي «لا تكرّر نفسك»: كل قاعدة في عملك، كالسعر أو رسوم التوصيل، تُكتب في مكان واحد فتغيّرها مرة واحدة. ومعًا تسمح للفريق أن يرفض ميزة دون أن يرفض القيمة التي تريدها.

لم تحسم ما تبنيه أولًا؟ اسأل عن خدمة المدير التقني ←

كم تكلّفك ميزة إضافية واحدة؟

كل ميزة تُضاف بعبارة «وبالمرة…» تبدو مجانية في الاجتماع. لكن مارتن فاولر، من أشهر الكتّاب في تصميم البرمجيات، يقسم كلفتها الحقيقية إلى أربعة أجزاء (martinfowler.com):

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

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

المبادئ الثلاثة في جدول واحد

المبدأ	من أين جاء	بكلمات بسيطة	ماذا يوفّر لك	متى يُساء استخدامه
KISS: أبقِها بسيطة	يُنسب عادةً إلى كيلي جونسون من Skunk Works في Lockheed، واستخدمته البحرية الأمريكية منذ 1960	أبسط تصميم يؤدي مهمة اليوم	أخطاء أقل، وإطلاق أسرع	حين تُسقط «البساطة» ما يحتاجه عميلك، كالعربية أو وسيلة الدفع التي يستخدمها
YAGNI: لن تحتاجها	البرمجة القصوى (Extreme Programming)، منهجية رشيقة من أواخر التسعينيات	ابنِ لمستخدم حقيقي لا لتخمين: لا تبنِ مرآبًا لأربع سيارات لأنك قد تملكها يومًا	كلفة البناء، ووقت الإطلاق	حين تكون الحاجة مؤكدة ولها موعد، كقاعدة ضريبية معلنة
DRY: لا تكرّر نفسك	كتاب The Pragmatic Programmer لآندي هنت ودايف توماس، 1999	كل قاعدة عمل في مكان واحد: قائمة أسعار واحدة تقرأ منها كل الفروع	كلفة التغيير، والتناقض بين الشاشات	حين يُدمج شيئان متشابهان في الشكل فقط

KISS: ماذا توفّر لك النسخة الأبسط؟

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

وفي مشروعك، تعني KISS عادةً:

• شيفرة واحدة لتطبيقَي iPhone وAndroid، إلا إن احتاج المنتج شيئًا لا يقدّمه إلا التطبيق الأصلي (كيف نختار).
• تطبيق واحد منظّم قبل تقسيمه إلى خدمات منفصلة.
• طريقة أو طريقتان لتسجيل الدخول يستخدمهما عملاؤك، كرقم الجوال، بدل خمس. فبعض الطرق تجرّ قواعد معها: تطبيق iPhone الذي يتيح الدخول بحساب Google أو Facebook عليه أن يتيح أيضًا خيارًا يحفظ الخصوصية (إرشادات Apple، البند 4.8).

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

YAGNI: «قد نحتاجها» ليست سببًا

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

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

YAGNI تعني «ليس الآن»، لا «أبدًا». كل فكرة تذهب إلى قائمة «لاحقًا» مع الإشارة التي تعيدها: عملاء يطلبونها دون أن تسألهم، أو سوق جديدة تُفتح، أو عقد يشترطها. وحين تصل الإشارة، تعرف ما يجب أن تفعله الميزة فعلًا، وهو غالبًا غير ما خمّنته أولًا.

وحدّان يُبقيان المبدأ في مكانه:

1. يشمل الميزات لا الأساسات. يوضح فاولر أن العمل الذي يُبقي البرمجيات سهلة التعديل، كالبنية النظيفة والاختبارات الآلية، لا يخالف YAGNI. نحن نختصر الميزات، ولا نختصر الأساسات.
2. لا يشمل حاجة مؤكدة لها موعد. القاعدة الضريبية التي أُعلن موعدها ليست تخمينًا. إن كنت تصدر فواتير في الإمارات، فخطّط من الآن لـالفوترة الإلكترونية ومواعيدها، ولو جاءت شاشاتها لاحقًا.

DRY: قاعدة واحدة في مكان واحد

في كتاب The Pragmatic Programmer، كتب آندي هنت ودايف توماس أن كل معلومة في النظام يجب أن يكون لها تمثيل واحد واضح ومعتمد. وبلغة صاحب المشروع، هذه المعلومات هي قواعد عملك: الأسعار، وضريبة القيمة المضافة، ورسوم التوصيل، والخصومات، والعمولات.

تخيّل رسوم توصيل مكتوبة في التطبيق، ومرة أخرى في الموقع، ومرة ثالثة في الفاتورة. يوم تغيّرها ستفوتك واحدة منها، فيرى العميل سعرًا عند الدفع وسعرًا آخر في الفاتورة. ومع DRY، تعيش الرسوم في مكان واحد تقرأ منه كل الشاشات، فتغيّرها مرة واحدة.

ويمكن المبالغة في DRY: استرداد مبلغ لعميل واسترداد مبلغ لمورّد قد يتشابهان في الشكل، لكن لكلٍّ منهما قواعد موافقة مختلفة. ادمجهما في واحد، ويكسر تعديلُ أحدهما الآخر.

ماذا يعني هذا لك: حين يعترض فريقك على ميزة، اسأله: أي مبدأ تطبّقون، وماذا يوفّر لي؟ «لم يطلبها أحد بعد، وإضافتها لاحقًا سهلة» جواب جيد. «لا نرغب» ليس جوابًا. وفي الحالتين، القرار الأخير لك.

كيف يقلّص المدير التقني النطاق دون أن يقلّص القيمة؟

تطبيق هذه المبادئ على خطتك جزء كبير من عمل المدير التقني كخدمة لمن ليس في فريقه مؤسس تقني:

1. ابدأ بالمهمة الأساسية وميزتك التنافسية، وهذه لا تُقصّ أبدًا. ويشرح تحليل المنافسين للمشاريع الناشئة كيف تجدها.
2. وزّع كل طلب على ثلاث قوائم: للإطلاق، ولاحقًا مع إشارته، وأبدًا. و«أبدًا» تأتي من مبادئ منتجك.
3. افرز ما يصعب إضافته لاحقًا. الميزة قد تنتظر، لكن القرار خلفها قد لا ينتظر: شاشات عربية من اليمين إلى اليسار، ومزوّد الدفع ووسائل الدفع المحلية مثل مدى وKNET، ونموذج البيانات، وفي حسابات من تعيش الشيفرة. احسم هذه الآن، فتصل الميزة لاحقًا دون إعادة بناء.
4. ابحث عن أبسط نسخة تحفظ القيمة: خطوة يدوية في لوحة التحكم قبل الأتمتة، وملف تصدير قبل لوحة تقارير.
5. اكتب كل قرار مع سببه وإشارته، كي لا يُعاد النقاش في «ليس الآن» كل شهر.

أمثلة توضيحية، لا مشاريع عملاء:

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

أما ما يدخل كل إصدار فموضوع مقال الفرق بين MVP وMMP وMLP، وفي فريق التطوير يحرس مالك المنتج هذه القوائم يومًا بيوم.

كل ميزة تبدو ضرورية؟ أخبرنا أين وصل منتجك اليوم، ولمن هو. نقول لك ما تحتاجه من قيادة تقنية الآن وما يمكن أن ينتظر. اسأل عن خدمة المدير التقني ←

عندك سؤال واحد فقط؟ اكتبه في النموذج نفسه. تريد أن تعرفنا أولًا؟ اطلب ملفنا التعريفي. نردّ بالبريد الإلكتروني أولًا ونرتّب مكالمة فقط إذا رغبت.

اختبار طلب الميزة: ثمانية أسئلة لأي فريق

استخدمه معنا، أو مع شركة أخرى، أو مع مطوّريك، قبل أن يدخل أي طلب في الخطة.

#	السؤال	المبدأ	ماذا يعني الجواب
1	أي مستخدم حقيقي طلبها، ولأي مهمة؟	YAGNI	«ربما يحتاجها أحد» تعني: أجّلها
2	هل ينجز المستخدم المهمة الأساسية دونها عند الإطلاق؟	YAGNI	إن كان نعم، فلتنتظر إشارتها
3	هل توجد نسخة أبسط: خطوة يدوية، أو رابط، أو ملف تصدير؟	KISS	ابدأ بها
4	هل يصعب إضافتها لاحقًا: نموذج البيانات، أو الدفع، أو العربية، أو مكان البيانات؟	حدود YAGNI	احسم القرار الآن ولو انتظرت الميزة
5	هل الحاجة مؤكدة ولها موعد: قانون، أو عقد موقّع، أو قاعدة في متجر التطبيقات؟	حدود YAGNI	خطّط لها، فهي ليست تخمينًا
6	هل تكرّر قاعدة موجودة في مكان آخر: سعر، أو رسوم، أو نسبة ضريبة؟	DRY	تقرأ من ذلك المكان الواحد
7	ماذا تضيف إلى كل إصدار: شاشات تُختبر، وصلاحيات، وبيانات تُحفظ؟	KISS	وازن هذه الكلفة، لا كلفة البناء وحدها
8	ما الإشارة التي تعيدها من قائمة «لاحقًا»؟	YAGNI	اكتبها بجانب الطلب

لم يطلبها مستخدم حقيقي، وإضافتها لاحقًا سهلة؟ مكانها قائمة «لاحقًا» مع إشارتها. هذا هو الاختبار كله.

متى تكون البساطة جوابًا خاطئًا؟

هذه المبادئ تقصّ الميزات لا القيمة، ولا تمسّ ثلاثة أشياء:

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

واسأل أيضًا: بسيطة لمن؟ إن كانت إعادة الطلب بلمسة واحدة هي ما يعيد الناس إليك، فابنِها ولو كانت أصعب في البناء.

كيف نعمل بهذه المبادئ

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

Qargo منصة لتأجير السيارات وطلب المشاوير في قطر، قُدنا توجّهها التقني وبنيتها. تحدّث مع الفريق الذي بناه: احجز اجتماعاً.

تحدّث معنا قبل أن تحسم نطاق مشروعك

Flojics Technology شركة برمجيات عملت منذ 2014 مع أكثر من 100 عميل، منهم شركات في الإمارات والسعودية وقطر والكويت، ومقرها الرئيسي مجمع دبي الرقمي في واحة دبي للسيليكون. وفريقنا الأساسي يتحدث العربية لغةً أمًّا ويعمل بالإنجليزية.

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