--
### فراتر از کدنویسی؛ هنر معماری با اصل Single Responsibility (SRP)

در دنیای برنامه‌نویسی وب، نوشتن کدی که «کار کند» فقط ۲۰ درصد ماجراست. ۸۰ درصد باقی‌مانده، توانایی نگهداری (Maintenance) و توسعه‌‌پذیری آن کد است. امروز به سراغ اولین و مهم‌ترین اصل از اصول SOLID می‌رویم.

#### 🛠 اصل مسئولیت واحد (SRP) چیست؟
این اصل می‌گوید: «هر کلاس یا ماژول باید فقط و فقط یک دلیل برای تغییر داشته باشد.»

به زبان ساده: یک قطعه کد نباید همزمان هم با دیتابیس حرف بزند، هم محاسبات ریاضی انجام دهد و هم خروجی را برای کاربر نمایش دهد!

#### ❌ نمونه کد غیرحرفه‌ای (Spaghetti Code):
در این مثال، یک کلاس هم وظیفه مدیریت کاربر و هم وظیفه اعتبارسنجی و ذخیره در فایل را دارد:

class User {
  constructor(name, email) {
    this.name = name;
    this.email = email;
  }

  // مدیریت داده‌های کاربر
  saveToDatabase() {
    console.log(`Saving ${this.name} to DB...`);
  }

  // اعتبارسنجی - این وظیفه کلاس User نیست!
  validateEmail() {
    return this.email.includes('@');
  }

  // نمایش - این هم وظیفه این کلاس نیست!
  showProfile() {
    return `<h1>${this.name}</h1>`;
  }
}

#### ✅ نمونه کد حرفه‌ای (Refactored):
در سطح حرفه‌ای، ما وظایف را تفکیک می‌کنیم. این کار باعث می‌شود اگر روزی متد ذخیره‌سازی از فایل به دیتابیس تغییر کرد، نیازی نباشد منطق نمایش پروفایل را دستکاری کنیم.

// ۱. کلاس موجودیت کاربر (فقط داده)
class User {
  constructor(name, email) {
    this.name = name;
    this.email = email;
  }
}

// ۲. سرویس اعتبارسنجی
class UserValidator {
  static validateEmail(email) {
    return email.includes('@');
  }
}

// ۳. سرویس ذخیره‌سازی (Persistance)
class UserRepository {
  save(user) {
    console.log(`Saving ${user.name} to Database...`);
  }
}

// ۴. سرویس نمایش (UI/Presentation)
class UserView {
  renderProfile(user) {
    return `<div>User: ${user.name}</div>`;
  }
}

#### 🚀 چرا این سبک کدنویسی برای شما مهم است؟
۱. تست‌پذیری: تست کردن یک تابع کوچک که فقط یک کار انجام می‌دهد، بسیار راحت‌تر است.
۲. کاهش باگ: وقتی تغییری در بخش دیتابیس ایجاد می‌کنید، خیالتان راحت است که بخش UI خراب نمی‌شود.
۳. کار تیمی: در پروژه‌های بزرگ (مثل پروژه‌های درس آزمایشگاه مهندسی نرم‌افزار)، هر کس می‌تواند روی یک بخش مستقل کار کند.

---
#برنامه_نویسی #مهندسی_نرم_افزار #CleanCode #SOLID #WebDevelopment #شب_تاب

@init_code هزاران آموزش برنامه نویسی

کدنویسی امن؛ چرا نباید هرگز به ورودی‌های کاربر اعتماد کرد؟

در دنیای توسعه نرم‌افزار، شکاف بزرگ میان یک «کدنویس» و یک «مهندس نرم‌افزار»، در نحوه برخورد با داده‌های ورودی است. امنیت یک سیستم، قبل از آنکه به فایروال‌ها وابسته باشد، به کیفیت کدهایی که می‌نویسیم بستگی دارد.

#### 🛡 اصل طلایی: Never Trust User Input
فرقی نمی‌کند شما یک فرم تماس ساده می‌سازید یا یک API پیچیده؛ هر داده‌ای که از سمت کاربر می‌آید (پارامترهای URL، بدنه درخواست‌های POST، یا حتی هدرها) می‌تواند سمی باشد.

#### ❌ رویکرد خطرناک (آسیب‌پذیر در برابر SQL Injection):
بسیاری از توسعه‌دهندگان مبتدی، ورودی کاربر را مستقیماً در کوئری‌های پایگاه داده قرار می‌دهند:

// بسیار خطرناک!
const userId = req.body.id;
const query = `SELECT * FROM users WHERE id = ${userId}`; 
db.execute(query);

*در این حالت، یک نفوذگر می‌تواند با وارد کردن مقداری مثل 1 OR 1=1 به تمام اطلاعات دیتابیس دسترسی پیدا کند.*

#### ✅ رویکرد حرفه‌ای (استفاده از Prepared Statements):
در سطح مهندسی، ما از پارامتریزه کردن کوئری‌ها استفاده می‌کنیم تا موتور پایگاه داده، ورودی را فقط به عنوان «داده» ببیند، نه بخشی از دستورات اجرایی:

// ایمن و حرفه‌ای
const userId = req.body.id;
const query = "SELECT * FROM users WHERE id = ?";
db.execute(query, [userId]); 

#### 🛠 سه گام برای افزایش امنیت در پروژه‌های وب:

1. Validation (اعتبارسنجی): چک کنید که آیا داده اصلاً فرمت درستی دارد؟ (مثلاً ایمیل واقعاً ایمیل است؟)
2. Sanitization (پاک‌سازی): حذف کاراکترهای خطرناک (مانند <script> یا کدهای SQL) از ورودی‌ها.
3. Principle of Least Privilege: اپلیکیشن شما باید با کمترین دسترسی ممکن به دیتابیس متصل شود. (مثلاً دسترسی حذف یا Drop کردن جداول را نداشته باشد).

#### 💡 نتیجه‌گیری برای توسعه‌دهندگان:
امنیت یک ویژگیِ الحاقی (Add-on) نیست که در پایان پروژه به آن فکر کنیم؛ امنیت باید در تار و پود کدهای ما تنیده شده باشد. با رعایت همین نکات ساده، جلوی بیش از ۸۰٪ حملات رایج وب گرفته می‌شود.

---
#برنامه_نویسی #امنیت_نرم_افزار #WebSecurity #SQLInjection #CleanCode #توسعه_وب #شب_تاب

---

@init_code هزاران آموزش برنامه نویسی

### هنر سکوت در کدنویسی؛ چه زمانی و چگونه کامنت بنویسیم؟

در دنیای برنامه‌نویسی یک جمله معروف وجود دارد: «کدِ خوب مثل یک جکِ خوب است؛ اگر مجبور شوید آن را توضیح دهید، یعنی به اندازه کافی خوب نیست!»

اما واقعیت این است که حتی بهترین کدهای دنیا هم گاهی به توضیح نیاز دارند. مرز بین «کامنت‌گذاری حرفه‌ای» و «کامنت‌گذاری آزاردهنده» کجاست؟

#### ❌ اشتباه رایج: توضیحِ بدیهیات (Redundant Comments)
بسیاری از کدنویس‌ها عادت دارند دقیقاً همان چیزی که کد انجام می‌دهد را بنویسند. این کار فقط حجم فایل را زیاد و تمرکز را کم می‌کند:

// دریافت نام کاربر از ورودی
const userName = getName(); 

// حلقه برای پیمایش لیست محصولات
for (let i = 0; i < products.length; i++) {
  // اضافه کردن قیمت به مجموع
  total += products[i].price;
}

*این کامنت‌ها هیچ ارزشی ندارند، چون خودِ کد به وضوح دارد همین را می‌گوید.*

#### ✅ رویکرد حرفه‌ای: توضیحِ «چرا» به جای «چیستی»
کد شما می‌گوید «چه اتفاقی» می‌افتد، اما کامنت باید بگوید «چرا این اتفاق» می‌افتد. از کامنت برای توضیح منطق‌های پیچیده، تصمیمات بیزنسی یا رفع باگ‌های خاص استفاده کنید:

// به دلیل محدودیت API درگاه بانکی، مبالغ باید به ریال تبدیل شوند
// و سقف تراکنش نباید از ۵۰ میلیون فراتر برود.
if (amount > 50000000) {
  throw new Error("سقف تراکنش رعایت نشده است");
}

#### 🛠 ۳ قانون طلایی برای مستندسازی حرفه‌ای:

1. کدِ خود-توضیح‌دهنده (Self-Documenting): به جای اینکه برای یک متغیر با نام مبهم کامنت بگذارید، نام متغیر را اصلاح کنید.
- ❌ let d = 30; // تعداد روزهای انقضا
- ✅ let daysUntilExpiration = 30;

2. استفاده از JSDoc یا استانداردهای مشابه: برای توابع و کلاس‌ها از فرمت‌های استانداردی استفاده کنید که ادیتورها (مثل VS Code) بتوانند آن‌ها را تشخیص دهند:

    /**
     * محاسبه تخفیف بر اساس سطح کاربری
     * @param {number} price - قیمت اصلی محصول
     * @param {string} rank - رتبه کاربر (Gold, Silver, Bronze)
     * @returns {number} قیمت نهایی پس از کسر تخفیف
     */
    function calculateDiscount(price, rank) { ... }
    

3. کامنت‌های TODO: برای کارهایی که باید در آینده انجام شوند، از تگ // TODO: استفاده کنید تا تیم بداند چه بخش‌هایی نیاز به تکمیل دارد.

#### 💡 نتیجه‌گیری:
بهترین کامنت، کدی است که به کامنت نیاز نداشته باشد. اما وقتی منطق کار پیچیده می‌شود، کامنتِ شما باید مثل یک نقشه‌ راه برای برنامه‌نویس بعدی (یا خودتان در ۶ ماه آینده) عمل کند.

#برنامه_نویسی #CleanCode #Documentation #Refactoring #مهندسی_نرم_افزار #کدنویسی #شب_تاب

---

@init_code هزاران آموزش برنامه نویسی

### بدهی فنی (Technical Debt)؛ قاتل خاموش پروژه‌های نرم‌افزاری

در دنیای مهندسی نرم‌افزار، ما مدام با یک دوراهی مواجهیم: «سرعت» یا «کیفیت»؟
وقتی برای رساندن پروژه به ضرب‌الاجل (Deadline)، از استانداردهای کدنویسی صرف‌نظر می‌کنیم، در واقع در حال گرفتن یک وام هستیم؛ وامی که به آن «بدهی فنی» می‌گویند.

#### ❓ بدهی فنی دقیقاً چیست؟
تصور کنید برای راه‌اندازی سریع یک قابلیت، به جای طراحی یک معماری اصولی، از کدهای کپی-پیست شده و راه‌حل‌های موقتی (Quick Fixes) استفاده می‌کنید. کار شما راه می‌افتد، اما این کدِ ضعیف، «بدهی» شماست. مانند هر وامی، این بدهی هم «بهره» (Interest) دارد. بهره‌ٔ آن، زمانی است که در آینده باید صرف دست‌وپنجه نرم کردن با باگ‌های عجیب و سخت شدن توسعه قابلیت‌های جدید کنید.

#### 🛠 انواع بدهی فنی:

1. بدهی عمدی: وقتی آگاهانه برای رسیدن به بازار (Time to Market) کیفیت را فدا می‌کنیم (باید در اولین فرصت بازپرداخت شود).
2. بدهی فرسایشی: کدی که در زمان خودش خوب بوده، اما با گذشت زمان و تغییر تکنولوژی، قدیمی و ناکارآمد شده است.
3. بدهی ناشی از بی‌تجربگی: زمانی که تیم به دلیل عدم تسلط بر الگوهای طراحی (Design Patterns)، کدی غیراستاندارد تولید می‌کند.

#### ❌ نشانه‌های بالا رفتن بدهی فنی در یک پروژه:
- اضافه کردن یک ویژگی ساده، هفته‌ها زمان می‌برد.
- با اصلاح یک باگ، سه جای دیگر پروژه خراب می‌شود.
- تیم از دست زدن به کدهای قدیمی می‌ترسد (Legacy Code).

#### ✅ چگونه بدهی فنی را مدیریت کنیم؟

- رفکتورینگ (Refactoring) مستمر: بخشی از زمان هر اسپرینت یا هفته کاری را به تمیز کردن کدهای قبلی اختصاص دهید.
- تست‌نویسی (Unit Testing): تست‌های خودکار مثل یک ترمز عمل می‌کنند و اجازه نمی‌دهند بدهی فنی از حد مجاز فراتر برود.
- مستندسازی تصمیمات: بنویسید که چرا فلان بخش را موقتاً این‌طور پیاده کرده‌اید تا آیندگان (یا خودِ آینده‌تان) گیج نشوند.

#### 💡 نتیجه‌گیری:
بدهی فنی به خودیِ خود بد نیست؛ گاهی برای تجارت لازم است. اما اگر مدیریت نشود، پروژه شما به نقطه‌ای می‌رسد که هزینه‌ نگهداری‌اش از هزینه بازنویسی کامل آن بیشتر می‌شود (ورشکستگی فنی).

#برنامه_نویسی #مهندسی_نرم_افزار #TechnicalDebt #بدهی_فنی #مدیریت_پروژه #CleanCode #شب_تاب

---

@init_code هزاران آموزش برنامه نویسی

🍝 اسپاگتی کد و بدهیِ فنی؛ وقتی مثلِ گاو فقط کد می‌زنی!

ببین، یه سری برنامه‌نویس داریم که فکر می‌کنن چون کُدشون "کار می‌کنه"، دیگه یعنی شاهکار کردن! آخه لاشخور! اگه کدی زدی که فردا خودت هم نمی‌تونی بفهمی چی به چیه، تو برنامه‌نویس نیستی، تو یه «تایپیستِ متوهمی» که داری یه بمبِ ساعتی می‌سازی.

💀 داستان چیه؟ (بدهیِ فنی یا Technical Debt)
بدهی فنی یعنی تو واسه اینکه سریع کار رو تحویل بدی، از راهِ کثیف و میان‌بُر میری. مثل اینه که واسه ساختنِ خونه، جای تیرآهن از چوبِ کبریت استفاده کنی. اولش خونه سرپاست، ولی یه باد بیاد، کلِ هیکلِ پروژه به فاک میره.

چطوری گند می‌زنن به پروژه؟
۱. اسپاگتی کد: کدها رو جوری به هم گره می‌زنن که اگه یه if رو این‌ور تغییر بدی، یهو دیتابیسِ اون‌ورِ دنیا منفجر میشه!
۲. Hard-coding: متغیرها و آدرس‌ها رو دستی می‌نویسن وسط کد. انگار مغزشون نمیکشه که اینا باید داینامیک باشن.
۳. نبودِ داکیومنت: طرف جوری کد می‌زنه انگار قراره فردا بمیره و رازش رو با خودش ببره تو گور. هیچکس نمی‌فهمه این فانکشنِ کص‌شعر قراره چه غلطی بکنه!

نتیجه؟
بعد از ۶ ماه، پروژه جوری سنگین و کثیف میشه که دیگه هیچ آپدیتِ ساده‌ای نمیشه داد. هر تغییری مساوی با ۱۰۰ تا باگِ جدیده‌. اینجاست که صاحبِ پروژه باید کلِ اون کدهایِ آشغال رو بریزه دور و از اول شروع کنه. یعنی پول و زمانِ ملت رو دادی دستِ یه مشت اَجق‌وَجق!

⚠️ چرا اینا برنامه‌نویس نیستن؟
چون این کص‌مغزها هنوز نمی‌فهمن که کد رو برای آدمیزاد می‌نویسن، نه برای ماشین! ماشین هر آشغالی رو اجرا می‌کنه، ولی این هنرِ توئه که جوری بنویسی که بقیه هم بتونن توسعه‌اش بدن. اینا همونایی هستن که فرقِ SOLID و KISS رو با مارکِ پوشکِ بچه‌شون نمی‌دونن!

🛠️ راهِ نجات (اگه نمی‌خوای یه بازنده باشی):
- Clean Code: برو کتابِ کُلین کد رو بخون تا بفهمی چطوری مثل آدم اسم‌گذاری کنی و فانکشن بنویسی.
- Refactoring: همیشه وقتی کد می‌زنی، برگرد و تمیزش کن. نذار زباله‌ها روی هم جمع بشن.
- Design Patterns: الگوهای طراحی رو یاد بگیر که چرخ رو از اول اختراع نکنی (اونم مربع!).
- TDD: قبل از اینکه کدِ کثیف بزنی، براش تست بنویس که بفهمی داری چه گوهی می‌خوری.

#TechnicalDebt #CleanCode #SpaghettiCode #Programming #Refactoring #برنامه_نویس_بی_عرضه

---
اگه با این پست حال کردی و فهمیدی که تا حالا داشتی آشغال تولید می‌کردی، اون انگشتِ مبارکت رو فشار بده رو ریکشن‌ها. حمایت نکنی، باگ‌های کدِ قبلیت میاد تو خوابت خفه‌ات می‌کنه! 😂🖕
@init_code

SQLite
در مقابل غول‌های دیتابیس؛ وقتی با پیکان میری مسابقه فرمول یک! 🏎️📦

تا حالا شده برای یه پروژه ساده که فقط قراره اسم چند تا کاربر رو ذخیره کنه، به فکر نصب PostgreSQL یا MySQL بیفتی و ۳ ساعت درگیر تنظیمات سرور و یوزر و دسترسی‌ها بشی؟ تبریک میگم، تو هم دچار سندرم «بیش‌ازحد-مهندسی-کردن» (Over-engineering) شدی! 😅

خیلیا فکر می‌کنن استفاده از SQLite نشونه‌ی آماتور بودن یا غیرحرفه‌ای بودن پروژه است. اما بذارید یه رازی رو بهتون بگم: SQLite مثل اون آچار فرانسه‌ایه که توی جیب جا میشه و هیچ‌وقت هم گم نمیشه!

چرا SQLite برای شروع (و حتی خیلی جاهای دیگه) پادشاهه؟
۱. نصب؟ چه نصبی؟: وقتی با Flask کار می‌کنی، SQLite دقیقاً یعنی «هیچی»! لازم نیست دیتابیس رو نصب کنی، کانفیگ کنی یا با هزارتا ارورِ «Connection Refused» بجنگی. فقط یه فایل .db داری و تمام. زندگی یعنی همین!

۲. سریع‌تر از نور (برای شما): برای پروژه‌های کوچیک تا متوسط، سرعت SQLite اونقدر بالاست که اصلاً متوجه نمیشی دیتابیس داری یا داری با یه لیست توی پایتون کار می‌کنی.

۳. قابلیت حمل فوق‌العاده: می‌خوای پروژه رو بفرستی برای دوستت؟ یه دونه فایل .db رو کپی کن و براش بفرست. همین! نه نیازه که اونم دیتابیس نصب کنه، نه نیاز به Export/Import پیچیده داری.

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

نصیحت برادرانه به تو برنامه‌نویس عزیز:
به‌جای اینکه ۵۰ درصد وقتت رو صرفِ ور رفتن با تنظیماتِ پیچیده دیتابیس‌های سنگین کنی، انرژی‌ت رو بذار روی ساختار داده‌هات (Schema). یه دیتابیس عالی با طراحی غلط، از یه SQLite با طراحیِ هوشمندانه، هزار برابر کندتر و پرباگ‌تره!

نتیجه اخلاقی:
پروژه رو با ساده‌ترین ابزار شروع کن. وقتی به دیواری خوردی که دیگه با SQLite حل نمیشد، اون وقت با افتخار برو سراغ غول‌ها. تا اون موقع، از سادگی لذت ببر و کد بزن، چون اون چیزی که به برنامه‌ت اعتبار میده، کیفیت کد توئه، نه اسمی که روی دیتابیس گذاشتی! 💻✨

#SQLite #برنامه_نویسی #پایگاه_داده #Flask #Python #کدنویسی #CleanCode #طنز_برنامه_نویسی #برنامه_نویس #دیتابیس #توسعه_وب #BackEnd

هزاران آموزش برنامه نویسی
@init_code