https://virgool.io/feed/@hedieh-heydari فرانت‌اند دولوپر | کد تمیز، طراحی دقیق fa 2026-06-16 05:41:39 https://files.virgool.io/upload/users/4778182/avatar/cgiOFT.jpg?height=120&width=120 https://virgool.io/@hedieh-heydari https://virgool.io/@hedieh-heydari/%D9%81%D8%B5%D9%84-%DB%B3-%D8%AF%D8%B4%D9%85%D9%86%D8%A7%D9%86-%DA%A9%D8%AF-%D8%AA%D9%85%DB%8C%D8%B2-wg5c4qrhpkrf تا اینجا فهمیدیم کد تمیز چیه و چه اصولی داره. اما دونستن این اصول به‌تنهایی کافی نیست — باید بدونیم چه چیزایی می‌تونن ما رو از نوشتن کد تمیز باز دارن.این «دشمنان» رو نباید دقیقاً به چشم دشمن ببینید. بهتره بهشون به‌عنوان عواملی نگاه کنید که آروم‌آروم کد تمیز رو تحلیل می‌برن.۱. جاوااسکریپتبدترین ویژگی جاوااسکریپت، همزمان بهترینشه. این زبان به‌شکل عجیبی همه‌جا هست و با سرعت زیادی رشد کرده.جاوااسکریپت خیلی انعطاف‌پذیره — می‌خواید شی‌گرا بنویسید؟ تابعی؟ نمونه‌ای؟ همه رو پوشش می‌ده. همین انعطاف باعث شده ورود بهش آسون باشه، ولی همین انعطاف باعث شده که در هزار جهت مختلف کشیده بشه. امروز با انبوهی از فریم‌ورک‌ها، کتابخانه‌ها، و ابزارهای build مواجهیم و انتخاب «راه درست» تقریباً غیرممکن به نظر می‌رسه.اگه این زبان رو درست به‌کار ببرید، با بیانگری‌اش شگفت‌زده می‌شید. و اگه وقت و تلاش بذارید، می‌تونید باهاش کدی بنویسید که از نظر قابل اطمینان بودن با هر زبان دیگه‌ای برابری کنه.۲. مدیریتکد تمیز فقط به سینتکس مربوط نیست؛ به فرهنگی هم بستگی داره که اون رو پرورش می‌ده. وقتی مدیریت رو «دشمن» می‌نامیم، منظور این نیست که مدیرها مقصرن — مشکل اصلی بعضی رویه‌های فرهنگیه.فشار برای ارسال کدددلاین‌ها از نگاه مدیر منطقی به نظر می‌رسن، ولی از نگاه کسی که روی پروژه کار می‌کنه، اغلب یعنی اجبار به مصالحه. اولین چیزی که قربانی می‌شه، کیفیت کده — مستندات نوشته نمی‌شن، تست‌ها حذف می‌شن، معماری نادیده گرفته می‌شه. نتیجه؟ کد پر از باگ، کاربران ناراضی، و توسعه‌دهندگان فرسوده.راه‌حل اینه که تعادلی معقول بین سرعت ارسال و بدهی تکنیکال برقرار بشه. چند راهکار ساده:بدون تست، هیچ ویژگی یا باگ‌فیکسی ارسال نکنیدبدهی تکنیکال رو به‌طور منظم پرداخت کنید — مثلاً یه بار در هفته همه روی بهبود کدبیس تمرکز کننبا ذینفعان صادقانه ارتباط برقرار کنیدمعیارهای بدیه مدیر غیرفنی ممکنه نگران تعداد خطوط کد یا فیچرهای ارسال‌شده باشه. این معیارها گمراه‌کننده‌ان. یه توسعه‌دهنده ممکنه ده روز وقت بذاره تا یه باگ حیاتی رو با یه خط تغییر حل کنه — آیا این بی‌بهره‌وریه؟قانون گودهارت می‌گه:«وقتی یه معیار به هدف تبدیل می‌شه، دیگه معیار خوبی نیست.»به‌جای شمارش خطوط کد، از توسعه‌دهنده‌ها بپرسید چی سرعت‌شون رو کم کرده. به‌جای شمارش فیچرها، کیفیت و تأثیر هر فیچر روی کاربر رو بسنجید.فقدان مالکیتمالکیت یعنی یه فرد یا تیم احساس مسئولیت واقعی نسبت به بخشی از کد داشته باشه. بدون مالکیت، همه‌چیز آروم‌آروم فرو می‌ریزه. با مالکیت درست، کد پایش می‌شه و با یه چشم‌انداز منسجم رشد می‌کنه.فقط مراقب مالکیت افراطی باشید — غرور بیش از حد می‌تونه به فرهنگی لجوجانه تبدیل بشه.۳. خودماناحساس غرور نسبت به کار، طبیعی و حتی لازمه. اما اگه کنترل نشه، ممکنه به جایی برسیم که کد رو برای تحت‌تأثیر قرار دادن دیگران می‌نویسیم — نه برای اینکه خوانا یا نگهداری‌پذیر باشه.خودنمایی با سینتکسمثلاً برای گرد کردن اعشار به پایین، به‌جای:از عملگر بیتی استفاده می‌کنیم:یا مثال دیگه — استفاده از عملگرهای منطقی به‌جای if:کد یعنی انتقال قصد — و ارتباط خوب به شنونده هم مربوطه، نه فقط گوینده.نظرات لجوجانهوقتی دو نفر از تیم هر کدوم یه ابزار متفاوت رو پیشنهاد می‌دن و هیچ‌کدوم حاضر به انعطاف نیستن، نتیجه یه کدبیس بلاتکلیفه. اگه هر دو از خودمحوری بیرون بیان و دیدگاه دیگری رو واقعاً بشنوند، رسیدن به توافق خیلی ساده‌تره.سندرم ایمپاستراحساس «واقعاً لایق این جایگاه نیستم» در دنیای فناوری خیلی شایعه. این احساس باعث می‌شه در تصمیم‌گیری‌ها تردید کنیم یا نگرانی‌های مهم رو با تیم در میان نذاریم.حقیقت اینه: هیچ‌کس همه‌چیز رو بلد نیست. تنوع دانش اعضای یه تیمه که موفقیت پروژه رو رقم می‌زنه.۴. کارگو کالتدر اوایل قرن بیستم، برخی فرهنگ‌های ملانزی شروع به ساختن باند فرود از چوب و گل کردند — به این امید که هواپیماهای غربی برایشان کالا بیاورند. اشتباهشون اینجا بود که «باند فرود» رو علت رسیدن کالا می‌دونستن، نه وسیله‌ای برای هواپیماها.در برنامه‌نویسی، کارگو کالت یعنی کپی کردن الگوها بدون درک واقعی هدف و عملکردشون.کارگو کالت در کدیه برنامه‌نویس می‌خواد یه route جدید به سرور اضافه کنه. این کد رو توی فایل می‌بینه:و برای route جدیدش اینو می‌نویسه:اشتباه! کد اول یه middleware برای کنترل دسترسی بود. کد درست اینه:خطرناک‌ترین نوع کارگو کالت اینه که وقتی وارد یه کدبیس می‌شیم، ناخودآگاه از الگوهای موجود پیروی می‌کنیم — حتی اگه اشتباه باشن — چون فرض می‌کنیم «حتماً دلیلی داشته.»کارگو کالت در ابزارهاهر ماه یه فریم‌ورک جدید با هیاهوی زیاد معرفی می‌شه. قبل از انتخاب هر ابزار جدید، این سؤال‌ها رو بپرسید:آیا برای این مشکل خاص مناسبه؟آیا درست کار می‌کنه و در آینده هم کار خواهد کرد؟آیا ساده و مستنده؟آیا با کدبیس موجود خوب ادغام می‌شه؟جمع‌بندیکد تمیز فقط یه ویژگی کد نیست — یه فرهنگه که باید هم در سطح سازمان و هم در سطح فردی پرورش داده بشه. جاوااسکریپت، فشارهای مدیریتی، غرور شخصی، و کپی‌کاری کورکورانه — هر کدوم به شکل خودشون می‌تونن این فرهنگ رو تضعیف کنن. Hedieh Hedieh Wed, 03 Jun 2026 15:28:52 +0330 https://virgool.io/@hedieh-heydari/%D9%81%D8%B5%D9%84-%DB%B2-%E2%80%93-%DA%86%D9%87%D8%A7%D8%B1-%D8%A7%D8%B5%D9%84-%DA%A9%D8%AF-%D8%AA%D9%85%DB%8C%D8%B2-i3y56mn99t4p تو فصل قبل گفتیم که کد نوشتن یعنی حل مسئله برای کاربر. حالا می‌خوایم از همین پایه، چهار اصل اساسی رو بسازیم که هر کد خوبی باید داشته باشه:قابل اعتماد بودن کارایی قابل نگهداری بودن قابل استفاده بودن قابل اعتماد بودن (Reliability):یه کد قابل اعتماد سه ویژگی داره: درست، پایدار، و مقاوم.درستی (Correctness) نیازمندی‌های کد باید مستقیماً از نحوه استفاده کاربر بیان. اول کاربر و مسئله‌اش رو بشناس، بعد از روی اون‌ها نیازمندی‌هایی تعریف کن که بشه مستقلاً تستشون کرد.پایداری (Stability) پایداری یعنی کد در شرایط مختلف و با ورودی‌های متفاوت، همچنان درست کار کنه. جاوااسکریپت توی مرورگر خیلی در معرض این مشکله — چون روی سخت‌افزارها، سیستم‌عامل‌ها، و مرورگرهای مختلف اجرا میشه. بهترین راه تأیید پایداری، نوشتن تست‌هاییه که کد رو در معرض طیف کامل ورودی‌ها قرار بده.مقاومت (Resilience) پایداری بیشتر با ورودی‌های مورد انتظار سر و کار داره، اما مقاومت اینجاست که می‌پرسه: اگه یه اتفاق غیرمنتظره افتاد چی؟مثال خوبش اینه: فرض کن می‌خوای یه فایل MP3 پخش کنی. قبل از اینکه این کارو بکنی، چک کن که مرورگر اصلاً از MP3 پشتیبانی می‌کنه یا نه اگه مرورگر پشتیبانی نکرد، به‌جای اینکه کد بی‌سروصدا خراب بشه، یه مسیر جایگزین فعال میشه — مثل نمایش متن صوتی. بهش میگن graceful degradation یا تخریب ظریف.نکته جالب: وقتی برای شرایط غیرمنتظره آماده میشی، عملاً اون‌ها رو به بخشی از رفتار عادی کدت تبدیل می‌کنی. این یعنی مقاومت به پایداری تبدیل میشه. کارایی (Efficiency)منابع محدودن — وقت و فضا هر دو.زمان: کد باید CPU رو بی‌دلیل مشغول نکنه. ولی مراقب بهینه‌سازی‌های جزئی (micro-optimization) باش — اول اندازه بگیر، بعد روی گلوگاه‌های واقعی کار کن.فضا: داده‌ها روی شبکه جابجا میشن، توی RAM موقتاً نگه داشته میشن، و احتمالاً روی دیسک ذخیره میشن. هدف اینه که فقط فضای لازم رو استفاده کنی و داده رو فقط وقتی که واقعاً لازمه جابجا کنی.زمان و فضا با هم در هم تنیده‌ان — بهینه‌سازی یکی معمولاً روی دیگری هم اثر داره. اصل کلی: فقط کاری که لازمه رو انجام بده، اسراف نکن. قابل نگهداری بودن (Maintainability)کد مثل ماشین نیست که بدون نگهداری زنگ بزنه، ولی بالاخره باید تغییر کنه — باگ‌ها رفع بشن، فیچرها اضافه بشن، و اغلب توسط آدم‌های مختلف. اون‌هایی که روی کد ما کار می‌کنن هم کاربر ما هستن — پس باید بهشون فکر کنیم.سازگاری (Adaptability) بهترین نگهداری اونیه که اصلاً لازم نشه انجام بشه. ولی وقتی تغییر لازمه، دو دشمن اصلی داریم:شکنندگی (Fragility): یه تغییر کوچیک، جاهای به‌ظاهر نامرتبط رو خراب می‌کنه.سختی (Rigidity): برای یه تغییر ساده، باید همه‌جا رو دستکاری کنی.راه‌حل هر دو: ماژولار کردن کد — جدا کردن مسئولیت‌ها به بخش‌های مستقل که کمتر به هم وابسته باشن.آشنایی (Familiarity) کدی که با الگوهای آشنا و قراردادهای رایج نوشته شده، خیلی راحت‌تر فهمیده میشه. بیشتر اپ‌های وب مفاهیم مشترکی دارن — ثبت‌نام، ورود، CRUD — پس نوشتن کد آشنا کار سختی نیست. قابل استفاده بودن (Usability)قابل استفاده بودن یعنی کد و چیزی که ارائه میده، برای همه کاربران — چه کاربر نهایی، چه برنامه‌نویس دیگه — تا جای ممکن ساده و راحت باشه.User Story یه تکنیک مفید برای تعریف کاربردها اینه:به‌عنوان یه {کاربر}، می‌خوام {فلان کار} رو انجام بدم تا {فلان هدف} رو برسم.مثال برای یه اپ مخاطبین:به‌عنوان کاربر، می‌خوام مخاطب جدید اضافه کنم تا بعداً بتونم پیداش کنم.به‌عنوان کاربر، می‌خوام مخاطب رو با فامیلی پیدا کنم تا باهاش تماس بگیرم.طراحی بدیهی (Intuitive Design) کد خوب نباید نیاز به توضیح داشته باشه. مثال‌هایی از الگوهای بدیهی:تابعی که با is شروع میشه، مقدار بولین برمیگردونه.ثابت‌ها با حروف بزرگ نوشته میشن: MAX_SIZEدکمه X یعنی بستندسترس‌پذیری (Accessibility) کاربرها یه جور نیستن. بعضی‌ها مشکلات بینایی دارن، بعضی‌ها روی سخت‌افزار قدیمی کار می‌کنن، بعضی‌ها اختلال یادگیری دارن — و این فقط شامل کاربر نهایی نیست، برنامه‌نویس‌ها هم همینطور. باید برای همه فکر کرد.اگه همه این اصول پیچیده به نظر میان، یه قانون ساده همه رو جمع می‌کنه:همیشه روی کاربر تمرکز کن — همه کاربرها. Hedieh Hedieh Sat, 23 May 2026 22:01:41 +0330 https://virgool.io/@hedieh-heydari/%D9%81%D8%B5%D9%84-%DB%B1-%E2%80%93-%D8%A8%D8%AE%D8%B4-%DB%B1-%DA%86%DB%8C%D8%AF%D9%86-%D8%B5%D9%81%D8%AD%D9%87-i9sifbampqg7 مدتیه که دارم کتاب Clean Code in JavaScript رو می‌خونم و تصمیم گرفتم مفاهیمش رو به شکل خلاصه و کاربردی اینجا مرور کنم. تمرکزم روی نکاتیه که واقعاً در عمل به کار میان — نه توضیحات آکادمیک اضافه. این اولین بخشه.جاوااسکریپت از کجا اومد؟جاوااسکریپت رو برندن ایچ در ۱۹۹۵ ساخت. هدف اولیه‌اش ساده بود: یه «زبان چسبنده» که به طراحان وب کمک کنه صفحات HTML رو راحت‌تر دستکاری کنن. این دستکاری از طریق DOM API انجام می‌شه.کمی بعدتر مفهوم DHTML هم مطرح شد که امکاناتی مثل انیمیشن و اعتبارسنجی ورودی رو فراهم کرد. در اون سال کمتر کسی فکر می‌کرد این زبان روزی برای ساخت اپ‌های پیچیده وب یا حتی Node.js استفاده بشه.DHTMLدر ۱۹۹۷ هم جاوااسکریپت توسط سازمان Ecma استانداردسازی شد و با نام ECMAScript شناخته شد. این استاندارد هنوزم توسط کمیته TC39 توسعه پیدا می‌کنه و نسخه‌هاش بر اساس سال نام‌گذاری میشن — مثل ES2020.چرا اصلاً کد می‌نویسیم؟کدنویسی در اصل حل مسئله‌ست. وقتی کد می‌نویسیم داریم یه مسئله پیچیده رو به مجموعه‌ای از مراحل ساده تبدیل می‌کنیم تا کاربر بتونه ازش استفاده کنه.یه نکته مهم اینه که «کاربر» لزوماً کاربر نهایی UI نیست — ممکنه برنامه‌نویس دیگه‌ای باشه که از کد ما استفاده می‌کنه. در هر صورت، کاربر مرکز همه تصمیم‌گیری‌های ماست.مثال کوچیک: فرض کن داری یه تابع برای اعتبارسنجی کد پستی می‌نویسی. اگه مشخص نکنی این کد برای کدوم کشوره، مشکل داری — چون کد پستی آمریکا فقط عددیه، ولی انگلستان شامل حروف هم میشه.اول مسئله رو بشناستا وقتی دقیق ندونی داری چه مسئله‌ای رو حل می‌کنی، پیشرفتی نخواهی داشت. شناخت درست مسئله اولین قدم برای تعریف نیازمندی‌هاست.برای فهمیدن بهتر مسئله می‌تونی از این سؤال‌ها کمک بگیری:کاربر با چه مشکلاتی روبروئه؟الان چطور اون‌ها رو حل می‌کنه؟چه راه‌حل‌هایی وجود داره و هرکدوم چطور کار می‌کنن؟مدل مسئله چیه؟مدل (یا مدل انتزاعی) یه نمای ساده‌شده از واقعیته که توضیح می‌ده یه سیستم چطور کار می‌کنه. ما همیشه در حال ساختن مدل هستیم — و هرچی اطلاعات بیشتری به‌دست بیاریم، مدلمون به واقعیت نزدیک‌تر میشه.کد برای انسان‌ها نوشته میشهیه چیزی که این فصل روش تأکید می‌کنه اینه: درست کار کردن کد کافی نیست. خوانایی و قابل فهم بودنش هم به همون اندازه مهمه.bad codeclean codeاین مفهوم مستقیماً به انتزاع (Abstraction) می‌رسه — وقتی بخشی از پیچیدگی رو پنهان می‌کنیم و یه رابط ساده‌تر ارائه می‌دیم. انتزاع معنادار یعنی دیگران بتونن بدون اینکه لازم باشه جزئیات رو بدونن، از اون بخش استفاده کنن. این یکی از پایه‌های اصلی فناوری مدرنه.abstraction Hedieh Hedieh Sat, 09 May 2026 16:10:26 +0330 https://virgool.io/@hedieh-heydari/clean-code-in-javascript-kgechhvxlo9v مقدمهمدتی بود که موقع کار با جاوااسکریپت، بیشتر از قبل به خوانایی و تمیزی کد اهمیت می‌دادم و همین باعث شد سراغ کتاب Clean Code in JavaScript برم.در این مجموعه، قراره مفاهیم و اصول مهم این کتاب رو به شکل خلاصه و کاربردی مرور کنم. تمرکزم بیشتر روی نکاتیه که به نظرم در عمل کمک می‌کنن کدهای خواناتر و قابل نگهداری‌تری بنویسیم.سعی کردم هر بخش رو بدون ورود به جزئیات اضافی و به صورت مرحله‌به‌مرحله بنویسم، طوری که هم برای یادگیری اولیه مفید باشه و هم برای مرور سریع. Hedieh Hedieh Wed, 22 Apr 2026 16:35:28 +0330