كيفية التعامل مع شيء معقد؟

Question

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

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

Answer 1

سأحكي قصة حالة حدث لي فيها هذا.

كنت أرغب في تنفيذ خوارزمية قرار جديدة لنوع الإطار لـ x264 والتي تستخدم البرمجة الديناميكية الأمامية (خوارزمية Viterbi).لكن الأمر سيكون معقدًا وفوضويًا وقبيحًا وما إلى ذلك.وأنا حقا لا أريد أن أفعل ذلك.لقد حاولت رهن المشروع في Google Summer of Code، ولكن بسبب سوء الحظ الشديد، قام الطالب الوحيد الذي حصلنا عليه بكفالة مشروعه ببساطة...كان الطالب الذي اختار هذا المشروع.

لذلك بعد شهرين من الشكوى والتهرب منها، تمكنت أخيرًا من العمل على الخوارزمية.وإليك كيف فعلت ذلك.

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

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

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

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

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

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

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

Answer 2

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

افعل ذلك!!!

على محمل الجد، بمجرد أن تبدأ، يصبح الانتهاء منها أسهل بكثير.أجد دائمًا أنني أؤجل الأمور حتى أبدأها، ثم فجأة أجد أنه، الآن بعد أن بدأت، لم يكن الأمر سيئًا كما كنت أتخيل، وانظر، لقد انتهى الأمر تقريبًا بالفعل!

Answer 3

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

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

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

Answer 4

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

Answer 5

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

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

Answer 6

أعتقد أن هناك مشكلتين هنا.

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

ثم هناك العملية الفعلية لحل المشكلات الصعبة.هناك كتاب عظيم اسمه "Conceptual Blockbusting" الذي يناقش الطرق المختلفة للتعامل مع المشاكل.لقد تعلمت الكثير عن كيفية تعاملي مع حل المشكلات ونقاطي العمياء باستخدام هذا الكتاب.ينصح به بشده.

Answer 7

أحاول إنشاء استعارة لما يحاول النظام القيام به.أشعر دائمًا براحة أكبر عندما أتمكن من وصف السلوك من خلال الاستعارة.

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

هث.

هتافات،

روب

Answer 8

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

أنا من المعجبين ب"فرق تسد"-نوع النهج نفسي.

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

ثم خذ كل واحدة من هذه المهام، وقم بتقسيمها إلى الوظائف / المكالمات الأساسية المطلوبة.

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

Answer 9

عادةً ما أعالج هذا النوع من المشاكل في المنزل باستخدام قلم وورقة.أتخيل الخوارزمية و/أو التدفق المنطقي ثم أضع (على الورق!) الطبقات وأعقاب الطرق وعندما أقف أمام الكمبيوتر يمكنني القيام بذلك بشكل أسهل بكثير ...ربما هذا أنا فقط..