ساخت یک NPM Package شاید با یک npm publish ساده به نظر بیاد؛ ولی اگر بخوای Package حرفه‌ای منتشر کنی، داستان خیلی بزرگ‌تره.
این راهنما مراحل ساخت یک NPM Package رو بررسی می‌کنه، مقاله خوبیه بنظرم، برای باز کردن ذهنتون درموردش.
🔗 Link
@programming_codiing
این راهنما مراحل ساخت یک NPM Package رو بررسی می‌کنه، مقاله خوبیه بنظرم، برای باز کردن ذهنتون درموردش.
🔗 Link
@programming_codiing
❤4🔥2
نکست جی‌اس و پروژه‌های فول‌استکی؟
اصلاً پروژه Full-Stack ای یعنی چی و Next.js چه کمکی به ساخت این پروژه‌ها می‌کنه؟
مزیتش هم اینه که:
در واقع اگر هدفت فقط ساخت چند صفحه ساده نیست و می‌خوای پروژه‌هایی بسازی که واقعاً کار کنن، یادگیری Next.js در کنار مفاهیم Full-Stack می‌تونه انتخاب خیلی خوبی باشه.
@programming_codiing
اصلاً پروژه Full-Stack ای یعنی چی و Next.js چه کمکی به ساخت این پروژه‌ها می‌کنه؟
وقتی می‌گیم یک پروژه Full-Stack هست، یعنی فقط ظاهر سایت رو نمی‌سازیم؛ بلکه بخش‌هایی که پشت سایت اتفاق می‌افتن رو هم خودمون پیاده‌سازی می‌کنیم.
مثلاً یک فروشگاه اینترنتی رو در نظر بگیر:
صفحه محصولات، طراحی سایت و دکمه‌ها یک بخش ماجراست؛
اما ثبت‌نام کاربر، ورود، ذخیره اطلاعات، سبد خرید و ثبت سفارش هم باید جایی مدیریت بشن.
اینجاست که مفهوم Full-Stack خودش رو نشون می‌ده.
نکست جی اس یکی از گزینه‌های محبوب برای ساخت چنین پروژه‌هاییه؛ چون می‌تونی باهاش بخش‌های مختلف یک پروژه رو در کنار هم داشته باشی و لازم نباشه برای هر قسمت حتماً یک پروژه جدا بسازی.
مزیتش هم اینه که:
• توسعه پروژه راحت‌تر و یکپارچه‌تر می‌شه
• سرعت ساخت پروژه بالاتر می‌ره
• می‌تونی پروژه‌های واقعی‌تر و کامل‌تری بسازی
• برای سایت‌های بزرگ و کوچک قابل استفاده‌ست
• امکانات خوبی برای سرعت و سئو داره
در واقع اگر هدفت فقط ساخت چند صفحه ساده نیست و می‌خوای پروژه‌هایی بسازی که واقعاً کار کنن، یادگیری Next.js در کنار مفاهیم Full-Stack می‌تونه انتخاب خیلی خوبی باشه.
@programming_codiing
❤10🔥1
تکنولوژی‌ها ادعا هستن؛ پروژه‌ها مدرک.
چیزیه که توی برسی رزومه‌تون بیشتر خواهید دید.
@programming_codiing
چیزیه که توی برسی رزومه‌تون بیشتر خواهید دید.
@programming_codiing
❤18👍4💯2
احتمالاً عبارت Design Pattern رو بارها شنیدید؛
مخصوصاً اگه با React، JavaScript یا توسعه نرم‌افزار کار کرده باشید.
اما واقعاً Design Pattern چیه؟
پس Design Pattern بیشتر از اینکه یک سری کد آماده باشه، راهی برای فکر کردن و طراحی بهتر نرم‌افزاره.
@programming_codiing
مخصوصاً اگه با React، JavaScript یا توسعه نرم‌افزار کار کرده باشید.
اما واقعاً Design Pattern چیه؟
دیزاین پترن یعنی یک راه‌حلِ از قبل شناخته‌شده برای یک مسئله‌ی رایج در طراحی نرم‌افزارِ.
قرار نیست دیزاین پترن یک تکه کد آماده باشه که کپی کنیم و داخل پروژه بذاریم،
در واقع، یک الگوی فکری و طراحیه که بهمون می‌گه برای حل یک مشکل تکراری، معمولاً چه ساختاری می‌تونه مناسب باشه.
مثلاً فرض کنید در چند جای پروژه به یک منطق مشترک نیاز دارید. به جای اینکه هر بار همون منطق رو دوباره بنویسید، می‌تونید از یک الگوی مناسب استفاده کنید تا کد:
• قابل نگهداری‌تر باشه
• ساختار بهتری داشته باشه
• راحت‌تر توسعه پیدا کنه
• وابستگی‌های غیرضروری کمتر بشن
دیزاین پترن ها معمولاً در چند دسته معروف قرار می‌گیرن که می تونید برای هر کدوم تحقیقی کنید.
نکته مهم اینه که استفاده ازش به معنی هر جا تونستی Pattern استفاده کن نیست،
در واقع اگه یک Pattern مشکل پروژه رو حل نکنه، فقط باعث پیچیده‌تر شدن کد می‌شه، این در واقع همه‌جا صدق می کنه که اگر یه چیزی برای حل پيچيدگی پروژه بزرگی هست می تونه عامل خود پیچیدگی پروژه کوچیک هم باشه.
پس Design Pattern بیشتر از اینکه یک سری کد آماده باشه، راهی برای فکر کردن و طراحی بهتر نرم‌افزاره.
@programming_codiing
❤5✍2
</ MoDev >
چرا زبان انگلیسی کلید طلایی برنامه‌نویسیه؟ یکی از بزرگ‌ترین دغدغه‌هایی که خیلیا موقع ورود به دنیای برنامه‌نویسی دارن اینه: «من زبان انگلیسیم خوب نیست، یعنی نمی‌تونم برنامه‌نویس بشم؟» پاسخ کوتاه و روشن: چرا که نه! بلد نبودن زبان انگلیسی اصلاً دلیلی برای…
به عنوان یه برنامه‌نویس
بنده از بالا نبودن سطح زبان انگلیسیم رنج می برم، البته که می تونستم از اول کار خودمو تقویت کنم ولی الان دارم انجامش می دم.
پیشنهادم اینه که برید کلاس زبان، چون واقعا تاثیرش خوبه تو یادگیری ولی اگه شرایطش رو ندارید، دوره زبان احمدیان رو ببینید یا هم یوتیوب پر از دوره هست که یکم بگردید پیدا می کنید و وقتی شروع کردید استمرار داشته باشید تا نتیجه بگیرید.
هر چی زبانتون خوب باشه دستتون بالاتره تو برنامه نویسی، جدی بگیریدش برا خودتون.❤️
@programming_codiing
بنده از بالا نبودن سطح زبان انگلیسیم رنج می برم، البته که می تونستم از اول کار خودمو تقویت کنم ولی الان دارم انجامش می دم.
پیشنهادم اینه که برید کلاس زبان، چون واقعا تاثیرش خوبه تو یادگیری ولی اگه شرایطش رو ندارید، دوره زبان احمدیان رو ببینید یا هم یوتیوب پر از دوره هست که یکم بگردید پیدا می کنید و وقتی شروع کردید استمرار داشته باشید تا نتیجه بگیرید.
هر چی زبانتون خوب باشه دستتون بالاتره تو برنامه نویسی، جدی بگیریدش برا خودتون.❤️
@programming_codiing
👍16❤8
هرچی بیشتر برنامه‌نویسی می‌کنی، بیشتر می‌فهمی که ننوشتن کد هم یه مهارته.
اگه می‌تونی با تغییر ساختار پروژه، حذف یه وابستگی یا ساده‌تر کردن معماری، ۲۰۰ خط کد اضافه رو ننویسی، احتمالا تصمیم بهتری گرفتی.
کد کمتر همیشه بهتر نیست؛
ولی کد غیرضروری تقریباً همیشه بَده.
@programming_codiing
اگه می‌تونی با تغییر ساختار پروژه، حذف یه وابستگی یا ساده‌تر کردن معماری، ۲۰۰ خط کد اضافه رو ننویسی، احتمالا تصمیم بهتری گرفتی.
کد کمتر همیشه بهتر نیست؛
ولی کد غیرضروری تقریباً همیشه بَده.
@programming_codiing
❤17👍4
چرا Dark Mode همیشه جواب نیست؟
🔗 Link
@programming_codiing
دارک مود فقط قشنگ کردن ظاهر نیست؛ مستقیم روی خوانایی، کنتراست و فشار به چشم تأثیر می‌ذاره.
سیاه کردنِ ساده‌ی پس‌زمینه کافی نیست! و حالت دارک فقط به معنی این که white رو به black تبدیل کنیم نیست، رنگ متن، کنتراست دقیق و حتی نور محیط کاربر تعیین‌کننده‌ست.
پس سؤال اصلی این نیست که:
دارک مود قشنگ‌تره؟
بلکه اینه:
در این نوع سایتی که دارم آیا برای کاربر بهتره؟
توی این مقاله می تونه سوال هایی که ممکنه براتون پیش بیاد نوشته شده، می تونید یه سرچ ساده هم کنید و بقیه مقاله های مرتبط رو مطالعه کنيد.
🔗 Link
@programming_codiing
❤7✍2
اگه همیشه موقع کدنویسی موسیقی گوش می‌دید، یه بار بدونش کدنویسی کنید.
نه برای Productivity.
برای اینکه ببینید واقعاً می‌تونید چند دقیقه بدون حواس‌پرتی روی یه مسئله تمرکز کنید یا نه.
خیلی وقت‌ها مشکل ما کمبود زمان نیست،
تکه‌تکه شدن توجه‌مونه.
@programming_codiing
نه برای Productivity.
برای اینکه ببینید واقعاً می‌تونید چند دقیقه بدون حواس‌پرتی روی یه مسئله تمرکز کنید یا نه.
خیلی وقت‌ها مشکل ما کمبود زمان نیست،
تکه‌تکه شدن توجه‌مونه.
پ.ن: موسیقی گوش بدین، عشقه :))
@programming_codiing
❤12😁4🤔1
هر چیزی که می‌تونید با npm install نصب کنید، لزوماً نباید نصبش کنید.
قبل از اضافه کردن یه پکیج به پروژه، چندتا سؤال ساده بپرسید:
واقعاً بهش نیاز دارم؟
خودم می‌تونم با چند خط کد حلش کنم؟
چقدر Maintenance داره؟
چقدر استفاده می‌شه؟
حجمش چقدره؟
یه Dependency جدید فقط چند خط کد به پروژه اضافه نمی‌کنه، یه تکه از مسئولیت پروژه رو هم بهتون اضافه می‌کنه.
می تونم بگم یه پروژه م به خاطر اینکه هر چی جلوم میومد نصب می کردم به پایان نرسید.
@programming_codiing
قبل از اضافه کردن یه پکیج به پروژه، چندتا سؤال ساده بپرسید:
واقعاً بهش نیاز دارم؟
خودم می‌تونم با چند خط کد حلش کنم؟
چقدر Maintenance داره؟
چقدر استفاده می‌شه؟
حجمش چقدره؟
یه Dependency جدید فقط چند خط کد به پروژه اضافه نمی‌کنه، یه تکه از مسئولیت پروژه رو هم بهتون اضافه می‌کنه.
می تونم بگم یه پروژه م به خاطر اینکه هر چی جلوم میومد نصب می کردم به پایان نرسید.
@programming_codiing
❤4👍2✍1
</ MoDev >
به عنوان یه برنامه‌نویس بنده از بالا نبودن سطح زبان انگلیسیم رنج می برم، البته که می تونستم از اول کار خودمو تقویت کنم ولی الان دارم انجامش می دم. پیشنهادم اینه که برید کلاس زبان، چون واقعا تاثیرش خوبه تو یادگیری ولی اگه شرایطش رو ندارید، دوره زبان احمدیان…
کتابم بخونید
بنظرم تو برنامه‌تون به اندازه ای که به زبان اهمیت می دین به کتاب خوندن هم اهمیت بدید.
متاسفانه خیلی ها بیخیالن ...
@programming_codiing
بنظرم تو برنامه‌تون به اندازه ای که به زبان اهمیت می دین به کتاب خوندن هم اهمیت بدید.
متاسفانه خیلی ها بیخیالن ...
@programming_codiing
1❤11❤🔥3🫡1
احتمالاً موقع نصب یه پکیج دیدید که نسخه‌ش مثلاً اینه: 3.7.2
ولی این سه تا عدد دقیقاً چی می‌گن؟
این سیستم اسمش Semantic Versioning یا SemVerـه و شکل کلیش اینه :
MAJOR.MINOR.PATCH
خلاصه:
@programming_codiing
ولی این سه تا عدد دقیقاً چی می‌گن؟
این سیستم اسمش Semantic Versioning یا SemVerـه و شکل کلیش اینه :
MAJOR.MINOR.PATCH
مثلاً:
3.7.2
یعنی:
3 → MAJOR
7 → MINOR
2 → PATCH
حالا قسمت جذابش اینجاست
MAJOR — تغییرات بزرگ و Breaking
وقتی نسخه Major تغییر می‌کنه، ممکنه چیزهایی که قبلاً توی پروژه‌ات کار می‌کردن، دیگه کار نکنن.
مثلاً:
2.4.1 → 3.0.0
فرض کن قبلاً این API رو داشتی:
getUser(id)
ولی توی نسخه جدید تبدیل شده به:
getUser({ id })
کدت ممکنه بشکنه؛ چون API قبلی تغییر کرده.
پس:
Major = احتمال Breaking Change
MINOR — قابلیت جدید، بدون شکستن قبلی‌ها
مثلاً:
3.7.2 → 3.8.0
یک قابلیت جدید اضافه شده، ولی قرار نیست قابلیت‌های قبلی خراب بشن.
مثلاً:
getUser()
همچنان کار می‌کنه و فقط قابلیت جدیدی مثل:
getUsers()
اضافه شده.
پس:
Minor = Feature جدید + سازگاری با قبلی
PATCH — رفع باگ
مثلاً:
3.7.2 → 3.7.3
اینجا معمولاً قابلیت جدیدی اضافه نشده؛ فقط باگ‌ها و مشکلات نسخه قبلی برطرف شدن.
مثلاً:
نسخه قبلی:
calculateTotal()
گاهی مبلغ اشتباه برمی‌گردوند.
در نسخه جدید این باگ Fix شده.
پس:
Patch = Bug Fix
حالا یه مثال واقعی‌تر
فرض کن نسخه پکیجت اینه:
1.4.2
بعد:
1.4.3 → یک باگ Fix شده.
1.5.0 → یک قابلیت جدید اضافه شده.
2.0.0 → تغییر بزرگی اتفاق افتاده که ممکنه نیاز به تغییر کدت داشته باشه.
پس فقط با نگاه کردن به نسخه می‌تونی بفهمی تقریباً چه نوع تغییری اتفاق افتاده.
اما یه نکته مهم درباره npm
وقتی توی package.json می‌نویسی:
"react": "^19.0.0"
این ^ مهمه.
یا مثلاً:
"lodash": "~4.17.21"
این علامت‌ها مشخص می‌کنن چه نسخه‌هایی اجازه دارن نصب بشن.
به زبان ساده:
^ → معمولاً Minor و Patch را اجازه می‌دهد.
~ → معمولاً فقط Patch را اجازه می‌دهد.
مثلاً:
^1.4.2
1.4.3 ✅
1.5.0 ✅
1.9.9 ✅
2.0.0 ❌
و:
~1.4.2
1.4.3 ✅
1.4.9 ✅
1.5.0 ❌
خلاصه:
1.4.2
│ │ │
│ │ └── PATCH → رفع باگ
│ └──── MINOR → قابلیت جدید
└────── MAJOR → تغییرات ناسازگار
@programming_codiing
❤9
به بک اند هم پا گذاشتم
می تونم بگم کارت از فرانت راحتره در اکثر پروژه ها
واقعا دوست داشتنیه و لذت بخشه، اما دیگه مثل فرانت اند خبری از رنگ و این چیزا نیست، کارت با منطق، ساختار و داده‌هاست.
و الان دغدغه‌ی مهمم نبود پروژه های خوبی برا رزومه خودم هست، روزمه ای که پروژه هاش با تکنولوژی هاش بهم نمی خورن و این وافعا خوب نیست چون وقت نکردم خیلی پروژه بزنم.
رزومه و پورتفولیوم رو بعد از تکمیل، نشونتون می دم. 💙
می تونم بگم کارت از فرانت راحتره در اکثر پروژه ها
واقعا دوست داشتنیه و لذت بخشه، اما دیگه مثل فرانت اند خبری از رنگ و این چیزا نیست، کارت با منطق، ساختار و داده‌هاست.
و الان دغدغه‌ی مهمم نبود پروژه های خوبی برا رزومه خودم هست، روزمه ای که پروژه هاش با تکنولوژی هاش بهم نمی خورن و این وافعا خوب نیست چون وقت نکردم خیلی پروژه بزنم.
رزومه و پورتفولیوم رو بعد از تکمیل، نشونتون می دم. 💙
❤15❤🔥5
یه ابزار کاربردی برای وقتی که می‌خواید localhost رو موقتاً روی اینترنت در دسترس قرار بدید.
با
برای تست Webhook هم می تونه کاربردی باشه.
🔗 https://ngrok.com
@programming_codiing
با
ngrok می‌تونید پروژه‌تون رو با یه Public URL در اختیار بقیه قرار بدید؛ بدون نیاز به Deploy یا تغییر تنظیمات پروژه.برای تست Webhook هم می تونه کاربردی باشه.
🔗 https://ngrok.com
@programming_codiing
❤6
یه سایت خیلی خفن برای یادگیری Git.
گیت رو به شکل Interactive یاد می‌گیرید و می‌تونید Branch، Merge، Rebase و بقیه دستورات رو با محیط گرافیکی تمرین کنید.
به‌جای اینکه فقط دستورها رو حفظ کنید، نتیجه‌شون رو می‌بینید و می تونه براتون جالب باشه برای یادگیری.
🔗 Link
@programming_codiing
گیت رو به شکل Interactive یاد می‌گیرید و می‌تونید Branch، Merge، Rebase و بقیه دستورات رو با محیط گرافیکی تمرین کنید.
به‌جای اینکه فقط دستورها رو حفظ کنید، نتیجه‌شون رو می‌بینید و می تونه براتون جالب باشه برای یادگیری.
🔗 Link
@programming_codiing
❤9
آدمی که عاشق مسیر هست از آدمی که عاشق مقصد هست جلوتر خواهد رفت.
تقریبا درسته
چون ما توی شروعمون یا توی مسیرمون به این بر می خوریم که چرا به درآمد خب نمی رسیم و ناامیدمون می کنه
و بهترین کار اینه که با علاقه مسیر رو ادامه بدی و به درامد هم فکر کنی ولی نه به این صورت که چرا نمی تونم فلان رو کنم و..
بهتره از این نظر نگاه کنی که من با سطح خودم چی کار می تونم بکنم یا برای چیزی که می خوام به چه سطحی نیاز دارم، در واقع به فکر درآمد بودن از اول می تونه خلاقیتت رو هم استارتش رو بزنه ولی با دیدگاه درست که اگه فکر می کنی دیدگاه درستی نداری و بیشتر فکر کردن درباره درآمد استرس هم می ده بهتره فقط از مسیر لذت ببری و به چیز دیگه ای فکر نکنی.
و یه چیز دیگه ام که باید ول کنی مقایسه س. مقایسه نمی گم بد هست در واقع خیلی هم خوبه ولی مقایسه خودت با خود دیروزت، نه مقایسه خودت با یکی دیگه که شرایطش حالا هر چی هست.
@programming_codiing
تقریبا درسته
چون ما توی شروعمون یا توی مسیرمون به این بر می خوریم که چرا به درآمد خب نمی رسیم و ناامیدمون می کنه
و بهترین کار اینه که با علاقه مسیر رو ادامه بدی و به درامد هم فکر کنی ولی نه به این صورت که چرا نمی تونم فلان رو کنم و..
بهتره از این نظر نگاه کنی که من با سطح خودم چی کار می تونم بکنم یا برای چیزی که می خوام به چه سطحی نیاز دارم، در واقع به فکر درآمد بودن از اول می تونه خلاقیتت رو هم استارتش رو بزنه ولی با دیدگاه درست که اگه فکر می کنی دیدگاه درستی نداری و بیشتر فکر کردن درباره درآمد استرس هم می ده بهتره فقط از مسیر لذت ببری و به چیز دیگه ای فکر نکنی.
و یه چیز دیگه ام که باید ول کنی مقایسه س. مقایسه نمی گم بد هست در واقع خیلی هم خوبه ولی مقایسه خودت با خود دیروزت، نه مقایسه خودت با یکی دیگه که شرایطش حالا هر چی هست.
@programming_codiing
❤16
اگه یه JSON شلوغ دارید و می‌خواید سریع Format / Validate / Minifyش کنید:
🔗 https://jsonformatter.org
برای کارهای سریع خیلی راحت‌تر از اینه که بخواید هر بار یه ابزار نصب کنید.
@programming_codiing
🔗 https://jsonformatter.org
برای کارهای سریع خیلی راحت‌تر از اینه که بخواید هر بار یه ابزار نصب کنید.
@programming_codiing
❤7
با قابلیت‌هایی که الان یوتیوب داره، تقریباً می‌شه گفت دانشگاه بودنش ثابت شده. هر چیزی که فکرشو بکنی، از برنامه‌نویسی و طراحی و زبان گرفته تا ریاضی و پزشکی و کسب‌وکار، دوره‌ی کامل و منظمش اونجا هست و خیلی وقتا هم استادهای اصلی دانشگاه‌های بزرگ دنیا خودشون درس‌هاشونو آپلود کردن. دوره‌های خارجی رو هم دیگه دلیلی نداره نگاه نکنیم، چون ترجمه‌ی آنلاین یوتیوب کارمون رو راه می‌ندازه. شاید ترجمه‌اش بی‌نقص نباشه، مخصوصاً تو اصطلاحات تخصصی، ولی برای فهمیدن مطلب کاملاً کافیه و هر روز هم داره بهتر می‌شه.
از یه زاویه‌ی متفاوت‌تر هم اگه نگاه کنیم، تولید محتوا هم همین مزیت رو داره. چون با همین ترجمه، هر کسی با هر زبانی می‌تونه محتوای شما رو دنبال کنه و مخاطبتون محدود به یه کشور و یه زبون نمی‌مونه. یعنی ممکنه کسی اون طرف دنیا ویدیوی شما رو ببینه و ازش استفاده کنه، بدون اینکه یه کلمه فارسی بلد باشه. البته به شرطی که محتوا خوب باشه و متفاوت باشه، چون وقتی مخاطب جهانی می‌شه، رقیب هم جهانی می‌شه و محتوای معمولی خیلی راحت بین میلیون‌ها ویدیو گم می‌شه. و اینم خیلی مهم نیست چون همین ممبرای فارسی زبان رو دلشونو ببری اوکیه.
اگه هم تو تولید محتوا فقط کاری رو دنبال کنید که بقیه انجام می‌دن، در بهترین حالت هم‌سطح بقیه می‌مونید. اگه کارتون خیلی خوب باشه، شاید از بقیه یه کم بالاتر برید. ولی اگه متفاوت‌تر تولید کنید، یعنی زاویه‌ی خودتون، تجربه‌ی خودتون و سبک خودتون رو داشته باشید، قطعاً نتیجه‌ی خیلی بهتری می‌گیرید، چون تفاوت چیزیه که دیگران نمی‌تونن راحت ازتون کپی کنن و مردم به دنبال تفاوت هستند.
پ.ن : سعی می کنم این پست رو ادامه بدم. "تولید محتوا"
@programming_codiing
از یه زاویه‌ی متفاوت‌تر هم اگه نگاه کنیم، تولید محتوا هم همین مزیت رو داره. چون با همین ترجمه، هر کسی با هر زبانی می‌تونه محتوای شما رو دنبال کنه و مخاطبتون محدود به یه کشور و یه زبون نمی‌مونه. یعنی ممکنه کسی اون طرف دنیا ویدیوی شما رو ببینه و ازش استفاده کنه، بدون اینکه یه کلمه فارسی بلد باشه. البته به شرطی که محتوا خوب باشه و متفاوت باشه، چون وقتی مخاطب جهانی می‌شه، رقیب هم جهانی می‌شه و محتوای معمولی خیلی راحت بین میلیون‌ها ویدیو گم می‌شه. و اینم خیلی مهم نیست چون همین ممبرای فارسی زبان رو دلشونو ببری اوکیه.
اگه هم تو تولید محتوا فقط کاری رو دنبال کنید که بقیه انجام می‌دن، در بهترین حالت هم‌سطح بقیه می‌مونید. اگه کارتون خیلی خوب باشه، شاید از بقیه یه کم بالاتر برید. ولی اگه متفاوت‌تر تولید کنید، یعنی زاویه‌ی خودتون، تجربه‌ی خودتون و سبک خودتون رو داشته باشید، قطعاً نتیجه‌ی خیلی بهتری می‌گیرید، چون تفاوت چیزیه که دیگران نمی‌تونن راحت ازتون کپی کنن و مردم به دنبال تفاوت هستند.
پ.ن : سعی می کنم این پست رو ادامه بدم. "تولید محتوا"
@programming_codiing
👏11❤3⚡1
قبل از کدنویسی، ساختار پروژه رو بچین.
اگه از همون اول ساختار پروژه مشخص باشه، با بزرگ شدن پروژه خیلی کمتر با فایل‌های درهم‌ریخته مواجه می‌شیم.
مثلاً برای پروژه‌های Next.js / React می‌تونیم از چنین ساختاری شروع کنیم:
این فقط یک الگوئه ابتدایی هست و می تونه برای خیلی از پروژه ها اوکی باشه ولی ساختار مناسب هر پروژه به اندازه و نوع پروژه بستگی داره.
و برای اینکه هر بار این پوشه‌ها رو دستی نسازید، از AI بخواید دستور ساختش رو براتون بنویسه:
@programming_codiing
اگه از همون اول ساختار پروژه مشخص باشه، با بزرگ شدن پروژه خیلی کمتر با فایل‌های درهم‌ریخته مواجه می‌شیم.
مثلاً برای پروژه‌های Next.js / React می‌تونیم از چنین ساختاری شروع کنیم:
project/
├── app/
│ ├── _components/
│ ├── _constants/
│ ├── _hooks/
│ ├── _lib/
│ ├── _services/
│ ├── _types/
│ ├── _utils/
│ │
│ └── test/
│ ├── _components/
│ │ ├── TestHeader.tsx
│ │ └── TestCard.tsx
│ ├── _constants/
│ │ └── test.constants.ts
│ ├── _hooks/
│ │ └── useTest.ts
│ ├── _lib/
│ │ └── test.lib.ts
│ ├── _services/
│ │ └── test.service.ts
│ ├── _types/
│ │ └── test.types.ts
│ ├── _utils/
│ │ └── test.utils.ts
│ └── page.tsx
│
├── public/
│ ├── fonts/
│ └── images/
│
این فقط یک الگوئه ابتدایی هست و می تونه برای خیلی از پروژه ها اوکی باشه ولی ساختار مناسب هر پروژه به اندازه و نوع پروژه بستگی داره.
و برای اینکه هر بار این پوشه‌ها رو دستی نسازید، از AI بخواید دستور ساختش رو براتون بنویسه:
«برای ساخت این ساختار پروژه، دستور ترمینالی مناسب ویندوز / لینوکس / مک رو بنویس.»
@programming_codiing
❤8
</ MoDev >
قبل از کدنویسی، ساختار پروژه رو بچین. اگه از همون اول ساختار پروژه مشخص باشه، با بزرگ شدن پروژه خیلی کمتر با فایل‌های درهم‌ریخته مواجه می‌شیم. مثلاً برای پروژه‌های Next.js / React می‌تونیم از چنین ساختاری شروع کنیم: project/ ├── app/ │ ├── _components/…
ساختار مناسب، خودش جزوی از تمیزی کدِ.
👍10
ساختار کامل پروژه‌ی Backend.
تو پست قبلی ساختار ابتدایی پیشنهادی برای پروژه‌های Frontend رو گفتیم؛ این بار بریم سراغ یک ساختار تمیز و قابل توسعه برای Backend.
وقتی پروژه بزرگ می‌شه، پوشه‌هایی مثل controllers و services کم‌کم پر از فایل‌های بی‌ربط می‌شن. راه‌حل اینه هر Feature، یک ماژول مستقل داشته باشه و همه‌ی کدهای مرتبط با خودش رو همون‌جا نگه داره.
در نهایت، هدف این ساختار ساده‌ست:
ماژول بیشتر، نه شلوغی بیشتر.
@programming_codiing
تو پست قبلی ساختار ابتدایی پیشنهادی برای پروژه‌های Frontend رو گفتیم؛ این بار بریم سراغ یک ساختار تمیز و قابل توسعه برای Backend.
وقتی پروژه بزرگ می‌شه، پوشه‌هایی مثل controllers و services کم‌کم پر از فایل‌های بی‌ربط می‌شن. راه‌حل اینه هر Feature، یک ماژول مستقل داشته باشه و همه‌ی کدهای مرتبط با خودش رو همون‌جا نگه داره.
backend/
├── src/
│ ├── modules/
│ │
│ ├── shared/
│ │ ├── middlewares/
│ │ ├── errors/
│ │ ├── utils/
│ │ ├── constants/
│ │ └── types/
│ │
│ ├── infrastructure/
│ │ ├── database/
│ │ │ ├── migrations/
│ │ │ └── seeds/
│ │ ├── cache/
│ │ ├── queue/
│ │ ├── storage/
│ │ └── mailer/
│ │
│ ├── config/
│ │
│ ├── routes.ts
│ ├── app.ts
│ └── server.ts
│
├── tests/
│ ├── integration/
│ └── e2e/
│
├── scripts/
modules/
هر Feature، ماژول خودش رو داره و کدهای مربوط به اون Feature کنار هم قرار می‌گیرن.
shared/
کدهایی که بین چند ماژول استفاده می‌شن؛ مثل Middlewareها، Errorها، Utilityها و Typeهای مشترک.
infrastructure/
مسئول ارتباط با زیرساخت‌ها و سرویس‌های بیرونی؛ مثل Database، Cache، Queue، Storage و Mailer.
config/
تنظیمات پروژه و متغیرهای "env" در یک نقطه مدیریت می‌شن.
tests/
تست‌های Integration و E2E از کد اصلی پروژه جدا نگه داشته می‌شن.
در نهایت، هدف این ساختار ساده‌ست:
ماژول بیشتر، نه شلوغی بیشتر.
@programming_codiing
❤4⚡1