جاوا اسکریپت

نحوه نوشتن کد جاوا اسکریپت قابل نگهداری در سال 2023 — Web یا Node.js

هر احمقی می تواند کدی بنویسد که کامپیوتر آن را بفهمد. برنامه نویسان خوب کدی را می نویسند که انسان بتواند آن را درک کند. - مارتین فاولر

طراحی سایت  سفارش طراحی سایت با بهترین متخصصان سایت 

توسعه جاوا اسکریپت هنوز در سال 2022 بی نظم است. با افزایش سرعت رایانه ها، ما باید برای برنامه نویسان کد بنویسیم، نه برای ماشین ها. این چیزی است که دنیای جاوا اسکریپت باید در مورد آن باشد.

سلب مسئولیت: این مقاله برای توسعه دهندگان JS (web یا Node.js) با حداقل تجربه متوسط ​​مناسب است. من فرض می کنم که شما قبلاً تجربه خوبی در نوشتن JS دارید.
مطالب این مقاله:

در همه جا از TypeScript استفاده کنید
جاوا اسکریپت و فریمورک های خود را به خوبی یاد بگیرید
قالب بندی کد و سبک
نظرات در کد و مستندات درون خطی
در صورت لزوم، تست های معنی دار و مفید بنویسید
قبل از اجرای ویژگی های پیچیده از نمونه های اولیه و/یا MVP ها استفاده کنید
پاداش: چند نکته اضافی

در همه جا از TypeScript استفاده کنید

از TypeScript نترسید. برای هر توسعه دهنده جاوا اسکریپت با تجربه معقولی، راهنمای رسمی 5 دقیقه ای "TypeScript for JavaScript Programmers" برای شروع نوشتن تایپ اسکریپ امروز کافی است.


متلب انجام پروژه متلب با بهترین متلب دانان

TypeScript به شما کمک می کند تا دوباره وارد شوید.

اگر از یک IDE یا ویرایشگری استفاده می کنید که دارای تکمیل خودکار، پیشنهادات، اسناد درون خطی و غیره است، می توانید The TypeScript™ را تجربه کنید. این 2 مثال را بدون هیچ زمینه ای ببینید:

// src/api/posts.jsexport default {
  getPosts: () => axios.get("/posts"),
}

مشکلات این روش باید بلافاصله برای شما آشکار شود. getPosts چه چیزی را برمی گرداند؟ اگر بخواهید از axios به واکشی تغییر دهید چه؟ اگر بخواهید یک تابع برای ایجاد یک پست اضافه کنید، چگونه می‌توانید ساختار داده را در یک شی تعریف کنید؟ اکنون به همان کد در TypeScript نگاه کنید:

// src/api/posts.tsexport interface Post {
  title: string;
  excerpt: string;
}export default {
  getPosts: function(): Promise> {
    return axios.get("/posts");
  },
};

تفاوت اصلی در شفافیت است. اکنون می توانید کد را درک کنید و ویرایشگر یا tsc شما در انجام آن به شما کمک می کند. وقتی با نسخه TS ofgetPosts تماس می گیرید، اکنون اطلاعات مفیدی دریافت خواهید کرد.
TypeScript Intellisense در VSCode
IntelliSense VSCode برای برگرداندن تایپ شده توابع

می‌توانید با TypeScript همه‌چیز را انتخاب کنید. مدل‌های مشترک بین سرور و کلاینت اطمینان حاصل می‌کنند که ساختار یکسانی را در هر دو طرف اعمال می‌کنید. اجباری کردن یک نوع ویژگی یا کلاس شی از اشتباهات تایپی در کد شما جلوگیری می کند. موارد زیادی وجود دارد که می توانید به لطف TypeScript باگ های احتمالی را پیدا کنید. نه تنها این، بلکه می توانید در عرض 2 سال دوباره به آن کد بازگردید.
جاوا اسکریپت و فریمورک های خود را به خوبی یاد بگیرید

یک مرد فقط به اندازه ابزارش خوب است. - Emert Wolf

در سال 2022، باید درک کنید که جاوا اسکریپت در پشت صحنه چه می کند. اگر اینطور نیست، به منبع جاوا اسکریپت مورد علاقه من - کتاب الکترونیکی رایگان Eloquent JavaScript - نگاهی بیندازید. همچنین باید بدانید که جاوا اسکریپت امروزه بسیار بیشتر از ساختارهای داده اولیه و APIهای مرورگر غیرقابل اعتماد ارائه می دهد. برای مثال، اکنون می‌توانید از جاوا اسکریپت نسل بعدی، مجموعه‌های کلیددار، یا API بین‌المللی‌سازی که قبلاً به خوبی پشتیبانی شده است استفاده کنید و مقداری در زمان CPU صرفه‌جویی کنید یا کدی را که کمتر به اشخاص ثالث وابسته است بنویسید.
میم جاوا اسکریپت همه جا


طراحی لوگو با بهترین طراح لوگو و طراحی لوگو حرفه ای


برای تبدیل شدن به یک توسعه‌دهنده بزرگ JS، باید جاوا اسکریپت ناهمزمان، توابع ژنراتور، پارادایم‌های کاربردی و شی گرا، محدوده، عملکرد و بسیاری موارد دیگر را بدانید. متأسفانه، اکثر توسعه دهندگان JS درک عمیق تری از جاوا اسکریپت ناهمزمان ندارند، که یک ویژگی اصلی در برنامه های مدرن است (به Promises و async / await فکر کنید).

در اینجا چیزی است که می توانید بدون یادگیری چیز جدیدی از امروز شروع کنید.

با اسناد کار کنید - خواه Next.js، Webpack، React، TypeScript یا هر ابزار دیگری باشد. به عنوان مثال، React دارای قلاب های زیادی است که اکثر ما هرگز استفاده نکرده ایم. وقتی یک ویژگی اصلی را توسعه می دهید یا یک پروژه را راه اندازی می کنید وقت خود را صرف کنید و عمیقاً در اسناد ابزارهای خود فرو بروید.
عملکرد کد را با پروفایل‌کننده‌ها، اشکال‌زداها، اندازه‌گیری‌های زمان و آزمایش‌های بیش از حد آزمایش کنید - چرا 100 هزار ردیف داده را در جدول React خود قرار ندهید؟ سعی کنید قبل از انتشار یک ویژگی اصلی، خوانایی خوب و همچنین عملکرد را هدف قرار دهید. بدترین سناریو را آزمایش کنید تا ببینید آیا کد شما یک گلوگاه عملکرد است یا خیر.
برای مثال، امیدوارم در مورد تفاوت‌های بین حلقه for و Array.prototype.forEach بدانید، زیرا ممکن است با عملیات محاسباتی سنگین یا جاوا اسکریپت ناهمزمان با مجموعه داده‌های بزرگ مفید باشد.
برای همه چیز به NPM متکی نباشید – پیاده سازی بیشتر ساده ترین کتابخانه ها توسط خودتان آسان است. شکست پد چپ در سال 2016 را به خاطر دارید؟ خود را از به‌روزرسانی بسته‌ها، آزمایش سازگاری، نجات دهید و با کمی کدنویسی اضافی رنج ببرید.
اگر از یک کتابخانه بدون مستند استفاده می کنید، کد منبع را بخوانید. در صورت تمایل، می‌توانید به کتابخانه‌های مستند و محبوب‌تر بچسبید.
تاثیر اندازه بسته خود را تجزیه و تحلیل کنید. برای یک تماس _.omit نیازی به وارد کردن کل کتابخانه lodash ندارید. بارگیری یک بسته بزرگ، بارگذاری اولیه برنامه شما را به میزان قابل توجهی کاهش می دهد. برای اطلاعات بیشتر در مورد bu

اندازه ndle، به این مقاله عالی کسرا (که بر روی Webpack تمرکز دارد) نگاهی بیندازید.

قالب بندی کد و سبک
عکس کد قالب بندی شده توسط Pankaj Patel (@pankajpatel) از Unsplash.
عکس کد قالب بندی شده توسط Pankaj Patel (@pankajpatel) از Unsplash.

این اغلب جنبه نادیده گرفته شده اما بسیار مهم توسعه است. صرف نظر از کار انفرادی یا تیمی، همیشه به اجرای برخی قوانین کمک می کند.

از ESLint و Prettier با هم استفاده کنید و می توانید روی کاری که کدتان انجام می دهد تمرکز کنید. تصور کنید دیگر هرگز در یک تست CI خودکار به دلیل کاما از دست رفته رد نشدید. همچنین، با استفاده از پیش‌فرض‌های شگفت‌انگیز Prettier، می‌توانید آرگومان‌های سبک کد را یک‌بار برای همیشه پایان دهید.
از نامگذاری توصیفی برای متغیرها استفاده کنید. فقط با خواندن نام باید بفهمید چیزی چیست. دکمهDomElem در مقابل el را در نظر بگیرید - درک کدام ساده تر است؟ یا بارگیری در مقابل isUserDataLoading. پیشوند متغیرهای بولی را با فعل like is یا has قرار دهید و از نام متغیرهای طولانی تر نترسید. IDE ها نام را پیشنهاد می کنند و کاربران vim به سرعت آن را کپی می کنند.
از فاصله استفاده کنید اگر از زیباتر استفاده کنید، به شکستگی های چند خطی می پیوندد. عالی. اما شکستگی‌های تک خطی، آن را دست نخورده باقی می‌گذارند که می‌خواهید استفاده کنید - حتی در داخل یک تابع یا اعلان شی اگر به خوانایی کمک کند.

نظرات در کد و مستندات درون خطی
نظرات در کد و مستندات درون خطی مثال عملی
نظرات در کد و مستندات درون خطی مثال عملی

حتی می توانید با استفاده از TSDoc یا JSDoc از استفاده از TypeScript به طور کلی اجتناب کنید، اگرچه من این کار را توصیه نمی کنم. از JSdoc در ارتباط با TypeScript استفاده کنید و همه متوجه خواهند شد که هنگام اجرای تماس شما در مکان های مختلف برنامه چه اتفاقی می افتد. شما می توانید از کلمات کلیدی یا قالب اسناد خود استفاده کنید تا زمانی که خواندن آن به طرز دردناکی آسان باشد.

هنگامی که بخش های پیچیده کد را می نویسید، همیشه هدف خود را بنویسید که کد خود را برای توسعه دهندگانی بنویسید که در زمانی که دیگر برای پاسخ به سؤالات در دسترس نباشید، هرگز آنها را ملاقات نخواهید کرد. پس از بازگشت به همان پروژه برای رفع یک اشکال در 2 سال، متوجه خواهید شد که چگونه همه چیز بدون خواندن کل کد منبع کار می کند.

آیا تا به حال یک setTimeout (someFn، 0) را بدون هیچ توضیحی در مورد اینکه چرا به پایان چرخه اجرا موکول شده است، دیده اید؟ می دانید چه کاری انجام می دهد، اما چرا در یک مکان تصادفی مانند نگاشت رنگ ها به آواتارهای کاربر در یک جدول نامیده می شود؟ در اینجا، یک نظر متفکرانه شما را از سردرد کشف مجدد یک اشکال از قبل رفع شده نجات می دهد.
در صورت لزوم، تست های معنی دار و مفید بنویسید

اگر آزمایش واحد محصول خود را دوست ندارید، به احتمال زیاد مشتریان شما نیز دوست ندارند آن را آزمایش کنند. - ناشناس

حتماً در مورد پارادایم توسعه تست محور (TDD) شنیده اید. اغلب اوقات، توسعه دهندگان را به دو گروه تقسیم می کند - برخی که TDD را اجرا می کنند و برخی که TDD را تحقیر می کنند.

من نه موافق و نه مخالف TDD هستم. در بعضی جاها منطقی است در حالی که در جاهای دیگر اتلاف منابع است. هنگامی که در حال توسعه یک ویژگی باطن حیاتی بر اساس مشخصات کامل هستید، از TDD سود خواهید برد. اما اگر در حال ایجاد یک برنامه داشبورد جلویی هستید، استفاده از TDD می تواند سرعت شما را به شدت کاهش دهد. در نظر بگیرید که آیا مزایا بیشتر از معایب است.
نمونه ای از تست های باطن
نمونه‌ای از خروجی آزمایش واحد در یک برنامه باطن Node.js

تست واحد - روش آزمایشی برای اکثر موارد استفاده است. آزمایش واحد برنامه frontend شما می‌تواند مؤلفه‌های پیچیده‌ای مانند طرح‌بندی‌ها، دیالوگ‌های مدال، جادوگران، فرم‌های تأییدشده چند مرحله‌ای سمت کلاینت، و غیره را ارزیابی کند. در توسعه باطن، می‌توانید بررسی کنید که آیا نقاط پایانی موارد خوب و بد را همانطور که انتظار دارید مدیریت می‌کنند.
تست End-to-End (E2E) - MVP واقعی تست ها. هنگامی که برنامه frontend شما بزرگ شد، منطقی است که هر بار که می خواهید آن را برای کاربران منتشر کنید، یک پایگاه داده آزمایشی ایجاد کنید و کد واقعی خود را در یک مرورگر واقعی آزمایش کنید. جامع ترین راه برای انجام تست E2E در بخش جلویی این است که مانند یک مهندس UX فکر کنید — جریان های کاربری خود را توسعه دهید یا آن داده ها را از ابزارهایی مانند HotJar جمع آوری کنید و کارهایی که کاربران شما انجام می دهند را آزمایش کنید.

اگر بخواهید می توانید چیزهای بسیار بیشتری را آزمایش کنید. یک اسکریپت آزمایشی رایج در package.json در پروژه‌های بزرگ‌تر ممکن است به این شکل باشد - "test": "NODE_ENV=test eslint && tsc --noEmit && jest && cypress run".

تست های بیشتر !== کیفیت بیشتر.

روی مفید بودن تست های خود تمرکز کنید. زمان را برای آزمایش یک دکمه ساده یا یک عملکرد کاربردی کوچک از دست ندهید. اینها تست‌های ویژگی‌هایی را که قبلاً دارید شکسته می‌شوند.


مجریان لیست مجریان نظام مهندسی اراک مجری ذیصلاح

بسیاری از مدیران و صاحبان محصولات یا حتی توسعه دهندگان ارشد از معیارهای پوشش کد معطل می شوند. پوشش کد باید یک قانون سرانگشتی باشد، نه یک قانون اجباری. با اعمال درصد بالایی از پوشش کد، توسعه دهندگان را مجبور می کنید برای صرفه جویی در زمان از کتابخانه های شخص ثالث استفاده کنند و ما قبلاً در مورد اینکه چرا این ایده آل نیست صحبت کردیم.
قبل از اجرای ویژگی های پیچیده از نمونه های اولیه و/یا MVP ها استفاده کنید

تنظیم یک چرخه عمر پروژه شفاف با مشخصات واضح و دانستن زمان انتشار هر فاز می تواند فرصت های زیادی را در اختیار شما قرار دهد تا در مورد کارهایی که قبلا انجام شده است فکر کنید. این عالی است، زیرا هنگامی که یک MVP "تمام شد"، شما حدودا


n ذهن خود را از کار معمولی دور کنید و نتیجه را ارزیابی کنید. این بهترین زمان برای انجام برخی تست‌های عملکرد اضافی، بازسازی جزئی یا سایر پیشرفت‌ها است.

بعد از هر ویژگی اصلی، قطعات کوچک‌تر را تمیز کرده و بازسازی کنید

این قانون فقط زمانی منطقی است که پروژه شما بیش از چند ماه دوام بیاورد. هنگامی که یک ویژگی اصلی را به پایان رساندید، طرز فکر خود را تغییر دهید و با یک دیدگاه بدبینانه تازه به آن بازگردید. تنگناها، اخطارها و مناطقی را برای بهبود پیدا کنید و ارزیابی کنید که چه چیزی ارزش تغییر را دارد و چه زمانی.

یک مثال عالی و ساده زمانی است که شما مجموعه‌ای از توابع را ایجاد می‌کنید که ویژگی‌های یک شی JS صادر شده است. نیازی نیست هر بار کل شی را وارد کنید زیرا تا زمانی که شما مرجعی از آن را نگه می‌دارید مانع از جمع‌آوری زباله داخلی جاوا اسکریپت می‌شود. با تعداد انگشت شماری از عملکردهای خالص، شما باید خوب باشید. با این حال، 70 عملکرد ناخالص را امتحان کنید و آنها را در 6 مکان وارد کنید - برنامه شما به طور قابل توجهی کندتر می شود. در عوض، صادرات نام‌گذاری شده را در فایل‌های کوچک‌تر ایجاد کنید تا خطر حمل ده‌ها هزار خط کد بلااستفاده را کاهش دهید.

از نمونه های اولیه برای آزمایش ویژگی ها استفاده کنید و از بازسازی بی پایان خودداری کنید.

این جایی است که زشت ترین کد غیرقابل نگهداری شما می تواند باشد. یک پروژه نمونه اولیه تک منظوره جداگانه. به عنوان مثال، اگر برای اولین بار با WebRTC کار می کنید، آن را در یک نمونه اولیه انجام دهید. پس از اینکه تأیید کردید که الزامات شما را برآورده می کند، زمان نوشتن کد واقعی فرا می رسد. در این مرحله، باید دید بسیار واضح تری از نحوه ظاهر و رفتار کد خود داشته باشید.
پاداش: چند نکته اضافی

دستورالعمل‌های راه‌اندازی و استقرار اولیه را برای هر پروژه‌ای که روی آن کار می‌کنید، شامل نیازمندی‌ها و نسخه‌های آن‌ها، مستند کنید، و توضیح دهید که چه مراحلی باید به ترتیب انجام شود. در حالت ایده آل نیز چرا.
برنامه خود را بر اساس یک روش ثابت ساختار دهید. می توانید از رویکردهای قدیمی MVC قرض بگیرید، می توانید تقسیم ویژگی ها را امتحان کنید یا چندین رویکرد را ترکیب کنید. هیچ درست یا غلطی وجود ندارد.
از بهترین ابزارهایی که می توانید با پول خود بخرید استفاده کنید. سخت افزاری را خریداری کنید که از استفاده از آن لذت خواهید برد، دفتر خود را تزئین کنید و برای لذت بردن از کار خود پول خرج کنید. به هر حال، شما حدود یک سوم از روز خود را صرف کار خواهید کرد.
اجازه ندهید خود را به ضرب‌الاجل‌های غیرواقعی سوق دهید. اگر محیط کار شما سمی است، اجازه ندهید یک شغل خلاقیت و اشتیاق شما را از بین ببرد. همیشه می توانید به موقعیت دیگری بروید.
نظر خود را بیان کنید و بحث را شروع کنید. ضرب المثل "هیچ سوال احمقانه ای وجود ندارد" را به خاطر دارید؟ پس به پرسیدن و صحبت کردن ادامه دهید. فقط با انجام این کار می توانید افق خود را بسیار گسترش دهید.

این لیست جامع از نکات مربوط به نوشتن کد قابل نگهداری بیشتر است.