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

الصورة من قبل توبياس وينكلمان على Unsplash

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

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

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

  • استخدام التحكم في الإصدار أكثر احترافًا
  • استخدم التسمية الدلالية للمتغيرات والوظائف
  • تشمل التعليقات والوثائق
  • ينت لأسلوب ثابت
  • اكتب الاختبارات الآلية لرمزك

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

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

التحكم في الإصدار

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

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

  • البرنامج التعليمي المقدم من GitHub
  • دروس مقدمة من Bitbucket
  • مقدمة إلى Git و GitHub للمبتدئين

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

الصفحة المقصودة لمستودع على GitHub ، تظهر بعض الإلتزامات الفظيعة

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

التسمية الدلالية

أنت تعرف ما هو لطيف؟ عندما يمكنك فهم ما يفعله الكود في لمحة. في البرمجة ، هناك قول مأثور قديم مفاده أن "الكود الجيد هو توثيق ذاتي" ويجب أن تكتب دائمًا مع وضع ذلك في الاعتبار. يجب أن تحاول كتابة التعليمات البرمجية بطريقة يمكن قراءتها تقريبًا مثل الجملة.

تسمية متغير

أسماء المتغيرات القصيرة مقابل الأسماء الوصفية

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

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

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

أسماء الوظائف

يجب أن تبدأ أسماء الدوال بالأفعال للإشارة إلى أنها تؤدي إجراءً ما. على سبيل المثال ، يجب أن تحصل الحروف والأدوات على كائن على [PropertyName] أو تعيين [PropertyName]. يمكن تسمية الوظيفة التي تقدم طلب AJAX للحصول على تفاصيل المنتج ، fetchProductDetails.

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

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

التعليقات والوثائق

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

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

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

تعليقات الوثائق

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

باستخدام Docblockr لكتابة وثائق وظيفة JSDoc في سامية

أحد الأساليب الشائعة لكتابة مستندات التعليق هو JSDoc. من خلال المكونات الإضافية مثل Docblockr (لـ Sublime) ، يمكنك بسهولة إضافة التعليقات المملوءة تلقائيًا بهذا النمط. إذا قررت بعد ذلك إنشاء وثائق منها ، فهناك أدوات يمكنها القيام بذلك تلقائيًا. تحقق منها في JSDoc Github repo.

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

اقرأ ، من فضلك

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

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

هنا أضفنا القليل من التعليقات التي توضح ما تقوم به وظائفنا ، والأنواع التي من المتوقع أن تكون معلماتها ، وما القيمة التي قد تُرجعها وظائفنا. في تدوين JSDoc ، تعني السلسلة [] صفيف سلاسل ، والرقم | غير محدد يعني رقم أو غير معرف. هذه هي مفيدة لمعرفة كيفية العمل مع وظيفة في لمحة.

Linting

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

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

Linter تضيء مثل شجرة عيد الميلاد

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

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

انشاء linter

بالنسبة لجافا سكريبت ، فإن اللغة الأكثر شعبية الحالية هي ESLint. إنه سهل التهيئة ويدمج في معظم برامج تحرير النصوص ، مثل Sublime و Atom و VS Code والعديد من الآخرين. لأنه يأتي مع مجموعة من القواعد الموصى بها الافتراضية التي يمكنك تمكينها بسهولة ، أو يمكنك إعداد التكوين المخصص الخاص بك. يتيح لك ESLint أيضًا تمديد أدلة النمط الخارجية. يظهر مقال براندون موريلي عن أدلة الأسلوب بعض المقالات الشعبية. أنا شخصياً أحب تمديد دليل Javascript Style Guide من Airbnb وتخصيص بعض القواعد من هناك. (المسافة البادئة الأربعة أفضل من اثنين. آسف ، لا آسف. )

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

  • وثائق ESLint الرسمية
  • لماذا (وكيف) استخدام eslint في مشروعك بواسطة Node.js Foundation
  • التشغيل والتشغيل مع ESLint - Linterable JavaScript Linter

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

تقديم الوبر لمؤسستك الهندسية

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

اختبارات

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

مثال على اختبار مكتوب باستخدام الياسمين

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

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

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

إضافة اختبار إلى سير العمل الخاص بك

كتب فيتالي زيدمان وصفًا رائعًا لحالة اختبار جافا سكريبت الحالي الذي أوصي به كنقطة انطلاق جيدة للبحث عن كيفية البدء في الاختبار. أوصي أيضًا بـ James Sinclair’s Gentle Introduction to JavaScript to Driven Development.

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

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

حسن المظهر

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

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

نقوم بالتوظيف! إذا كنت تتبع بالفعل جميع هذه الممارسات وكنت تبحث عن فريق جديد ، فراجع وظائف في Splash!