لماذا تعتبر كتابة وثائق تصميم البرمجيات أمرا مهما

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

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

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

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

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

لماذا وثائق تصميم البرمجيات مهمة

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

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

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

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

ما الذي يجب أن تحدده مواصفات تصميم البرنامج فعليًا؟

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

واجهة المستخدم

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

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

1. هل الضوابط مرئية و / أو ممكّنة دائمًا؟ تحت أي ظروف تتغير دولهم؟
2. تبدو وكأنها صورة نقطية - هل هي زر؟
3. ما التحولات التي تحدث بين هذه الحالات والآراء؟ وكيف يجب أن تكون متحركة؟

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

أبعاد الشاشة مهمة أيضًا. هناك (حتى كتابة هذا التقرير) ثلاثة أحجام لشاشات iPhone. من المحتمل أن تكون الإطارات السلكية المنفصلة للشاشات مقاس 3.5 بوصة و 4 بوصة مفرطة ، ولكن قد تضطر إلى صنعها ؛ في معظم الحالات ، يمكنك ببساطة تغيير النسب.

إذا قام عميلك بتزويدك بالرسومات ، فتأكد من أن حجمها صحيح مع نسب العرض إلى الارتفاع المناسبة ؛ سيؤدي تحويل أي صورة نقطية تحتوي على نص أو كائنات (مثل الدوائر) إلى حدوث تشوهات. إذا لم تتطابق ، أخبر العميل أن يعيد إنشائها بأحجام متطابقة. لا تفترض أنه يمكنك تمديد شاشة دفقة مقاس 3.5 بوصات إلى رشاش بحجم 4 بوصات وتدحرج معها فقط.

وظائف

الأسئلة الرئيسية التي يجب طرحها في وثيقة تصميم التطبيق:

• ماذا يفعل التطبيق ، وما مدى سرعة عمله؟
• ما هي شروط الفشل المحتملة وكيف يتم التعامل معها؟
• ما هي العمليات التي تتم لمرة واحدة عند التنفيذ الأول (أي بعد التثبيت)؟
• إذا قام المستخدم بإنشاء إدخالات من أي نوع (مثل الإشارات المرجعية) ، فما هي القيود؟

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

معالم

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

مثال على مواصفات تصميم البرامج

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

بيان الأهداف

قم بتضمين فقرة قصيرة تصف المشروع والجمهور المستهدف.

وصف وظيفي

ماذا يفعل التطبيق؟ ما هي حالات التطبيق (أوصاف عالية المستوى لسيناريوهات المستخدم الأساسية) التي سيواجهها المستخدم؟

على سبيل المثال ، قد يبدو الوصف الوظيفي الخاص بك كما يلي:

• الجولة الأولى
• إنشاء _____ جديد (لعبة ، بحث ، إلخ.)
• عمليات
• الخلفية والسلوك الأمامي

واجهة المستخدم

قم بتضمين إطارات سلكية لكل صفحة ، مع وصف تفصيلي لما يلي:

• كل عنصر تحكم ، بما في ذلك الحالات (ممكّن / معطل / مميز) والعمليات.
• دعم التوجهات والانتقالات بينهم.
• وظيفة ممثلة.
• معالجة الأخطاء.
• الأبعاد والقيود.

فيما يلي الإطارات الشبكية المتعلقة بأحدث تطبيقات iOS الخاصة بي ، NotifEye:

إذا كنت مهتمًا ، فقد صنعت هذه النماذج باستخدام أداة التخطيط الشبكي من Balsamiq.

على سبيل المثال ، قد يبدو وصف واجهة المستخدم كما يلي:

• شريط التنقل
  • التحكم في التنقل الأيسر: العودة إلى الصفحة الرئيسية
  • شريط العنوان: الشاشة الحالية أو اسم العملية
  • زر جديد: أنشئ شيئًا جديدًا
• عرض جدول
  • القسم 0: عنوان القسم
  • قسم 0 صفوف:
    • التحكم في الصف 0 (على سبيل المثال ، صورة)
    • سطر نص 0
    • سطر النص 2

معالم

كما هو موضح أعلاه ، المواعيد النهائية للإنجاز والمخرجات المتوقعة.

على سبيل المثال ، قد يبدو قسم المعالم في قالب مستند التصميم الخاص بك كما يلي:

1. يظهر تطبيق الواجهة شاشة وبها انتقالات مؤقتة وأمثلة على الصور / النصوص
2. بروتوكول الاتصال: يتصل التطبيق بالشبكة / الخادم
3. المعلم الوظيفي 1: ...
4. تطبيق Alpha (بوظائف كاملة)
5. استقرار
6. إطلاق سراح

التأكد من أن وثائق البرامج تظل ذات صلة

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

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

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

1. ما الذي كان المطور يعمل عليه للتو؟
2. ما الذي يعمل عليه المطور حاليا؟
3. ما الذي سيعمل عليه المطور بعد ذلك؟