دورة حياة التطوير لتقديم الطلب؟

Question

لدي فكرة أريد تحويلها إلى تطبيق (لدي خلفية برمجة C/C++ وC# وJava لذا سأقوم بالتطوير في QT Creator من أجل التجميع المتبادل).والآن أنا أسألكم يا كبار المطورين، ماذا علي أن أفعل بعد ذلك؟أعلم أن كل البرامج الجيدة تأتي من فكرة.إذن ماذا يجب أن أفعل؟النموذج الأولي لواجهة المستخدم؟ثم تطوير الكود؟هل هناك مثل دائرة تطوير التطبيق؟
لا أقصد أن يكون هذا السؤال موضوعيًا أو جدليًا

Answer 1

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

• أولاً، تعامل جيدًا مع متطلباتك.إذا لم يكن المستخدمون متأكدين مما يريدون بالضبط، فإن أسلوب @Michael Herold في البدء بنموذج أولي لواجهة المستخدم يعد بالتأكيد أحد الاقتراحات الجيدة.قد ترغب أيضًا في اتباع نوع من النهج التكراري، مثل رشيقة / سكروم.
• بعد ذلك، حدد نوعًا ما من البنية عالية المستوى التي يجب أن تكون مرنة بدرجة كافية لتحقيق هدفك.هل سيكون تطبيقك خادم عميل؟هل سيحتاج إلى قاعدة بيانات؟مواضيع متعددة؟عمليات متعددة؟إذا كان أي منهما "نعم"، فكيف سيتم التواصل بين هذه الخيوط/العمليات.قم برسم مخطط بياني بعد الإجابة على الأسئلة أعلاه.
• إذا كان مشروعك متوسط ​​الحجم أو أكبر، فقد ترغب أيضًا في رسم بعض الرسوم البيانية للفئات أو من نوع UML.فكر في نوع الفصول الدراسية التي ستحتاجها وعلاقاتها.
• إذا كنت ترغب في تجربة التطوير القائم على الاختبار قد يكون الآن هو الوقت المناسب لتحويل متطلباتك إلى اختبارات الوحدة.
• بمجرد أن تكون لديك فكرة جيدة عما تحاول حله، وكيف ستتعامل مع حله، يمكنك أخيرًا البدء في صياغة الحل.

بعض الأساليب متكررة، مثل التنمية المتزايدة أو رشيقة / سكروم.في Agile/Scrum، ستكون تكراراتك سريعة جدًا، حيث تمر كل بضعة أسابيع بدورة كاملة.في التطوير التزايدي، تكون الدورة عادةً أطول:أشهر أو حتى سنوات.في كل من Scrum وفي Incremental Development، الشيء الرئيسي الذي يجب أخذه في الاعتبار هو أنه في نهاية كل تكرار، تريد الحصول على جزء من البرنامج قابل للاستخدام (حتى لو لم يفعل الكثير).وهذا يساعد في الحفاظ على اهتمام العملاء الحقيقيين أو المحتملين، وحتى المطورين.

مهما كان النهج الذي تتبعه، كلما تمكنت من إشراك المستخدمين (أو المستخدمين المحتملين) في وقت مبكر وفي كثير من الأحيان، إما من خلال النظر في النماذج الأولية لواجهة المستخدم، أو من خلال اختبار قابلية الاستخدام, ، الافضل.

Answer 2

أود أن أقول أن ذلك يعتمد على الجزء الرئيسي من التطبيق. هل سيأتي غالبية العمل من تصميم واجهة المستخدم (أي أنه من أين يأتي "عامل واو"؟) أم أنه سيكون في الغالب معالجة البيانات أو بعض "الرفع الثقيل" الآخر (أي هذه هي نتائجي في أ واجهة مستخدم بسيطة)؟

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

الشيء الجميل هو أنه إذا تم القيام بهما بشكل صحيح ، فيجب فصل هذين الأمرين بالكامل (أو تمامًا تقريبًا) عن بعضهما البعض.

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

Answer 3

تصدع معها. فقط تتعثر.

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

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

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