مدروس الترميز

لماذا يعتبر الترميز أكثر من مجرد توتير الرموز معًا

مبرمج يتحدث عن الكود

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

أهرامات جافا سكريبت

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

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

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

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

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

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

عقلية الميكانيكي

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

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

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

process.exit () ؛

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

  • Tom