مقدمة المترجم: بعد قراءة هذا المقال ، قد تتفاجأ أو حتى تغضب. نعم ، لقد فوجئنا أيضًا: يزعم أن المؤلف لم يسمع أبدًا عن التسلسل الهرمي في الفريق ، وعن تحديد المهام ذات الحالة "افعلها بسرعة ودون تفكير". نعم ، هذا كل شيء ، إنه نص غريب بعض الشيء. في الواقع ، يقدم المؤلف المبرمج لتولي دور مهندس النظم - لماذا إذن تحتاج إلى مهندس معماري؟ لكن كل هذه الاعتراضات يجب ألا تخفي عنك الشيء الرئيسي - لماذا أخذنا هذا النص وترجمناه. انه ليس عن الأدوار. هذا النص هو عن النهج المهني والوعي. الحقيقة هي أنه بينما "تفعل ما تقوله" فقط دون التفكير في معنى أفعالك ، لن تصبح مبرمجًا رائعًا أبدًا.قل لا للرمز الإضافي. كل ما عليك القيام به هو وضع الحروف الثلاثة وقول الكلمة. دعونا نحاول القيام بذلك معًا: "Nooo!"
لكن مهلا. لماذا نفعل هذا؟ بعد كل شيء ، فإن المهمة الرئيسية للمبرمج هو كتابة التعليمات البرمجية. لكن هل من الضروري كتابة أي كود مطلوب منك؟ لا! "إن فهم متى يجب ألا تكتب الكود ربما يكون أهم مهارة للمبرمج".
فن القراءة المقروءة .
نذكرك: لجميع قراء "Habr" - خصم بقيمة 10،000 روبل عند التسجيل في أي دورة تدريبية في Skillbox باستخدام الرمز الترويجي "Habr".
توصي Skillbox بما يلي: دورة عملية "Mobile Developer PRO" .
البرمجة هي فن حل المشكلات. وأنت أسياد هذا الفن.
في بعض الأحيان ، في محاولة للبدء في أقرب وقت ممكن ، لا نفكر في أي شيء آخر غير إكمال المهمة. وهذا يمكن أن يسبب مشاكل أكثر خطورة.
ماذا غض الطرف عن المبرمجين؟
يجب فهم جميع التعليمات البرمجية التي تكتبها بواسطة مطورين آخرين ، وكذلك اختبارها وتصحيحها.
ولكن هناك مشكلة: كل ما تكتبه ، سيعقد البرنامج الخاص بك وربما يضيف أخطاء في المستقبل.
وفقا لريتش سكنت ،
الكود هو عدونا . إليكم ما يكتب:
"الرمز سيء لأنه يبدأ في التعفن ويتطلب صيانة مستمرة. تتطلب إضافة ميزات جديدة غالبًا تعديل الرمز القديم. كلما كان حجمها أكبر ، كلما زاد احتمال حدوث خطأ وكلما زاد الوقت المستغرق في التجميع. يحتاج مطور آخر إلى مزيد من الوقت لمعرفة ذلك. وإذا كنت بحاجة إلى إعادة البناء ، فهناك بالتأكيد شظايا تستحق التغيير. غالباً ما تعني الشفرة المجمعة تقليل مرونة ووظائف المشروع. الحل البسيط والأنيق أسرع من الشفرة المعقدة. "
كيفية معرفة متى يجب أن لا تكتب الكود؟
المشكلة هي أن المبرمجين في كثير من الأحيان يبالغون في عدد الوظائف التي يحتاجها التطبيق. نتيجة لذلك ، تظل العديد من أقسام الكود غير مكتملة أو لا يستخدمها أحد ، لكنها تعقد التطبيق.
يجب أن تكون مدركًا بوضوح لما يحتاجه مشروعك وما لا يحتاجه.مثال على ذلك هو تطبيق يحل مهمة واحدة فقط - إنه يدير البريد الإلكتروني. تم تقديم وظيفتين لهذا - إرسال واستقبال الرسائل. يجب ألا تتوقع أن يصبح مدير البريد مدير مهام في وقت واحد.
عليك أن تقول بحزم لا للاقتراحات لإضافة وظائف لا تتعلق بالمهمة الرئيسية للتطبيق. هذه هي اللحظة بالضبط عندما يصبح من الواضح أنه لا حاجة إلى رمز إضافي.
أبدا خارج التركيز التطبيق الخاص بك.اسأل نفسك دائمًا:
- ما الوظيفة التي يجب تنفيذها الآن؟
- ما هو رمز يستحق الكتابة؟
استفسر عن الأفكار التي تتبادر إلى الذهن وقم بتقييم الاقتراحات من الخارج. خلاف ذلك ، قد يقتل رمز إضافي المشروع.
إن معرفة متى يجب ألا تضيف الكثير سوف يبقي قاعدة الشفرة تحت سيطرة مشددة.
في بداية المسار ، يكون للمبرمج ملفان أو ثلاثة ملفات مصدر فقط. كل شيء بسيط. يتطلب تجميع التطبيق وتشغيله الحد الأدنى من الوقت ؛ من الواضح دائمًا أين وما الذي تبحث عنه.
مع توسيع التطبيق ، تظهر المزيد والمزيد من ملفات التعليمات البرمجية. تملأ الدليل ، ولكل منها مئات الأسطر. من أجل تنظيم كل هذا بشكل صحيح ، سيكون عليك إنشاء أدلة إضافية. في الوقت نفسه ، يصبح من الصعب أكثر فأكثر أن تتذكر أي الوظائف هي المسؤولة عن ماذا وما هي الإجراءات التي تسببها ؛ اصطياد الحشرات يستغرق أيضًا وقتًا أطول. أصبحت إدارة المشاريع أكثر تعقيدًا ، وليس واحدة فقط ، ولكن هناك حاجة إلى العديد من المطورين لتتبع كل شيء. تبعا لذلك ، فإن التكاليف ، النقدية والمؤقتة على حد سواء ، آخذة في الازدياد ، وتم إعاقة عملية التطوير.
يصبح المشروع في النهاية ضخمًا ، مضيفًا أن كل وظيفة جديدة يتم توفيرها بصعوبة كبيرة وكبيرة. حتى بالنسبة لشيء ضئيل للغاية ، عليك قضاء عدة ساعات. تصحيح الأخطاء الموجودة يؤدي إلى ظهور أخطاء جديدة ، وتعطلت مواعيد إطلاق التطبيق.
الآن علينا أن نقاتل من أجل حياة المشروع. لماذا؟
الحقيقة هي أنك ببساطة لم تفهم متى لم تكن بحاجة إلى إضافة رمز إضافي ، وأجابوا بـ "نعم" على كل جملة وفكرة. كنت أعمى ، والرغبة في خلق شيء جديد تجعلك تتجاهل الحقائق المهمة.
يبدو وكأنه سيناريو فيلم رعب ، أليس كذلك؟
هذا هو بالضبط ما سيحدث إذا استمرت في قول نعم. حاول أن تفهم عندما لا يستحق الرمز الإضافة. إزالة لا لزوم لها من المشروع - وهذا سوف يسهل كثيرا حياتك وتوسيع وجود التطبيق.
"كان أحد أكثر أيامي إنتاجية عندما قمت بحذف 1000 سطر من التعليمات البرمجية."
- كين طومسون.
تعلم فهم عندما لا تحتاج إلى كتابة التعليمات البرمجية أمر صعب. لكن هذا ضروري.
نعم ، أعلم أنك قد شرعت للتو في مسار مطور وترغب في كتابة التعليمات البرمجية. هذا جيد ، لا تفقد هذا الانطباع الأول ، ولكن لا تغفل عن نظره عوامل مهمة بسبب الحماس. أدركنا كل شيء من خلال التجربة والخطأ. سوف ترتكب أخطاء أيضًا وتتعلم منها. ولكن إذا استطعت أن تتعلم درسًا مما سبق ، فسيصبح عملك أكثر وعياً.
استمر في الإبداع ، ولكن تعرف متى تقول لا.
توصي Skillbox بما يلي: