ما رأيك في تطوير سطر الأوامر أولاً؟
https://stackoverflow.com/questions/18984
-
09-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
ما هي آرائك حول تطوير سطر الأوامر أولاً، ثم إضافة واجهة المستخدم الرسومية بعد ذلك بمجرد استدعاء أساليب سطر الأوامر؟
على سبيل المثال.
W:\ todo AddTask "لقاء مع جون، بخصوص:تسجيل الدخول مراجعة النظراء" "مكتب جون" "22-08-2008" "14:00"
الأحمال todo.exe ويستدعي وظيفة تسمى AddTask يقوم ببعض التحقق من الصحة ويلقي الاجتماع في قاعدة بيانات.
في النهاية تضيف شاشة لهذا:
============================================================ Event: [meeting with John, re: login peer review] Location: [John's office] Date: [Fri. Aug. 22, 2008] Time: [ 2:00 PM] [Clear] [Submit] ============================================================
عند النقر فوق إرسال، فإنه يستدعي نفس وظيفة AddTask.
فهل يعتبر هذا:
- طريقة جيدة للتشفير
- فقط للمبتدئين
- بشع!.
إضافة:
ألاحظ اتجاهًا هنا لـ "مكتبة مشتركة تدعوها كل من GUI و CLI Executables." هل هناك سبب مقنع لأنه يجب فصلهم ، بخلاف حجم الثنائيات نفسها؟
لماذا لا نستدعي نفس الملف القابل للتنفيذ بطرق مختلفة:
"todo /G"عندما تريد الواجهة الرسومية الكاملة"todo /I"للمطالبة التفاعلية داخلtodo.exe(البرمجة النصية، الخ)- السهول القديمة
"todo <function>"عندما تريد فقط أن تفعل شيئًا واحدًا وتنتهي منه.
الإضافة 2:
لقد ذكر أنه "بالطريقة التي وصفت بها الأشياء، [سوف] تحتاج إلى إنشاء ملف قابل للتنفيذ في كل مرة تحتاج فيها واجهة المستخدم الرسومية إلى القيام بشيء ما."
مرة أخرى، لم تكن هذه نيتي.عندما ذكرت أن مثال واجهة المستخدم الرسومية يسمى "نفس الشيء AddTask وظيفة،" لم أقصد أن واجهة المستخدم الرسومية تستدعي برنامج سطر الأوامر في كل مرة.أوافق على أن ذلك سيكون سيئًا تمامًا.كنت أنوي (انظر الملحق الأول) أن يتم الاحتفاظ بكل هذا في ملف واحد قابل للتنفيذ، نظرًا لأنه كان مثالًا صغيرًا، لكنني لا أعتقد أن صياغتي تمنع بالضرورة وجود مكتبة مشتركة.
كما أود أن أشكركم جميعًا على مساهماتكم.هذا هو الشيء الذي يستمر في الظهور في ذهني وأنا أقدر حكمة تجربتك.
المحلول
سأقوم بإنشاء مكتبة باستخدام تطبيق سطر الأوامر الذي يرتبط بها.بعد ذلك، يمكنك إنشاء واجهة المستخدم الرسومية التي ترتبط بنفس المكتبة.يؤدي استدعاء سطر الأوامر من واجهة المستخدم الرسومية إلى ظهور عمليات خارجية لكل أمر ويكون أكثر إزعاجًا لنظام التشغيل.
أيضًا، باستخدام المكتبة، يمكنك بسهولة إجراء اختبارات الوحدة للوظيفة.
ولكن حتى طالما أن الكود الوظيفي الخاص بك منفصل عن مترجم سطر الأوامر الخاص بك، فيمكنك فقط إعادة استخدام المصدر لواجهة المستخدم الرسومية دون الحاجة إلى النوعين في وقت واحد لتنفيذ العملية.
نصائح أخرى
ضع الوظيفة المشتركة في مكتبة، ثم اكتب سطر أوامر وواجهة أمامية لواجهة المستخدم الرسومية لها.بهذه الطريقة لا يرتبط انتقال الطبقة بسطر الأوامر.
(تضيف هذه الطريقة أيضًا مصدر قلق أمني آخر:ألا يجب على واجهة المستخدم الرسومية أولاً التأكد من أن ملف todo.exe هو الصحيح الذي يتم استدعاؤه؟)
كتب جويل مقالًا يقارن بين هذا التطوير ("نمط يونكس") وأسلوب واجهة المستخدم الرسومية أولاً ("نمط Windows") قبل بضع سنوات.لقد دعاه الثنائية الثقافية.
أعتقد أنه في نظام التشغيل Windows، سيصبح من الطبيعي (إذا لم يكن الأمر كذلك بالفعل) تغليف المنطق الخاص بك في تجميعات .NET، والتي يمكنك بعد ذلك الوصول إليها من خلال واجهة المستخدم الرسومية وموفر PowerShell.وبهذه الطريقة يمكنك الحصول على أفضل ما في العالمين.
أسلوبي في برمجة وظائف الواجهة الخلفية أولاً دون الحاجة إلى واجهة مستخدم واضحة (خاصة عندما لا تكون واجهة المستخدم هي وظيفتي بعد، على سبيل المثال، أنا أقوم بتصميم تطبيق ويب لا يزال في مرحلة التصميم) هو كتابة اختبارات الوحدة.
وبهذه الطريقة، لا أحتاج حتى إلى كتابة تطبيق وحدة تحكم للسخرية من مخرجات كود الواجهة الخلفية الخاص بي - كل ذلك في الاختبارات، وعلى عكس تطبيق وحدة التحكم الخاص بك، لا يتعين علي التخلص من كود الاختبارات لأنها لا تزال موجودة تكون مفيدة في وقت لاحق.
أعتقد أن ذلك يعتمد على نوع التطبيق الذي تقوم بتطويره.يضعك التصميم لسطر الأوامر على المسار السريع لما يشير إليه آلان كوبر بـ "نموذج التنفيذ" في السجناء يديرون اللجوء.والنتيجة هي واجهة مستخدم غير بديهية وصعبة الاستخدام.
تدعو 37signals أيضًا إلى تصميم واجهة المستخدم الخاصة بك أولاً تصبح حقيقية.تذكر، لجميع المقاصد والأغراض، في غالبية التطبيقات، واجهة المستخدم يكون البرنامج.رمز النهاية الخلفية موجود فقط لدعمه.
ربما يكون من الأفضل البدء بسطر الأوامر أولاً للتأكد من صحة الوظيفة.إذا كان المستخدمون الرئيسيون لديك لا يستطيعون (أو لا يريدون) استخدام سطر الأوامر، فيمكنك إضافة واجهة المستخدم الرسومية أعلى عملك.
سيؤدي هذا إلى جعل تطبيقك أكثر ملاءمة للبرمجة النصية بالإضافة إلى الحد من مقدار المبلغ المقدم تزلج بالدراجات حتى تتمكن من الوصول إلى الحل الفعلي بشكل أسرع.
إذا كنت تخطط للاحتفاظ بإصدار سطر الأوامر من تطبيقك، فلا أرى مشكلة في القيام بذلك بهذه الطريقة - فهذا ليس وقتًا ضائعًا.ستظل في نهاية المطاف تقوم بترميز الوظيفة الرئيسية لتطبيقك لسطر الأوامر، وبالتالي سيكون لديك جزء كبير من العمل المنجز.
لا أرى أن العمل بهذه الطريقة يشكل عائقًا أمام واجهة مستخدم رائعة - لا يزال لديك الوقت لإضافة واحدة وجعلها قابلة للاستخدام وما إلى ذلك.
أعتقد أن طريقة العمل هذه لن تنجح إلا إذا كنت تنوي أن يشتمل تطبيقك النهائي على متغيرات سطر الأوامر وواجهة المستخدم الرسومية.من السهل الاستهزاء بواجهة المستخدم وبناء وظائفك فيها ثم تجميل واجهة المستخدم لاحقًا.
أتفق مع ستو:يجب أن تكون وظيفتك الأساسية موجودة في مكتبة يتم استدعاؤها من سطر الأوامر ورمز واجهة المستخدم الرسومية.يعد استدعاء الملف القابل للتنفيذ من واجهة المستخدم أمرًا غير ضروري في وقت التشغيل.
@jcarrascal
لا أفهم لماذا يجعل هذا واجهة المستخدم الرسومية "سيئة؟"
فكرتي هي أنه سيجبرك على التفكير في ما يحتاج منطق "العمل" إلى تحقيقه بالفعل، دون القلق كثيرًا بشأن جمال الأشياء.بمجرد أن تعرف ما ينبغي/يمكن أن تفعله، يمكنك بناء واجهتك حول ذلك بأي طريقة منطقية.
ملاحظة جانبية:لا أريد أن أبدأ بموضوع منفصل، ولكن ما هي الطريقة المفضلة لتناول الإجابات/التعليقات على أسئلتك؟لقد فكرت في هذا الأمر وتحرير السؤال نفسه.
لقد فعلت هذا بالضبط باستخدام إحدى الأدوات التي كتبتها، وكانت النتيجة رائعة.والنتيجة النهائية هي أداة قابلة للبرمجة يمكن استخدامها أيضًا عبر واجهة المستخدم الرسومية.
أنا أتفق مع الرأي القائل بضرورة التأكد من أن واجهة المستخدم الرسومية سهلة الاستخدام وبديهية، لذلك قد يكون من الحكمة تطوير كليهما في نفس الوقت...ميزة سطر أوامر صغيرة متبوعة بواجهة المستخدم الرسومية لضمان قيامك بالأشياء بشكل حدسي.
إذا كنت صادقًا في تنفيذ كليهما بالتساوي، فإن النتيجة هي تطبيق يمكن استخدامه بطريقة تلقائية، وهو ما أعتقد أنه قوي جدًا للمستخدمين المتميزين.
عادةً ما أبدأ بمكتبة صفية وواجهة مستخدم رسومية منفصلة سيئة للغاية وأساسية.نظرًا لأن سطر الأوامر يتضمن تحليل سطر الأوامر، أشعر وكأنني أضيف الكثير من النفقات غير الضرورية.
على سبيل المكافأة، يوفر هذا أسلوبًا يشبه MVC، حيث أن جميع التعليمات البرمجية "الحقيقية" موجودة في مكتبة الفصل.بالطبع، في مرحلة لاحقة، تعد إعادة هيكلة المكتبة مع واجهة المستخدم الرسومية الحقيقية في ملف EXE واحدًا خيارًا أيضًا.
إذا قمت بالتطوير بشكل صحيح، فمن السهل نسبيًا التبديل إلى واجهة المستخدم الرسومية لاحقًا في المشروع.المشكلة هي أنه من الصعب نوعًا ما القيام بذلك بشكل صحيح.
يعتمد نوع ما على هدفك من البرنامج، ولكن نعم أفعل ذلك من وقت لآخر - فهو أسرع في البرمجة، وأسهل في تصحيح الأخطاء، وأسهل في كتابة حالات اختبار سريعة وقذرة لها.وطالما قمت ببناء الكود الخاص بي بشكل صحيح، يمكنني العودة والتعامل مع واجهة المستخدم الرسومية لاحقًا دون الكثير من العمل.
إلى أولئك الذين يقترحون أن هذه التقنية ستؤدي إلى واجهات مستخدم رهيبة وغير قابلة للاستخدام:أنت على حق.تعد كتابة أداة مساعدة لسطر الأوامر طريقة رهيبة لتصميم واجهة المستخدم الرسومية.لاحظ أن الجميع هناك يفكرون في كتابة واجهة مستخدم ليس كذلك CLUI - لا تضع نموذجًا أوليًا له على أنه CLUI.
لكن، إذا كنت تكتب رمزًا جديدًا لا يعتمد في حد ذاته على واجهة المستخدم, ، ثم اذهب لذلك.
قد يكون الأسلوب الأفضل هو تطوير المنطق كمكتبة ذات واجهة برمجة تطبيقات محددة جيدًا، وفي مرحلة التطوير، لا توجد واجهة (أو واجهة مشفرة بشكل ثابت) ثم يمكنك كتابة واجهة سطر الأوامر (CLI) أو واجهة المستخدم الرسومية (GUI) لاحقًا
لن أفعل هذا لعدة أسباب.
تصميم:
واجهة المستخدم الرسومية وواجهة سطر الأوامر هما واجهتان مختلفتان تستخدمان للوصول إلى التنفيذ الأساسي.يتم استخدامها عمومًا لأغراض مختلفة (واجهة المستخدم الرسومية مخصصة للمستخدم المباشر، وعادةً ما يتم الوصول إلى واجهة سطر الأوامر (CLI) عن طريق البرمجة النصية) ويمكن أن يكون لها في كثير من الأحيان متطلبات مختلفة.إن اقتران الاثنين معًا ليس خيارًا حكيمًا ولا بد أن يسبب لك مشاكل في المستقبل.
أداء:
بالطريقة التي وصفت بها الأشياء، تحتاج إلى إنشاء ملف قابل للتنفيذ في كل مرة تحتاج فيها واجهة المستخدم الرسومية إلى القيام بشيء ما.هذا مجرد قبيح.
الطريقة الصحيحة للقيام بذلك هي وضع التنفيذ في مكتبة يتم استدعاؤها بواسطة كل من واجهة سطر الأوامر (CLI) وواجهة المستخدم الرسومية (GUI).
كان لدى John Gruber منشور جيد حول مفهوم إضافة واجهة المستخدم الرسومية إلى برنامج غير مصمم لأحد: رونكو رذاذ على سهولة الاستخدام
ملخص:لا يعمل.إذا لم يتم تصميم سهولة الاستخدام في تطبيق من البداية، فإن إضافتها لاحقًا ستكون عملاً أكثر مما يرغب أي شخص في القيام به.
@موديت
سيتحقق تطبيق سطر الأوامر من المعلمات مقدمًا ولن تفعل ذلك واجهة المستخدم الرسومية - لكنهم سيظلون يتحققون من نفس params وإدخالها في بعض وظائف العامل العامة.
لا يزال نفس الهدف.لا أرى أن إصدار سطر الأوامر يؤثر على جودة واجهة المستخدم الرسومية.
قم بعمل برنامج تعرضه كخدمة ويب.ثم قم بتنفيذ واجهة المستخدم الرسومية وسطر الأوامر للاتصال بنفس خدمة الويب.يتيح لك هذا الأسلوب أيضًا إنشاء واجهة مستخدم رسومية للويب، وكذلك توفير وظائف SaaS لشركاء الشبكة الخارجية و/أو تأمين منطق الأعمال بشكل أفضل.
يتيح هذا أيضًا لبرنامجك المشاركة بسهولة أكبر في بيئة SOA.
بالنسبة لخدمة الويب، لا تبالغ.قم بعمل yaml أو xml-rpc.أبقيها بسيطة.
بالإضافة إلى ما ستو وقال إن وجود مكتبة مشتركة سيسمح لك باستخدامها من تطبيقات الويب أيضًا.أو حتى من البرنامج المساعد IDE.
هناك عدة أسباب تجعل القيام بذلك بهذه الطريقة ليس فكرة جيدة.لقد تم ذكر الكثير منها، لذلك سألتزم بنقطة واحدة محددة.
عادةً ما تكون أدوات سطر الأوامر غير تفاعلية على الإطلاق، بينما تكون واجهات المستخدم الرسومية كذلك.وهذا فرق جوهري.وهذا على سبيل المثال أمر مؤلم بالنسبة للمهام طويلة الأمد.
ستقوم أداة سطر الأوامر الخاصة بك في أفضل الأحوال بطباعة نوع من معلومات التقدم - أسطر جديدة، وشريط تقدم نصي، ومجموعة من المخرجات، ...يمكن إخراج أي نوع من الأخطاء فقط إلى وحدة التحكم.
الآن تريد إضافة واجهة المستخدم الرسومية فوق ذلك، ماذا تفعل؟تحليل مخرجات أداة سطر الأوامر طويلة الأمد؟هل تبحث عن تحذير وخطأ في هذا الإخراج لإظهار مربع حوار؟
في أفضل الأحوال، تعرض معظم واجهات المستخدم المبنية بهذه الطريقة شريطًا مشغولًا نابضًا طوال فترة تشغيل الأمر، ثم تظهر لك مربع حوار النجاح أو الفشل عند خروج الأمر.للأسف، هذه هي الطريقة التي يتم بها تجميع الكثير من برامج UNIX GUI معًا، مما يجعلها تجربة مستخدم رهيبة.
معظم الردود هنا على حق في قولها إنه ربما ينبغي عليك تجريد الوظيفة الفعلية لبرنامجك في مكتبة، ثم كتابة واجهة سطر الأوامر وواجهة المستخدم الرسومية في نفس الوقت لذلك.يجب أن يكون كل منطق عملك موجودًا في مكتبتك، ويجب أن تقوم واجهة المستخدم (نعم، سطر الأوامر هو واجهة مستخدم) فقط بكل ما هو ضروري للتفاعل بين منطق عملك وواجهة المستخدم الخاصة بك.
يعتبر سطر الأوامر واجهة مستخدم سيئة للغاية بحيث لا يمكنك التأكد من تطوير مكتبتك بشكل جيد بما يكفي لاستخدام واجهة المستخدم الرسومية لاحقًا.يجب أن تبدأ بكليهما منذ البداية، أو تبدأ ببرمجة واجهة المستخدم الرسومية.من السهل إضافة واجهة سطر أوامر إلى مكتبة تم تطويرها لواجهة المستخدم الرسومية، لكن الأمر أصعب كثيرًا على العكس من ذلك، وذلك على وجه التحديد بسبب جميع الميزات التفاعلية التي ستحتاجها واجهة المستخدم الرسومية (التقارير، التقدم، مربعات حوار الأخطاء، i18n، ... )
تولد أدوات سطر الأوامر أحداثًا أقل من تطبيقات واجهة المستخدم الرسومية وعادةً ما تتحقق من جميع المعلمات قبل البدء.سيؤدي هذا إلى تقييد واجهة المستخدم الرسومية الخاصة بك لأنه بالنسبة لواجهة المستخدم الرسومية، قد يكون من المنطقي أن تطلب المعلمات أثناء عمل برنامجك أو بعد ذلك.
إذا كنت لا تهتم بواجهة المستخدم الرسومية فلا تقلق بشأن ذلك.إذا كانت النتيجة النهائية هي واجهة المستخدم الرسومية، فقم بإنشاء واجهة المستخدم الرسومية أولاً، ثم قم بإصدار سطر الأوامر.أو يمكنك العمل على كليهما في نفس الوقت.
--تحرير هائل--
بعد قضاء بعض الوقت في مشروعي الحالي، أشعر كما لو أنني قد انتهيت من إجابتي السابقة.أعتقد أنه من الأفضل تنفيذ سطر الأوامر أولاً ثم لف واجهة المستخدم الرسومية عليه.إذا كنت بحاجة إلى ذلك، فأعتقد أنه يمكنك إنشاء واجهة مستخدم رسومية رائعة بعد ذلك.من خلال تنفيذ سطر الأوامر أولاً، يمكنك الحصول على جميع الوسائط أولاً حتى لا تكون هناك مفاجآت (حتى تتغير المتطلبات) عند قيامك بتنفيذ واجهة المستخدم/تجربة المستخدم.
هذا هو بالضبط أحد أهم ما أدركته فيما يتعلق بالبرمجة وأتمنى أن يتبع المزيد من الأشخاص هذا النهج.
توضيح بسيط واحد فقط:لا ينبغي أن تكون واجهة المستخدم الرسومية عبارة عن غلاف حول سطر الأوامر.بدلاً من ذلك، ينبغي للمرء أن يكون قادرًا على قيادة جوهر البرنامج إما من واجهة المستخدم الرسومية أو من سطر الأوامر.على الأقل في البداية والعمليات الأساسية فقط.
متى تكون هذه فكرة عظيمة؟
عندما تريد التأكد من أن تنفيذ المجال الخاص بك مستقل عن إطار عمل واجهة المستخدم الرسومية.تريد الترميز حول الإطار لا داخل إطار العمل
متى تكون هذه فكرة سيئة؟
عندما تكون متأكدًا من أن إطارك لن يموت أبدًا
