بگذارید اول یک مسئله را برایتان روشن کنم. اگر شما یک برنامه‌نویس تازه‌کار هستید، هدف این مقاله این نیست که باعث شود حس بدی درباره اشتباهاتی که ممکن است مرتکب شوید داشته باشید. بلکه هدف این است که شما را از آنها آگاه کند، به شما آموزش دهد که چگونه اثرات آنها را ببینید، و به شما یادآوری کند از آنها خودداری کنید.
من این اشتباهات را در گذشته مرتکب شده‌ام و از تک تک آنها هم یاد گرفته‌ام. من خوشحالم که توانسته‌‌ام برخی عادات کدنویسی را شکل دهم، که این عادات به من کمک می‌کنند تا از آن اشتباهات خودداری کنم. شما هم باید همین کار را انجام دهید.
اشتباهات مذکور در این لیست، به هیچ ترتیب خاصی چیده نشده‌اند.
در بخش اول این مقاله همراه ما باشید:
۱) کدنویسی بدون برنامه‌ریزی
عموما محتویات با کیفیت بالا، نمی‌توانند به ساگی ساخته شوند. این محتویات نیازمند تفکر و تحقیق با دقت بالا هستند. برنامه‌های با کیفیت بالا هم از این قضیه مستثنا نیستند.
نوشتن برنامه‌های با کیفیت، روندی دارای یک جریان است: تفکر، تحقیق، برنامه‌ریزی، نوشتن، اعتبارسنجی، اصلاح. متاسفانه هیچ مخفف خوبی برای این چند مورد وجود ندارد. شما باید خود را عادت دهید تا همیشه هر کدام از این فعالیت‌ها را به مقدار مناسب داشته باشید.
یکی از بزرگ‌ترین اشتباهاتی که من به عنوان یک برنامه‌نویس تازه‌کار مرتکب شدم، این بود که بدون تفکر و تحقیق به اندازه کافی، سریعا شروع به کدنویسی می‌کردم. این کار برای یک برنامه کوچک پاسخ می‌دهد، اما یک تاثیر بزرگ و منفی بر روی برنامه‌های بزرگ دارد.
درست به مانند این که قبل از زدن یک حرف باید خوب فکر کنید تا از آن پشیمان نشوید، قبل از نوشتن کدی که ممکن است از آن پشیمان شوید هم باید خوب فکر کنید. کدنویسی راهی است برای برقراری ارتباط با افکار خود.
سومین رئیس جمهور ایالات متحده، یعنی Thomas Jefferson گفته است:
«وقتی که عصبانی هستید، قبل از صحبت کردن تا ۱۰ بشمارید. اگر خیلی عصبانی هستید، تا ۱۰۰ بشمرید.»
ویرایش من از این نقل قول هم به این صورت است:
«وقتی که در حال بازبینی یک کد هستید، قبل از بازسازی یک خط از آن تا ۱۰ بشمارید. اگر کد شما آزمایشی (test) در خود ندارد، تا ۱۰۰ بشمرید.»
برنامه‌نویسی اکثرا درباره خواندن کدهای قبلی، تحقیق درباره این که به چه چیزی نیاز داریم و این که چگونه در سیستم ما جای می‌گیرد، و برنامه ریزی برای نوشتن امکاناتی با افزایشات کوچک و قابل آزمایش است. نوشتن خط‌های کد احتمالا تنها ۱۰ درصد کل فرایند است.
به برنامه‌نویسی به عنوان نوشتن چند خط کد فکر نکنید. برنامه‌نویسی یک خلاقیت بر پایه منطق است که نیاز به پرورش دارد.
۲) برنامه‌ریزی بیش از حد قبل از کدنویسی
بله، برنامه‌ریزی قبل از رفتن به سراغ کدنویسی خوب است، اما حتی چیزهای خوب هم وقتی که بیش از حد انجامشان میدهید، می‌توانند به شما آسیب برسانند. خوردن آب بیش از حد می‌تواند شما را مسموم کند.
به دنبال یک برنامه بی نقص نباشید. چنین برنامه‌ای در دنیای برنامه‌نویسی وجود ندارد. به دنبال یک برنامه باشید که به اندازه کافی خوب است؛ چیزی که بتوانید از آن برای شروع کار استفاده کنید. واقعیت این است که برنامه شما تغییر خواهد کرد، اما چیزی که برای آن خوب است، این است که آن را در نوعی ساختار قرار دهید که وضوح بیشتری بر روی کد شما سوار می‌کند. برنامه‌ریزی بیش از حد، به سادگی راهی برای هدر دادن وقت خود است.
من فقط درباره برنامه‌ریزی ویژگی‌های کوچک صحبت می‌کنم. این که تمام ویژگی‌ها را به صورت یکجا برنامه‌ریزی کنید، به سادگی غیر قانونی است. ما آن را «رویکرد آبشاری» می‌نامیم. رویکرد آبشاری یک نقشه خطی با قدم‌های متمایز است که قرار است به صورت همزمان به اتمام برسند. به راحتی می‌توانید فرض کنید که این رویکرد به چه مقدار برنامه‌ریزی نیاز دارد. من درباره این نوع برنامه‌ریزی صحبت نمی‌کنم. رویکر آبشاری برای اکثر پروژه‌های نرم‌افزاری کار نمی‌کند. هر چیز پیچیده‌ای می‌تواند با سازگاری‌های سریع، در قالب واقعیت پیاده‌سازی شود.
نوشتن برنامه‌ها باید یک فعالیت پاسخگو باشد. در یک برنامه آبشاری شما ویژگی‌هایی اضافه خواهید کرد که هیچ وقت فکرشان را نکرده بودید، و همچنین ویژگی‌هایی را به دلایلی که هیچ وقت در نظر نگرفته بودید حذف خواهید کرد. شما باید باگ‌ها را برطرف کرده، و خود را با تغییرات تطبیق دهید. شما باید چابک باشید.
گرچه، همیشه چند مورد از ویژگی‌های بعدی خود را برنامه‌ریزی کنید. با دقت این کار را انجام دهید، زیرا برنامه‌ریزی کم و بیش از حد، هر دو به کیفیت کد شما آسیب خواهند زد و کیفیت کد چیزی نیست که بخواهید آن را در خطر قرار دهید.
۳) دست کم گرفتن اهمیت کیفیت کد
اگر فقط می‌توانید بر روی یک بُعد از کدی که می‌نویسید تمرکز کنید، این بعد باید خوانایی آن باشد. یک کد ناواضح به هیچ دردی نمی‌خورد. این کد حتی قابل بازیابی هم نیست.
هیچ وقت اهمیت کیفیت کد را دست کم نگیرید. به کد نویسی به عنوان راهی برای ارتباط با پیاده‌سازی‌ها نگاه کنید. کار اصلی شما به عنوان یک کدنویس، این است که به وضوح با پیاده‌سازی راه حل‌هایی که بر رویشان کار می‌کنید، ارتباط برقرار کنید.
یکی از نقل قول‌های مورد علاقه من درباره برنامه‌نویسی، این است:
«همیشه به نوعی کدنویسی کنید که انگار کسی که در نهایت کد شما را نگهداری خواهد کرد، یک روانی خشن خواهد بود که می‌داند شما کجا زندگی می‌کنید.»
حتی کوچک‌ترین چیزها هم اهمیت دارند. برای مثال، اگر نسبت به فرو رفتگی‌ها و حروف بزرگ حساس نباشید، باید گواهی کدنویسی خود را از دست بدهید.
tHIS is
WAY MORE important
than
you think
یک چیز ساده دیگر هم استفاده از خطوط طولانی است. خواندن هر چیزی بیشتر از ۸۰ کاراکتر، بسیار سخت‌تر است. شاید شما وسوسه شوید که برخی شروط طولانی را در یک خط قرار دهید، تا یک بلوک بیانیه if را واضح‌تر نگه دارید. این کار را انجام ندهید. هیچ وقت بالاتر از ۸۰ کاراکتر در یک خط نروید، هیچ وقت.
بسیاری از مشکلات ساده به مانند این مورد، می‌توانند با استفاده از ابزار linting و قالب‌بندی برطرف شوند. در JavaScript، دو ابزار عالی داریم که با یکدیگر به خوبی کار می‌کنند: ESLint و Prettier. لطفی در حق خود بکنید و از آن دو استفاده کنید.
در اینجا هم برخی اشتباهات دیگر مربوط به کیفیت کد را مشاهده می‌نمایید:
- استفاده از چند خط در یک تابع یا یک فایل. شما همیشه باید کد طولانی را به قطعه‌های کوچک‌تر تقسیم کنید که می‌توانند به صورت جداگانه آزمایش شده، و مدیریت شوند. من به شخصه فکر می‌کند هر تابعی که بیش از ده خط کد دارد، بیش از حد طولانی است، اما این یک قانون کلیدی است.
- استفاده از منفی‌های دوتایی. لطفا این کار را انجام ندهید.
- استفاده از نام‌های متغیر کوتاه، عمومی و بر پایه نوع. به متغیرهای خود نام‌های توصیفی و نامبهم بدهید.
- hardcode کردن رشته‌ها و اعداد اولیه بدون توضیحات. اگر می‌خواهید منطق بزرگی بنویسید که به یک رشته یا مقدار اولیه ثابت نیاز دارد، مقدار مورد نظر را در یک constant قرار دهید و یک نام خوب به آن بدهید.
const answerToLifeTheUniverseAndEverything = 42;
- استفاده از میان‌برهای نامرتب برای جلوگیری از صرف زمان بیشتر بر روی مشکلات ساده. با مشکلات نرقصید. با واقعیت‌های خود رو در رو شوید.
- تصور این که یک کد بزرگ، بهتر است. در اکثر موارد کد کوتاه‌تر بهتر است. فقط اگر نوشتن کد طولانی‌تر کد آن را خواناتر می‌کند، این کار را انجام دهید. برای مثال از عبارات سه‌گانه تو در تو استفاده نکنید که بتوانید کد خود را کوتاه‌تر نگهه دارید، و همچنین وقتی که نیازی نیست، کد را از روی عمد طولانی‌تر نکنید. حذف کردن کد غیر ضروری بهترین کاری است که می‌توانید در یک برنامه انجام دهید.
- استفاده بیش از حد از منطق شرطی. اکثر چیزهایی که فکر می‌کنید به منطق شرطی نیاز دارند، می‌توانند بدون آن انجام شوند. تمام راه‌های جانبی را در نظر بگیرید و منحصرا بر پایه خوانایی انتخاب کنید. در صورتی که نمی‌توانید کارایی را اندازه بگیرید، برای آن بهینه‌سازی نکنید.
۴) انتخاب اولین راه حل
وقتی که من در حال شروع برنامه‌نویسی بودم، به یاد دارم که وقتی با یک مشکل رو به رو می‌شدم، یک راه حل پیدا می‌کردم و سریعا با آن پیش می‌رفتم. من درست قبل از این که درباره پیچیدگی‌ها و شکست‌های احتمالی اولین راه حل تشخیص داده خود فکر کنم، به سراغ پیاده‌سازی می‌رفتم.
با این که راه حل اول می‌تواند وسوسه کننده باشد، راه حل‌های خوب معمولا وقتی کشف می‌شوند که شروع به زیر سوال بردن تمام راه حل‌هایی که یافته‌اید می‌نمایید. اگر نمی‌توانید برای یک مشکل به چند راه حل فکر کنید، احتمالا این نشانه‌ای است از این که شما مشکل مورد نظر را کاملا درک نمی‌کنید.
شغل شما به عنوان یک برنامه‌نویس حرفه‌ای این است که یک راه حل را برای یک مشکل بیابید، این که ساده‌ترین راه حل را برای یک مشکل بیابید. منظور من از ساده این است که راه حل مورد نظر باید به درستی کار کند و همچنان خواندن، درک و نگهداری آن راحت باشد.
۵) دست از کار نکشیدن
یکی از اشتباهات دیگری که خیلی مرتکب می‌شدم، این بود که حتی پس از این که پی می‌‌برم راه حل اول ساده‌ترین رویکرد نیست، همچنان بر روی آن باقی می‌ماندم. این مسئله احتمالا از نظر روانی مربوط به ذهنیت «دست از کار نکشیدن» می‌باشد. در اکثر فعالیت‌ها این یک ذهنیت خوب است، اما نباید نسبت به برنامه‌نویسی صدق کند. در واقع وقتی که به برنامه‌نویسی می‌رسیم، ذهنیت صحیح این است که زود شکست بخوریم و خیلی شکست بخوریم.
به محض این که به یک راه حل شک کردید، دور انداختن آن و تفکر مجدد درباره مشکل را در نظر بگیرید. مهم نیست که چقدر در آن راه حل سرمایه گذاری کرده باشید؛ همچنان این مسئله صحت دارد. ابزار کنترل منبع مانند Git می‌توانند به شما کمک کننند تا راه حل‌های مختلفی را امتحان کنید. از آن بهره ببرید.
۶) جستجو نکردن در گوگل
موارد زیادی بوده‌اند که در آنها من زمان با ارزشی را صرف تلاش برای رفع یک مشکل کردم، درحالیکه که باید اول درباره آن تحقیق می‌کردم.
وقتی که به یک مشکل بر می‌خورید، به احتمال زیاد یک نفر دیگر هم به آن بر خورده و راه حلی برایش یافته است، مگر این که در حال استفاده از یک فناوری بسیار جدید باشید. ابتدا مشکل خود را در گوگل جستجو کنید، و از هدر رفتن مقدار زیادی زمان جلوگیری کنید.
گاهی اوقات گوگل به شما نشان می‌دهد چیزی که فکر می‌کنید یک مشکل است، در واقع نیست و کاری که باید انجام دهید، این نیست که آن را برطرف کنید، بلکه آن را تقبل کنید. فرض نکنید که شما هر چیزی که برای انتخاب یک راه حل برای یک مشکل مورد نیاز است را دارید. گوگل شما را شگفت‌زده خواهد کرد.
گرچه، مواظب باشید که برای چه چیزی جستجو می‌کنید. یک نشانه دیگر از یک تازه‌کار بودن، این است که کد دیگران را بدون درک آن، کپی و پیست کنید. با این که ممکن است آن کد مشکل شما را برطرف کند، هیچ وقت نباید از کدی استفاده کنید که آن را به طور کامل درک نمی‌کنید.
اگر می‌خواهید یک کدنویس خلاق باشید، هیچ وقت فکر نکنید که می‌دانید چه کاری انجام میدهید.
۷) عدم استفاده از کپسوله سازی
نکته در استفاده از الگوی شیء گرا نیست. استفاده از مفهوم کپسوله سازی همیشه پرکاربرد است. عدم استفاده از کپسوله سازی معمولا به یک سیستم ختم می‌شود که نگهداری آن سخت‌تر است.
در یک برنامه، یک ویژگی فقط باید یک مکان داشته باشد که آن را مدیریت کند. این کار معمولا مسئولیت یک آبجکت تنها است. این آبجکت فقط باید چیزی که قطعا برای آبجکت‌های دیگر ضروری است را نمایان کند. این مسئله درباره محرمانگی نیست، بلکه دباره مفهوم کاهش وابستگی‌ها بین بخش‌های مختلف یک برنامه است. ماندن در کنار این قوانین شما را قادر می‌سازد تا در بخش‌های داخلی کلاس‌ها، آبجکت‌ها و توابع خود تغییراتی ایجاد کنید، بدون این که نگران خراب کردن همه چیز در مقیاسی بزرگ‌تر باشید.
واحدهای مفهومی منطق و state باید کلاس‌های مختص خود را داشته باشند. منظور من از کلاس، یک قالب طرح است. این طرح می‌تواند یک آبجکت کلاس یا یک آبجکت تابع باشد. همچنین ممکن است آن را به عنوان یک ماژول یا پکیج شناسایی کنید.
در داخل یک کلاس منطق، قطعه‌های عملیاتی خودمختار باید متدهای مختص خود را داشته باشند. متدها فقط باید یک کار را انجام دهند و آن کار را به خوبی انجام دهند. کلاس‌های مشابه، باید از نام‌های متد مشابه استفاده کنند.
من به عنوان یک برنامه‌نویس تازه‌کار، همیشه غریزه شروع یک کلاس جدید برای یک واحد مفهوم را نداشتم و اغلب نمی‌توانستم تشخیص دهم که چه چیزی می‌تواند خودمختار باشد. اگر شما یک کلاس «Util» می‌بینید که به عنوان مکانی برای تجمع چیزایی که به هم تعلق ندارند استفاده شده است، این نشانه‌ای از کد یک فرد تازه‌کار است. اگر یک تغییر ساده اعمال می‌کنید و پی می‌برید که تغییر مورد نظر یک تاثیر آبشاری دارد و شما باید چندین تغییر را در جای دیگری انجام دهید، این هم نشانه دیگری از کد یک فرد تازه‌کار است.
قبل از اضافه کردن یک متد به یک کلاس، یا اضافه کردن مسئولیت‌های بیشتر به یک متد، فکر کنید و غرایز خود را زیر سوال ببرید. در اینجا شما به زمان نیاز دارید. آن را رد نکنید و با خود فکر نکنید که بعدا آن را بازسازی خواهید کرد. فقط بار اول آن را به طور صحیح انجام دهید.
ایده اصلی در اینجا این است که شما می‌خواهید کدتان پیوستگی بالا و جفت‌سازی کمی داشته باشد. این یک عبارت فانتزی برای بیان این است که کدهای مربوط به یکدیگر را با هم (در یک کلاس) نگه دارید و وابستگی‌های بین کلاس‌های مختلف را کاهش دهید.
۸) برنامه‌ریزی برای ناشناخته‌ها
اغلب وسوسه کننده است که فراتر از راه حلی در حال نوشتنش هستید، فکر کنید. با هر خط کدی که می‌نویسید، تمام انواع مختلف «اگر ... چه؟»ها به سر شما می‌زنند. این اتفاق برای آزمایش موقعیت‌های خاص خوب است، اما استفاده از آن به عنوان یک راننده برای نیازهای بالقوه اشتباه می‌باشد.
شما باید تشخیص دهید که «اگر ... چه؟» شما به کدام یک از این دو دسته تعلق دارد. کدی که امروز به آن نیاز ندارید را ننویسید. برای آینده ناشناخته برنامه‌ریزی نکنید.
نوشتن یک ویژگی، به علت این که فکر می‌کنید در آینده ممکن است به آن نیاز داشته باشید، به سادگی اشتباه است. این کار را انجام ندهید.
همیشه یک مقدار حداقلی از کد که امروز به آن نیاز دارید را برای راه حلی که در حال پیاده‌سازی آن هستید، بنویسید. موقعیت‌های خاص را مدیریت کنید، اما امکانات خاصی برای آنها اضافه نکنید.
۹) ندانستن ساختارهای داده مناسب
برنامه‌نویسان تازه‌کار وقتی که برای مصاحبات آماده می‌شوند، معمولا تمرکز زیادی بر روی الگوریتم‌ها قرار می‌دهند. این که الگوریتم‌های خوب را تشخیص داده و وقتی که به آنها نیاز است، آنها را به کار بگیرید خوب است، اما حفظ کردن آنها احتمالا هیچ وقت به نبوغ برنامه‌نویسی شما نسبت داده نمی‌شود.
گرچه حفظ کردن نقات قوت و ضعف‌های ساختارهای داده متنوع که می‌توانید در زبان خود استفاده کنید، قطعا شما را تبدیل به یک توسعه دهنده بهتر خواهد کرد.
استفاده از ساختارهای داده اشتباه، یک نشانه بزرگ و به خوبی روشن شده است که نشان دهنده کد یک فرد تازه‌کار است.
هدف این مقاله آموزش ساختارهای داده به شما نیست، اما بگذارید به چند مثال کوتاه اشاره کنم:
- استفاده از لیست‌ها (آرایه‌ها) به جای مپ‌ها (آبجکت‌ها) برای مدیریت رکوردها
رایج‌ترین اشتباه ساختار داده، معمولا استفاده از لیست‌ها به جای مپ‌ها برای مدیریت یک لیست از رکوردها می‌باشد. بله، برای یک لیست از رکوردها بهتر است از یک مپ استفاده کنید.
دقت کنید که من درباره یک لیست از رکوردها صحبت می‌کنم که در آن هر رکورد یک مشخص کننده دارد، و از آن مشخص کننده برای گشتن به دنبال آن رکورد استفاده خواهد شد. استفاده از لیست‌ها برای مقادیر عددی اشکالی ندارد و اغلب به خصوص وقتی که تمرکز شما بر روی وارد کردن مقادیر به لیست است، انتخاب بهتری هستند.
در JavaScript، رایج‌ترین ساختار داده لیست یک آرایه است و رایج‌ترین ساختار داده مپ هم یک آبجکت می‌باشد.
استفاده از لیست‌ها به جای مپ‌ها برای مدیریت رکوردها، اغلب اشتباه است. با این که این نکته در واقع فقط برای مجموعه‌های بزرگ صحیح است، من پیشنهاد می‌کنم که همیشه بر روی آن باقی بمانید. علت اصلی که این مسئله مهم است، این است که در هنگام گشتن به دنبال رکوردها با استفاده از مشخص کننده آنها، مپ‌ها بسیار سریع‌تر از لیست‌ها هستند.
- عدم استفاده از Stackها
وقتی که در حال نوشتن هر کدی هستید که نیاز به نوعی برگشت دارد، همیشه وسوسه کننده است که از توابع برگشتی ساده استفاده کنید. گرچه، معمولا بهینه‌سازی کد برگشتی سخت است، به خصوص در محیط‌های single-thread.
بهینه‌سازی کد برگشتی، به چیزی که توابع بر می‌گردانند بستگی دارد. برای مثال، بهینه‌سازی یک تابع برگشتی که دو یا چند فراخوانی را به خود بر می‌گرداند، بسیار سخت‌تر از بهینه‌سازی یک تابع برگشتی است که به سادگی یک فراخوانی را به خود بر می‌گرداند.
چیزی که ما به عنوان تازه‌کاران دوست داریم به آن بیش از حد اهمیت دهیم، این است که یک راه جایگزین برای استفاده از توابع برگشتی وجود دارد. شما فقط می‌توانید از یک ساختار stack استفاده کنید. خودتان فراخوانی‌های تابع را به یک stack بفرستید و وقتی که آماده‌اید تا از آنها عبور کنید، شروع به اعزام آنها نمایید.
۱۰) بدتر کردن کد موجود
فرض کنید که یک اتاق به هم ریخته این چنینی به شما داده شده است:
سپس از شما درخواست شده است تا یک آیتم به آن اتاق اضافه کنید. از آنجایی که در حال حاضر هم این اتاق به هم ریخته است، شاید وسوسه شوید که آن آیتم را نیز هر جایی که دوست دارید قرار دهید. به این صورت تنها در چند ثانیه کار شما به اتمام خواهد رسید.
این کار را با یک کد به هم ریخته انجام ندهید. آن را بدتر نکنید! همیشه کد را کمی مرتب‌تر از زمانی که شروع به کار با آن کردید رها کنید.
کار صحیح برای انجام دادن در اتاق بالا، این است که چیزی که مورد نیاز است را مرتب‌کنید، تا آیتم جدید را در مکان مناسب قرار دهید. برای مثال اگر آیتم شما یک تکه لباس است که باید در یک کمد قرار داده شود، شما به یک مسیر باز به آن کمد نیاز دارید. این بخشی از انجام کار خود به صورت صحیح است.
معمولا برخی شیوه‌های اشتباه هم وجود دارند که کد را کمی به هم ریخته‌تر از آن چیزی که بود می‌کنند (البته این لیست کامل نیست):
- تکرار کد. اگر شما یک بخش کد را کپی / پیست کنید تا فقط یک خط بعد از آن را تغییر دهید، شما به سادگی در حال تکرار کد و به هم ریخته‌تر کردن آن هستید. در مورد مثال اتاق به هم ریخته بالا، این کار به مانند این است که به جای یک صندلی با قابلیت تنظیم ارتفاع، یک صندلی دیگر با ارتفاع کمتر در آن قرار دهید. همیشه مفهوم چکیده‌سازی را در ذهن خود نگه دارید و وقتی که می‌توانید، از آن استفاده کنید.
- عدم استفاده از فایل‌های پیکربندی. اگر شما باید از یک مقدار استفاده کنید که می‌تواند در محیط‌ها یا زمان‌های مختلف، متفاوت باشد، جای آن مقدار در یک فایل پیکربندی است. اگر باید از یک مقدار در چند جای کد خود استفاده کنید، جای آن مقدار در یک فایل پیکربندی است. فقط هر زمان که یک مقدار جدید را به کد خود معرفی می‌کنید، این سوال را از خود بپرسید: آیا این مقدار به یک فایل پیکربندی تعلق دارد؟ احتمالا پاسخ آن همیشه «بله» خواهد بود.
- استفاده از بیانیههای شرطی و متغیرهای موقت غیر ضروری. هر بیانیه if یک شاخه منطقی است که باید حداقل دو بار آزمایش شود. وقتی که می‌توانید بدون فدا کردن خوانایی کد، از شرط‌ها خودداری کنید، باید همین کار را انجام دهید. مشکل اصلی در اینجا گسترش یک تابع با یک شاخه منطق، با جای تعریف یک تابع دیگر است. هر زمان که فکر می‌کنید به یک بیانیه if یا یک تابع جدید نیاز دارید، باید از خود بپرسید: آیا من کد را در سطح مناسب تغییر می‌دهم، یا آیا باید درباره مشکل در یک سطح بالاتر فکر کنم؟
درباره موضوع بیانیههای if غیر ضروری، درباره این کد فکر کنید:
function isOdd(number) {
if (number % 2 === 1) {
return true;
} else {
return false;
}
}
تابع isOdd در بالا، چند مشکل دارد، اما آیا می‌توانید واضح‌ترین آنها را ببینید؟
این تابع از یک بیانیه if غیر ضروری استفاده می‌کند. در اینجا یک کد معادل را مشاهده می‌نمایید:
function isOdd(number) {
return (number % 2 === 1);
};
۱۱) نوشتن کامنت درباره مسائل واضح
من به روش سختی یاد گرفتم که وقتی می‌توانم، از نوشتن کامنت‌ها خودداری کنم. اکثر کامنت‌ها می‌توانند با عناصری در کد شما جایگزین شوند که بهتر نامگذاری شده‌اند.
برای مثال، به جای نوشتن این کد:
// این تابع فقط اعداد فرد موجود در یک آرایه را جمع می‌کند
const sum = (val) => {
return val.reduce((a, b) => {
if (b % 2 === 1) { // اگر عدد فعلی زوج است
a+=b; // عدد فعلی را به جمع اضافه کن
}
return a; // جمع مورد نظر
}, 0);
};
می‌توان همان کد را به این صورت و بدون کامنت نوشت:
const sumOddValues = (array) => {
return array.reduce((accumulator, currentNumber) => {
if (isOdd(currentNumber)) {
return accumulator + currentNumber;
}
return accumulator;
}, 0);
};
فقط استفاده از نام‌های بهتر برای توابع و آرگومان‌ها، به سادگی اکثر کامنت‌ها را غیر ضروری می‌کند. قبل از نوشتن هر کامنتی، آن را در ذهن داشته باشید.
گرچه، گاهی اوقات در موقعیت‌هایی قرار می‌گیرید که تنها از طریق کامنت‌ها می‌توانید به کد خود وضوح بدهید. این وقتی است که باید کامنت‌های خود را به گونه‌ای ساختاربندی کنید که به جای سوال «این کد چه کاری انجام می‌دهد؟»، به سوال «چرا این کد؟» پاسخ دهد.
اگر خیلی وسوسه شده‌اید که یک کامنت «چرا» بنویسید تا کد خود را واضح‌تر کنید، لطفا به آنچه که واضح است اشاره نکنید. در اینجا مثالی از برخی کدهای غیر ضروری را مشاهده می‌نمایید که فقط می‌توانند در کد شما اختلالات بیشتری اضافه کنند:
// یک متغیر بساز و آن را با صفر شروع کن
let sum = 0;
// بر روی یک آرایه به صورت حلقه‌وار حرکت کن
array.forEach(
// به ازای هر عدد در آرایه
(number) => {
// عدد فعلی را به متغیر جمع اضافه کن
sum += number;
}
);
شما این برنامه‌نویس نباشید. این کد را قبول نکنید. اگر باید با کدهای این چنینی سر و کله بزنید، کامنت‌های این چنینی را حذف کنید. مهم‌تر از همه، به برنامه‌نویسانی که کامنت‌های این چنینی می‌نویسند یاد بدهید که چقدر کارشان اشتباه است. اگر به طور اتفاقی برنامه‌نویسانی را استخدام می‌کنید که کامنت‌هایی به مانند بالا می‌نویسند، بگذارید بدانند که احتمال دارد سر همین موضوع شغل خود را از دست بدهند.
تا به اینجا ۱۱ نکته را با هم بررسی کردیم. در قسمت دوم این مقاله که به زودی بر روی راکت قرار داده خواهد شد، ۱۴ نکته دیگر را تحت بررسی قرار خواهیم داد. با ما همراه باشید...
دیدگاه و پرسش
در حال دریافت نظرات از سرور، لطفا منتظر بمانید
در حال دریافت نظرات از سرور، لطفا منتظر بمانید