👩‍💻 نسخه‌ی جدید فلاتر، یعنی Flutter 3.35، منتشر شده و کلی قابلیت هیجان‌انگیز با خودش آورده که تمرکزشون بیشتر روی بالا بردن سرعت و کیفیت کدنویسیه. بیاید چندتا از باحال‌ترین‌هاش رو با هم ببینیم.

🔥 هات ری‌لود پایدار برای وب

اولین خبر مهم برای اوناییه که با فلاتر برای وب کد می‌زنن: Stateful Hot Reload برای وب بالاخره پایدار شد! دیگه لازم نیست برای دیدن هر تغییر کوچیکی کل صفحه رو رفرش کنید. از این به بعد، مثل اپ‌های موبایل، تغییرات رو به صورت لحظه‌ای و با حفظ state برنامه می‌بینید. این یعنی یه جهش بزرگ توی سرعت توسعه‌ی وب با فلاتر!

🖼 پیش‌نمایش زنده ویجت‌ها (Widget Previews)

قابلیت شگفت‌انگیز این نسخه، معرفی Widget Previews به صورت آزمایشیه! اگه با ابزارهایی مثل Storybook توی دنیای وب کار کرده باشید، دقیقاً می‌دونید این چیه. این قابلیت بهتون اجازه می‌ده ویجت‌هاتون رو به صورت کاملاً ایزوله و جدا از کل اپلیکیشن ببینید، تست کنید و توسعه بدید. می‌تونید یه ویجت رو همزمان توی سایزهای مختلف صفحه، با تم‌های روشن و تاریک و فونت‌های متفاوت کنار هم ببینید. برای ساختن دیزاین سیستم یا تست کردن کامپوننت‌ها فوق‌العاده‌ست!

⚙️ بهبودهای موتور رندرینگ Impeller

موتور گرافیکی جدید و قدرتمند فلاتر، کلی بهبودهای زیرپوستی داشته. این یعنی اپلیکیشن‌های شما سریع‌تر و روان‌تر اجرا می‌شن. مهم‌ترین تغییراتش این‌ها بودن:

⬅️ کاهش زمان استارت اپ: برنامه‌ها سریع‌تر از قبل بالا میان.

⬅️ بهینه‌سازی رندر کردن مسیرها (Path rendering): انیمیشن‌ها و UIهای پیچیده عملکرد بهتری دارن.

⬅️ افزایش کیفیت بصری: افکت‌هایی مثل blur حالا تمیزتر و باکیفیت‌تر نمایش داده می‌شن.

👁 توجه ویژه به دسترسی‌پذیری (Accessibility)

فلاتر همیشه به فراگیر بودن اپ‌ها اهمیت می‌ده. تو این نسخه ویجت جدیدی به اسم SemanticsLabelBuilder معرفی شده. کارش اینه که بهتون کمک می‌کنه چندتا داده‌ی مختلف رو با هم ترکیب کنید و به صورت یک پیام منسجم و قابل فهم برای ابزارهای صفحه‌خوان (Screen Readers) ارائه بدید. اینجوری کاربرهایی که از این ابزارها استفاده می‌کنن، تجربه‌ی خیلی بهتری از اپ شما خواهند داشت.

🤖 هوشمندتر شدن با کمک هوش مصنوعی

با معرفی Dart and Flutter MCP Server، حالا دستیارهای هوش مصنوعی (AI Coding Assistants) می‌تونن به عمق پروژه‌تون دسترسی داشته باشن. هوش مصنوعی می‌تونه خطاهای (runtime) رو خودش پیدا و رفع کنه، بهترین پکیج رو از pub.dev پیدا و نصب کنه.


چندتا اتفاق مهم دیگه هم افتاده:

⬅️سریع‌تر شدن Analysis Server: ابزارهایی مثل dart analyze و dart fix تقریباً ۵۰٪ سریع‌تر شدن که باعث می‌شه تجربه‌ی کدنویسی روزمره‌تون خیلی روون‌تر بشه.

⬅️جداسازی کتابخونه‌های Material و Cupertino: تیم فلاتر تصمیم گرفته این دوتا کتابخونه‌ی طراحی رو از هسته‌ی اصلی جدا کنه. این کار باعث می‌شه آپدیت‌هاشون سریع‌تر و مستقل از نسخه‌های فلاتر منتشر بشه و جامعه‌ی برنامه‌نویس‌ها راحت‌تر بتونن تو توسعه‌شون مشارکت کنن.

⬅️ ویجت‌های جدید و بهبودیافته: کلی ویجت جدید مثل DropdownMenuFormField و CupertinoExpansionTile اضافه شده.


همه ی این ها بخشی از مقاله ای هست که تیم فلاتر منتشر کرده. برای دیدن جزئیات کامل تغییرات پیشنهاد میکنم مقاله ی تیم فلاتر رو بخونید:

📱 https://medium.com/flutter/whats-new-in-flutter-3-35-c58ef72e3766

---

💡 مثل همیشه کنجاو بمونید :)

🆔 @MdDaily

📄 فهرست مدارک و گواهینامه‌های رایگانی که تو دنیای کار اعتبار دارن:

احتمالا اسم freecodecamp رو زیاد شنیده باشید و اولین مورد لیستم هست :

1. https://freecodecamp.org/learn/

2. دوره های دانشگاه هلسینکی:

👩‍💻 Python Programming
https://programming-25.mooc.fi

📊 Data Analysis with Python
https://courses.mooc.fi/org/uh-cs/courses/data-analysis-with-python-2024-2025

🤖 AI
https://elementsofai.com

👩‍💻 DevOps with Kubernetes
https://devopswithkubernetes.com

👩‍💻 Fullstack Web Development
http://fullstackopen.com

همه ی دوره هاش: https://mooc.fi/en/courses/

3. سیسکو نت‌اکد (Cisco Netacad)

👩‍💻 Python
http://netacad.com/courses/python-essentials-1

👩‍💻 JavaScript
http://netacad.com/courses/javanoscript-essentials-1

📊 Data Analytics
http://netacad.com/courses/data-analytics-essentials

😒 Ethical Hacking
http://netacad.com/courses/ethical-hacker

🌐 Networking
http://netacad.com/courses/networking-basics

4. گواهینامه‌های اوراکل (Oracle Certifications)

☁️ Cloud
📊 Data
🤖 AI

🔗 https://education.oracle.com/race-to-certification-2025

5. آکادمی سیلور (Saylor Academy)

👩‍💻👩‍💻 Database
👩‍💻 OS
🖥 Networking
📊 Data Science

🔗 https://learn.saylor.org/course/index.php?categoryid=9

6. دانشگاه هاروارد

🧑‍💻 Computer Science
https://cs50.harvard.edu/x/2025/

👩‍💻 Python
https://cs50.harvard.edu/python/2022/

🤖 AI
https://cs50.harvard.edu/ai/2024/

👩‍💻 Web Dev
https://cs50.harvard.edu/web/2020/

7. آکادمی هاب‌اسپات (HubSpot Academy)

می‌تونید گواهینامه‌های مربوط به سئو (SEO)، بازاریابی، فروش و کلی چیزای دیگه رو بگذرونید

🔗 https://academy.hubspot.com/certification-overview

8. Neo4j

❯ Neo4j Certified Professional
https://graphacademy.neo4j.com/certifications/neo4j-certification/

❯ Neo4j Graph Data Science Certification
https://graphacademy.neo4j.com/courses/gds-certification/

9. Hackerrank


Get certified and also earn badges for free on Hackerrank.

👩‍💻👩‍💻 SQL
👩‍💻 👩‍💻👩‍💻👩‍💻 Python, Java, JavaScript, Golang
👩‍💻👩‍💻 React, Angular
❯ DSA

🔗 https://hackerrank.com/skills-verification


10. Kaggle

👩‍💻 Python
👩‍💻👩‍💻 SQL
🤖 AI/ML, DL
📊 Data Science

🔗 https://kaggle.com/learn

وقتی منابع یادگیری زیاد میشن، لزوما این نیست که برید همشون رو یاد بگیرید و اون کمال گرایی درونیتون که میگه اگه همش رو نبینم پس از یه چیزی عقب میوفتمم رو باید کنترل کنید :)
یکی از کار هایی که میشه کرد اینکه توشون چرخ بزنید، ایده بگیرید و بالاخره با یکیشون حال میکنید و ادامه میدید دیگه.

---

💡 مثل همیشه کنجاو بمونید :)

🆔 @MdDaily

برای حل چالش بالا بردن سرعت برنامه و کاهش فشار روی منابع یکی از مکانیزم های کشینگ مورد علاقم که بسته به use case زیاد ازش استفاد میکنم LRU Cache هست.

کلمه LRU مخفف عبارت "Least Recently Used" هست. این مکانیزم به زبان ساده، داده‌هایی رو که اخیراً بیشتر استفاده شدن، نگه می‌داره و اگه حافظه پر بشه، هوشمندانه قدیمی‌ترین داده‌ای رو که بهش دست نزدیم، حذف می‌کنه تا جا برای داده‌های جدید باز بشه.

این سیستم اونقدر کاربردیه که چه در حال ساخت یه سرویس بک‌اند باشید، چه یه اپلیکیشن ، می‌تونید برای افزایش پرفورمنس ازش استفاده کنید.

-----

الگوریتم پیاده‌سازی

برای فهمیدن LRU Cache و اینکه چرا انقدر کارآمد هست، باید بدونید که این سیستم از ترکیب دو تا ساختار داده اصلی ساخته شده:

⬅️ یک نقشه (Hash Map): این بخش برای جستجوی سریع داده‌ها با کلیدشون استفاده می‌شه. با این کار، پیدا کردن یک داده در کش در زمان ثابت O(1) اتفاق می‌افته و دیگه نیازی به گشتن توی کل داده‌ها نیست.

⬅️ یک لیست پیوندی دوطرفه (Doubly Linked List): این لیست وظیفه داره ترتیب استفاده از داده‌ها رو نگه داره. جدیدترین داده همیشه در ابتدای (Head) لیست قرار می‌گیره و قدیمی‌ترین داده هم در انتهای (Tail) اون. با این ساختار، می‌تونیم با سرعت بالا داده‌ها رو جابه‌جا کنیم یا قدیمی‌ها رو حذف کنیم.

حالا چطور کار می‌کنه؟

وقتی یه داده رو از کش دریافت (Get) می‌کنید، سیستم اول تو نقشه دنبال کلیدش می‌گرده. اگه پیداش کرد، اون داده رو از هر جایی که تو لیست پیوندی هست، جدا می‌کنه و به ابتدای لیست می‌بره تا "تازگی" اون به‌روز بشه.

وقتی هم یه داده جدید اضافه (Put) می‌کنید، سیستم بررسی می‌کنه که آیا اون داده از قبل وجود داشته یا نه. اگه قبلاً بود، فقط مقدارش رو آپدیت می‌کنه و می‌ذاره اول لیست. اگه جدید بود و کش هم پر بود، قدیمی‌ترین داده رو از انتهای لیست حذف می‌کنه و بعد داده جدید رو به اول لیست اضافه می‌کنه.

این ترکیب هوشمندانه از هش‌مپ و لیست پیوندی باعث می‌شه که هر دو عملیات اصلی کشینگ با بالاترین سرعت ممکن انجام بشن و برای همین هم LRU Cache یک تکنیک فوق‌العاده برای بهینه‌سازی پرفورمنسه.


یه نمونه ساده هم با Go پیاده کردم که توی این gist میتونید ببینید:

https://gist.github.com/mdpe-ir/bb25dac1ed506bd529292f0f52ecc929

البته این نمونه فقط برای اینکه ببینید این مکانیزم چطوری داره کار میکنه و توی پروژه های واقعی باید از کتابخونه مرتبط به اون زبان استفاده بشه.


منابع بیشتر

این مقاله هم منبع خوبی برای درک عمیق‌تر الگوریتم‌ها و نحوه پیاده‌سازی اونه:

🌐 Interview Cake: LRU Cache



---

💡 مثل همیشه کنجاو بمونید :)

🆔 @MdDaily

امروز ۲۵۶اُمین روز سال میلادی، یعنی روز برنامه‌نویسه!

این روز رو به همه کسایی که با هر خط کد، یه ایده رو به واقعیت تبدیل می‌کنن و ساعت‌ها برای بهینه‌تر شدن یه الگوریتم وقت می‌ذارن، تبریک می‌گم. برنامه نویسی از نظر من یعنی هنر ساختن و حل مسئله.

---

💡 مثل همیشه کنجاو بمونید :)

🆔 @MdDaily

چطوری System Design رو یاد بگیریم قسمت ۱ از ۲

داشتم یه مقاله از 📱 میخوندم با عنوان چطوری System Design رو یاد گرفتم. اول بریم سراغ این مقاله و آخر کارم منابعی که قبلا توی کانال معرفی کردم رو بهشون لینک میدم.

نویسنده ی مقاله که سفر یادگیریش رو باهامون به اشتراک میذاره میگه زمانی بود که هر ویدیو یا بلاگی که اسم «طراحی سیستم» (System Design) روش بود رو کلاً بی‌خیال می‌شده و با خودش میگفته اینا مال سنیور هاست نه من. بعد میره تو مصاحبه بهش میگن برای طراحی یه اپ مثل Uber باید چیکار کرد.

اصلاً نمی‌دونسته چطور باید از پس مقیاس‌پذیری بربیاد، هیچ ایده‌ای راجع به صف‌ها (Queues) نداشته، یا حتی نمی‌دونست چطور موقعیت لحظه‌ای کاربرها رو ذخیره کنه.

اینجاس که System Design وارد میشه.

---

1️⃣ اول از همه حالا که میدونیم چیو نمیدونیم بریم یادش بگیریم

طراحی سیستم اولش خیلی ترسناکه.

آدما یه سری کلمه میگن مثل «شاردینگ» (Sharding)، «CQRS»، «متوازن‌کننده بار» (Load Balancer)، (Eventual Consistency) و...

همه اولش احساس گم شدن دارن.

طراحی سیستم یه موضوع تکی نیست. یه «فصل» نیست که بتونی تو یه هفته تمومش کنی.

بلکه ترکیبی از ایناست:

✔️ جریان حرکت داده‌ها چطوریه؟

✔️ سرویس‌ها چطور با هم صحبت می‌کنن؟

✔️ چطور سیستم‌ها زیر بار ترافیک سنگین دوام میارن؟

✔️ و چطور می‌شه سیستم رو قابل‌اطمینان، سریع و مقاوم در برابر خطا (Fault-tolerant) ساخت؟

پس دست از تلاش برای کمال‌گرایی باید برداشت و روی موفقیت‌های کوچیک تمرکز کرد.

---

2️⃣ «طراحی سیستم» رو به موضوعات کوچیک تقسیم کنیم

طراحی سیستم یه موضوع بزرگ نیست، بلکه مجموعه‌ای از بلوک‌های ساختمانی به هم پیوسته است.

بریم برای نقشه راه:

الف) اصول اولیه (The Basics)

✔️ وقتی توی مرورگر یه آدرس (URL) رو تایپ می‌کنی، چه اتفاقی می‌افته؟

✔️ مفاهیم DNS، متوازن‌کننده بار (Load Balancer) و CDN چی هستن؟

✔️ پروتکل TCP در برابر UDP، HTTP در برابر HTTPS

ب) داده و ذخیره‌سازی (Data and Storage)

✔️ دیتابیس SQL در برابر NoSQL

✔️ ایندکسینگ (Indexing)، رپلیکا (Replication)، شاردینگ (Sharding)

✔️ کی باید MongoDB رو انتخاب کنی و کی PostgreSQL؟

ج) تکنیک‌های مقیاس‌گذاری (Scaling Techniques)

✔️ مقیاس‌گذاری افقی (Horizontal) در برابر عمودی (Vertical)

✔️ کشینگ (Caching) (مثل Redis، Memcached)

✔️ متوازن‌سازی بار (Load Balancing) (مثل Round-robin، IP Hashing)

این بخش باعث میشه چیزی رو طراحی کنید که برای میلیون‌ها کاربر کار کنه، حتی اگه فقط روی کاغذ باشه.

د) الگوهای معماری (Architecture Patterns)

✔️ مونولیت (Monolith) در برابر میکروسرویس‌ها (Microservices)

✔️ معماری مبتنی بر رویداد (Event-Driven Architecture)

✔️ مفاهیم Pub/Sub، صف‌های پیام (Message Queues) (مثل Kafka، RabbitMQ)

---

3️⃣ تماشای تفکر آدم‌های واقعی، نه فقط آموزش دادن اون‌ها

به جای دیدن ویدیوهایی که سبک آموزشی دارن، شروع کنید به دیدن مصاحبه‌های شبیه‌سازی‌شده (Mock Interviews).

و باور کنید، این کل قضیه رو عوض میکنه.

چون وقتی یه نفر بلندبلند فکر می‌کنه، اشتباه می‌کنه، عقب‌نشینی می‌کنه و از انتخاب‌هاش دفاع می‌کنه، تو یاد می‌گیری که چطور فکر کنی، نه فقط کپی کنی.

کانال‌هایی که خیلی کمک کننده میتونن باشن:

🎞 یوتیوب Gaurav Sen: توضیح دادن از صفر و اساس

🎞 یوتیوب Exponent: مصاحبه‌های شبیه‌سازی‌شده با کاندیداهای واقعی

🎞 یوتیوب ByteByteGo: رویکرد بصری و قصه‌گویی‌شون

بهتون یاد میده چطور:

✔️ سؤالات درست و شفاف‌کننده بپرسید.

✔️ نیازمندی‌های عملکردی (Functional) و غیرعملکردی (Non-functional) رو تعریف کنید.

✔️ مراحل طراحی API، انتخاب پایگاه داده و منطق مقیاس‌گذاری رو توضیح بدید.

✔️ و همیشه در مورد مبادله‌ها (Tradeoffs) صحبت کنید، نه فقط انتخاب‌ها.

—-

⬅️ هنوز تموم نشده و ادامه در قسمت بعدی

💡 تا قسمت بعدی مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily

چطوری System Design رو یاد بگیریم قسمت ۲ از ۲

قسمت اول

خب خب بریم برای برای ادامه‌ی مسیر: از طراحی روی کاغذ تا آموزش دادن به بقیه

4️⃣ شروع کن به رسم، حتی اگه روی کاغذ باشه!

یه چیزی که خیلی کمک کنندس: رسم کردن (Drawing) هستش.

ما آرتیست نیستیم. ولی وقتی فلو کار رو از

دیتایبیس → اپ های سرور → لود بالانسر ها → کلانیت

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

وقتی رسم میکنیم:

✔️ فلو درخواست واقعی به نظر می‌رسه.

✔️ میبینیم که Bottlenecks کجاها ممکنه اتفاق بیفته.

✔️ میفهمیم که کش (Cache) رو کجا بذاریم یا کِی از صف (Queue) استفاده کنیم.

هرجا گیر میکنم فقط یه قلم و کاغذ برمیدارم و شروع میکنم به رسم تا دیدم باز تر بشه و اون افکار پراکندم مرتب بشه. پیشنهاد میکنم نوشتن با ماژیک رو شیشه رو هم امتحان کنید، خیلی جوابه :)

5️⃣ با حل کردن مسئله‌های واقعی تمرین کنید

وقتی توی اصول اولیه مطمئن شدید، دست از تماشا کردن بردارید و رسم کردن رو شروع کنید.

این روش تمرینی میتونه کمکتون کنه:

✔️ یه سیستم واقعی انتخاب کنید: واتساپ، یوتیوب، اسنپ‌فود، اینستاگرام.

✔️ اول نیازمندی‌های عملکردی (Functional Requirements) رو بنویسید (سیستم باید چیکار کنه).

✔️ بعد نیازمندی‌های غیرعملکردی (Non-functional Requirements) رو اضافه کنید (مقیاس‌پذیری، دسترس‌پذیری، تأخیر).

✔️ یه تخمین اولیه بزنید (تعداد کاربر، QPS، حجم DB).

✔️ یه معماری سطح بالا (High-level Architecture) طراحی کنید.

🚀 حالا وقت عمیق تر شدن رسیده:

✔️ DB schema
✔️APIs
✔️ Scaling strategies
✔️ Handling failures (مدیریت خطا ها)
✔️ Edge Cases (حالت های خاص)

با رسم هفته ای یه طرح شروع کنید و نه فقط یک راه‌حل، بلکه چندین احتمال مختلف.

چون توی مصاحبه‌ها و کارهای واقعی، به ندرت یه جواب کامل وجود داره. مهم اینه که بتونی توجیه کنی چرا X رو به Y ترجیح دادی.

6️⃣ وقت واقعی کردن رسیده

🔴تئوری تا وقتی پیاده نشه، بی‌فایده‌ست.

بذارید از تجربه خودم بگم. تویه شرکت داشتیم رو یه سیستمی کار میکردیم که به صورت میکروسرویس پیاده شده بود با Go و برای ارتباط داخلی سرویس ها از GRPC استفاده کرده بودیم. اوایل برای سرویس آنالیتیکس از MongoDB استفاده کرده بودیم. اما با زیاد شدن حجم داده ها و کوئری ها (رکورد ها به قدری زیاد بودن که حجم دیسک دیتابیس شده بود 15 گیگ) سیستم شروع کرد به کند شدن. یه راهکار ها این بود که بیایم چنتا نود مختلف بیاریم بالا ولی پیچیدگی ایش زیاد بود، پس شروع کردیم به R&D کردن دیتابیس هایی که به نظر برای این کار مناسب بودن. بعد از تست های اولیه و گرفتن بنچمارک متوجه شدیم که clickhouse میتونه توی مورد ما این بخش از پروژه رو نجات بده. تیم بکند دور هم جمع شدیم و فقط یه ماژیک برداشتیم و ساعت ها روی شیشه سیستم دیزاین های مختلفیو رسم و بررسی کردیم و دیدمون باز شد و در نهایت طرح نهایی. حالا که همه چیز حداقل روی کاغذ اماده بود و کار میکرد باید مهاجرت رو شروع و سیستم جدید رو پیاده میکردیم. در نهایت با یه بررسی درست، بررسی سیستم دیزاین های مختلف و داشتن دید کلی و جزئی از سیستم ، به جایی رسیدیم که میلیون ها داده رو بدون مشکل آنالیز کردیم و نزدیک Real time خروجی نشون میدیم. بعد آروم آروم رفتیم جلو و چیز های دیگه هم مثل RabbitMQ اضافه کردیم. اره الان پروژه بزرگ شده ولی این پروژه ی بزرگ حاصل قدم های کوچیکی بود که برداشتیم ولی نکتش اینکه اگه میخواستیم به آخرش فکر کنیم که همچین چیز بزرگی چطوری قراره ساخته بشه هیچ وقت شروع نمیشد :)

7️⃣ شروع کنید به یاد دادن به بقیه

این آخرین مرحله هست.

وقتی یه چیزی رو توضیح می‌دی، چه به یه جونیور، یه کارآموز، یا توی یه بلاگ، شکاف‌های دانش خودت رو پیدا می‌کنی.

هر بار که یه چیزی رو توضیح میدم اینو میفهمم که:

اگه بتونم خیلی ساده اون رو درس بدم، پس واقعاً خوب فهمیدمش.

درنهایت طراحی سیستم شعبده‌بازی نیست.

فقط کافیه:

✔️ از اصول اولیه شروع کنید.

✔️ به موارد استفاده‌ی دنیای واقعی فکر کنید.

✔️ یه ساختار برای خودتون بسازید.

✔️ هفته‌ای تمرین کنید.

✔️ پشت هر انتخابتون بپرسید «چرا»؟

✔️ و آروم‌آروم بهتر بشید.

حتی اگه روزی ۳۰ دقیقه هم وقت بذارید، بعد از ۳ ماه تفاوت رو می‌بینید.

حرف آخر: قضیه جواب‌ها نیست، قضیه رویکرده!

توی طراحی سیستم، اغلب احساس عدم اطمینان خواهید کرد. این طبیعیه.

چیزی که مهمه اینه که چطور به یک مسئله نزدیک می‌شید.

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

با «یک URL چطور کار می‌کنه؟» شروع کنید و به طراحی اینستاگرام ختم کنید.

تعجب خواهید کرد که قدم به قدم، چقدر پیش رفتید.

—-

💡 مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily

میخواستم بک گراندم رو عوض کنم و دنبال یه جایی بودم که کلی بک گراند خوب و رایگان داشته باشه، پس توی ریپو های گیت هاب سرچ کردم و رسیدم به پروژه lwalpapers . حدودا ۳ سالی هست که اپدیت نشده ولی ۱۰۰۰ تا بک گراند یونیک رو توی خودش جمع آوری کرده.

آدرس وبسایت:

🔗 https://wallpaper.castorisdead.xyz/

—-

💡 مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily

داشتم یه مقاله فوق‌العاده از یه تجربه عملیاتی سنگین می‌خوندم با عنوان: «چطور یک میلیارد رکورد رو از DB1 به DB2 جابجا کردیم؛ بدون Downtime» 🚀

نویسنده مقاله (و تیمش) با یه چالش بزرگ روبرو بودن: دیتابیس قدیمیشون که دیتای حساس مالی (پرداخت، سفارش و...) رو نگه می‌داشت، از ۱ میلیارد رکورد رد شده بود و به شدت کند شده بود, Queryهایی که ثانیه‌ای طول می‌کشید، `Batch Job`ها (کارهایی که دسته‌ای مثل تسویه حساب‌ها) ساعتی طول می‌کشید. Scale کردن (افزایش مقیاس) دیگه جواب نمی‌داد و باید مهاجرت می‌کردن، اونم بدون حتی یک ثانیه Downtime (قطعی).

این خلاصه‌ی قدم‌به‌قدم کاریه که انجام دادن:

1️⃣ جابجایی دیتای قدیمی (Bulk Migration)

برای انتقال Cold data (دیتای قدیمی که دیگه تغییر نمی‌کنه)، نیومدن یه Dump (فایل خروجی) گنده بگیرن. به جاش:

✔️ جدول رو بر اساس رنج Primary Key (کلید اصلی جدول) به Chunk (تکه‌های کوچیک دیتا) تقسیم کردن.

✔️ موقع بارگذاری، ایندکس‌های ثانویه و `Constraint`ها (قیدها) رو غیرفعال کردن (تا سرعت Insert (ثبت دیتا) بالا بره).

✔️ چندتا ورکر رو Parallel (موازی) برای انتقال این تیکه‌ها ران کردن.

✔️ بعد از انتقال هر تیکه، یه Checksum (یه جور کد محاسباتی برای چک کردن یکی بودن دیتا) می‌گرفتن تا مطمئن بشن دیتا دقیقاً کپی شده.

2️⃣ مدیریت ترافیک زنده (Dual Writes)

چالش اصلی، دیتای جدیدی بود که همزمان با مهاجرت داشت وارد می‌شد.

✔️ اپلیکیشن رو طوری تغییر دادن که Dual Writes (نوشتن همزمان در دو دیتابیس) انجام بده (یعنی هر دیتای جدید رو همزمان هم تو دیتابیس قدیمی و هم تو دیتابیس جدید بنویسه).

✔️ برای اینکه مطمئن بشن دیتایی گم نمی‌شه، اگه نوشتن تو دیتابیس جدیده خراب می‌شد، اون رویداد (event) رو می‌نداختن توی یه `Retry Queue` کافکا (صفی برای کارهای شکست‌خورده که باید دوباره امتحان بشن).

✔️ یه Consumer (سرویسی که از صف کافکا دیتا می‌خونه) جدا اون صف رو می‌خوند و اونقدر تلاش می‌کرد تا بالاخره تو دیتابیس جدیده هم ثبت بشه.

✔️ برای جلوگیری از تکراری ثبت شدن دیتا (موقع تلاش مجدد)، همه‌ی نوشتن‌ها رو با آیدی یکتا Idempotent (یعنی اگه یه کاری رو چند بار هم اجرا کنی، نتیجه نهایی یکی باشه) کرده بودن.

3️⃣ تست پنهانی در پروداکشن (Shadow Reads)

خب، دیتاها سینک بودن. ولی آیا دیتابیس جدیده زیر بار واقعی جواب می‌داد؟

✔️ اینجا از Shadow Reads (خوندن پنهانی از دیتابیس جدید برای تست) استفاده کردن.

✔️ مشتری‌ها هنوز داشتن از دیتابیس قدیمی می‌خوندن اما در پشت صحنه، اپلیکیشن همون `Query` رو روی دیتابیس جدیده هم می‌زد و نتایج رو با هم مقایسه می‌کرد.

✔️ این کار باعث شد کلی باگ ریز ولی حیاتی رو پیدا کنن که تو تست‌ها معلوم نمی‌شد: مثلاً تفاوت رفتار Timezone ها (منطقه‌های زمانی)، تبدیل `NULL`ها (مقادیر پوچ) به مقادیر پیش‌فرض، و تفاوت در Collation (قواعد مرتب‌سازی و مقایسه متن‌ها) (که باعث می‌شد مرتب‌سازی نتایج فرق کنه).

4️⃣ لحظه جابجایی نهایی (The Cutover)

روز Cutover (لحظه جابجایی کامل و سوییچ کردن)، ریسک اصلی این بود که Cache (حافظه موقت) دیتابیس جدیده «سرد» (Cold) بود و اولین کوئری‌ها ممکن بود خیلی کند باشن.

✔️ قبل از سوییچ، با اجرای کوئری‌های مصنوعی، کش دیتابیس جدید رو Pre-warm (گرم کردن کش با دیتای الکی) کردن.

✔️ ساعت ۴:۳۰ صبح (کمترین ترافیک) با زدن یه Feature Flag (یه جور کلید نرم‌افزاری برای روشن/خاموش کردن قابلیت‌ها)، همه‌ی Read ها (خوندن‌ها) رو به سمت دیتابیس جدید فرستادن. (برای اطمینان، Dual Writes رو هنوز روشن نگه داشتن تا راه برگشت امن داشته باشن).

5️⃣ رصد کردن (Observability) 📊

نویسنده میگه چیزی که واقعاً نجاتشون داد، SQL خفن نبود، بلکه Observability (قابلیت رصد کامل سیستم) بود. اونا وسواسی همه‌چیز رو مانیتور می‌کردن:

✔️ با Replication Lag (میزان عقب بودن دیتابیس‌های کپی از دیتابیس اصلی)

✔️ با `Deadlock`ها (وقتی دوتا پروسه قفل منتظر هم می‌مونن)

✔️ با Cache Hit Ratio (درصدی از دیتا که از کش خونده می‌شه نه از دیسک)

✔️ با شمارنده‌ی عدم تطابق نتایج در Shadow Reads

✔️ و از همه مهم‌تر: `KPI`های بیزینسی (شاخص‌های کلیدی عملکرد مثل سفارش در دقیقه).

ما چی می تونیم یاد بگیریم؟ 💡

مهاجرت‌های بزرگ، یه «مسئله دیتابیسی» نیستن، بلکه یه «مسئله System Design (طراحی سیستم)» هستن.

شما یه میلیارد ردیف رو یهو جابجا نمی‌کنید، بلکه batch امن به batch امن»، «ورودی WAL (فایلی که دیتابیس قبل از هر کاری، تغییرات رو اول اونجا می‌نویسه) به WAL» و «Checksum به Checksum» این کار رو می‌کنید.

در نهایت: Zero Downtime (قطعی صفر) شانسی نیست؛ طراحیه.

—-

💡 مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily

تا حالا فکر کردید وقتی تو «اسنپ» یا «گوگل مپس» مبدأ و مقصد رو می‌زنید، چطوری تو یه چشم به هم زدن «بهترین» مسیر رو از بین این همه کوچه و خیابون پیدا می‌کنه؟

یا مثلاً تو یه بازی کامپیوتری، اون هوش مصنوعی (AI) دشمن چطوری انقدر قشنگ شما رو پیدا می‌کنه و کوتاه‌ترین راه رو برای رسیدن بهتون انتخاب می‌کنه؟

اینا همشون دارن یه مسئله‌ی معروف به اسم «پیدا کردن کوتاه‌ترین مسیر» (Shortest Path) رو حل می‌کنن. تو این پست میخوایم بریم سراغ دوتا از غول‌های حل این مسئله: دایکسترا (Dijkstra) و اِی-اِستار (A*).

1️⃣ الگوریتم دایکسترا (Dijkstra): کاوشگرِ وظیفه‌شناس (ولی کور!)

این الگوریتم که اسمش رو از خالقش، ادسخر دایکسترا، گرفته، کوتاه‌ترین مسیر از مبدأ رو پیدا میکنه.

چطوری کار می‌کنه؟

✔️ از نقطه‌ی شروع (Source) کارش رو شروع می‌کنه.

✔️ یه «صف اولویت» (Priority Queue) داره. کارش اینه که در هر مرحله، گرهی (node) رو برای بررسی انتخاب می‌کنه که کمترین هزینه (cost) رو از مبدأ داشته باشه.

✔️ این الگوریتم «کور» (Uninformed) ـه. یعنی چی؟ یعنی اصلاً نمی‌دونه مقصد کجاست! 😅

✔️ در نتیجه، جستجوش به صورت «یکنواخت» (مثل Uniform Cost Search) پخش می‌شه. کارش اینه که به صورت سیستماتیک کوتاه‌ترین مسیر از مبدأ به همه‌ی نقاط دیگه رو حساب کنه تا اینکه بالاخره اتفاقی به مقصد ما هم برسه.

نتیجه این روش چیه؟

مزیت: اینه که تضمین می‌کنه کوتاه‌ترین و بهینه‌ترین مسیر رو پیدا می‌کنه (بهش میگن Optimal)، البته به شرطی که وزن منفی (negative weight) تو گراف نداشته باشیم (مثلاً راهی که به جای هزینه داشتن، بهت زمان اضافه کنه!).

عیب: چون «کوره» و نمی‌دونه هدف کجاست، کلی زمان و انرژی صرف بررسی گره‌هایی می‌کنه که اصلاً در جهت مقصد نیستن. (مثلاً می‌خوای از تهران بری شمال، این بنده خدا همزمان مسیرهای به سمت اصفهان رو هم چک می‌کنه، چون شاید یه راه عجیبی از اونجا باشه!).

2️⃣ الگوریتم A* (A-Star): کاوشگرِ هوشمند (و هدفمند)

اِی-اِستار (A*) نسخه‌ی باهوش‌تر و «زرنگ»ترِ دایکستراست. می‌تونیم بگیم A* همون دایکسترای خودمونه، فقط یه «قطب‌نما» یا «GPS» هم دستش گرفته.

چطوری کار می‌کنه؟

✔️ اِی-استار هم مثل دایکسترا، هزینه‌ای که واقعاً تا الان طی کرده (یعنی مسافت واقعی از مبدأ تا گره فعلی) رو حساب می‌کنه. (ریاضیش رو بخوامی بگیم g(n)).

✔️ اما، برگ برنده‌اش اینجاست: اون یه «حدس هوشمندانه» (Heuristic) هم می‌زنه که چقدر فکر می‌کنه تا مقصد مونده. (ریاضیش رو بخوامی بگیم h(n)).

هیوریستیک یعنی چی؟

خیلی ساده‌ست: در مسیریابی، بهترین هیوریستیک همون «فاصله خط صاف» خودمونه. یعنی تو نقشه یه خط صاف از جایی که هستی تا مقصد بکشی.

✔️ پس اِی-استار در هر قدم، میره سراغ گرهی که مجموعِ «هزینه واقعی تا اینجا» + «هزینه تخمینی تا مقصد» (f(n) = g(n) + h(n)) از همه کمتر باشه.

نتیجه این هوشمندی چیه؟

مزیت: چون «آگاه» (Informed) هست و یه «حس جهت‌یابی» داره، جستجوی خودش رو مستقیم می‌بره به سمت هدف. دیگه الکی همه‌جا رو نمی‌گرده و در نتیجه خیلی خیلی سریع‌تره و گره‌های (nodes) کمتری رو بررسی می‌کنه.

عیب (یا نکته مهم): همه‌چی به «خوب» بودن اون حدس (Heuristic) بستگی داره. اگه هیوریستیک شما «قابل قبول» (Admissible) نباشه (یعنی بدبین باشه و فاصله رو بیشتر از حد واقعی حدس بزنه)، A* ممکنه گول بخوره و اصلاً جواب بهینه (Optimal) رو پیدا نکنه!


💡 خب، ما چی یاد گرفتیم؟ (Dijkstra vs A*)

دایکسترا: «کور»ـه و جستجوش (UCS) در تمام جهات پخشه. هدفش پیدا کردن کوتاه‌ترین راه از مبدأ به همه‌ی نقاطه.

اِی-اِستار: «هوشمند»ـه و با کمک هیوریستیک به سمت هدف می‌گرده. هدفش پیدا کردن کوتاه‌ترین راه از مبدأ به یک مقصد مشخصه.

حالا یه نکته:

الگوریتم دایکسترا در واقع یه حالت خاص از الگوریتم A* هست!

چطوری؟ اگه توی A*، اون «حدس هوشمندانه» (h(n)) رو برای همه‌ی گره‌ها صفر در نظر بگیری (یعنی عملاً بگی: «آقا من هیچ حدسی ندارم!»)، الگوریتم A* دقیقاً تبدیل می‌شه به دایکسترا!

پس کی از کدوم استفاده کنیم؟

برو سراغ Dijkstra:

* وقتی می‌خوای کوتاه‌ترین مسیر از یک نقطه به تمام نقاط دیگه رو بدونی (مثلاً تو پروتکل‌های روتینگ شبکه مثل OSPF که باید بدونن بهترین راه تا همه‌ی روترهای دیگه چیه).

برو سراغ A*:

* وقتی یک مبدأ و یک مقصد مشخص داری (۹۹٪ کاربردهای ما مثل GPS، مسیریابی تو بازی‌ها، رباتیک و...).

* وقتی سرعت برات مهمه و می‌تونی یه هیوریستیک خوب (مثل فاصله خط صاف) حساب کنی.

دفعه‌ی بعدی که «نشان» رو باز کردید یا تو یه بازی مثل The Last of Us دیدید که دشمن چقدر هوشمندانه دنبالتون میاد، یادتون باشه که یه چیزی شبیه A* پشت صحنه داره کار می‌کنه.

—-

💡 مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily

حالا که همه جا صحبت از AI و اخبارشه، بیاید یه لحظه ترمز کنیم و یه ابزار کاربردی متفاوت رو یاد بگیریم.

تا حالا شده بخواید یه پروژه شخصی (Side Project) رو تست کنید، یه نمونه‌کار بیارید بالا یا صرفاً یه وبسایت برای خودتون داشته باشید، ولی نمی خواهید برای دامین (Domain) هزینه کنید؟
یا شایدم رفتید سراغ دامین‌های رایگان ولی دیدید همشون ساب‌دامین (Subdomain) هستن و حسابی تو ذوق میزنن؟

امروز میخوایم بریم سراغ یه پروژه اوپن‌سورس به اسم DigitalPlat Domain.
شعارشون خیلی جذابه: «دامین رایگان برای همه»

🌐 داستان چیه؟

پروژه DigitalPlat Domain یه حرکت غیرانتفاعی (Nonprofit) هست که توسط The Hack Foundation پشتیبانی میشه. هدفشون اینه که دسترسی به وب رو برای همه راحت‌تر کنن. برخلاف خیلی از سرویس‌های دیگه که اولش رایگانن و بعد پول میخوان، این پروژه واقعاً رایگانه.

🛠 چه ویژگی‌هایی داره که به درد ما میخوره؟

✔️ دامین واقعی، نه ساب‌دامین: اینجا خبری از آدرس‌های طولانی و زشت نیست. شما دامین‌هایی با پسوند‌های خاص مثل .US.KG ، .DPDNS.ORG یا .QZZ.IO میگیرید.
✔️ کنترل کامل DNS: این خیلی مهمه! شما می‌تونید دامینتون رو به سرویس‌های مدیریت DNS محبوب مثل Cloudflare متصل کنید.
✔️ بدون هزینه‌های مخفی: نه هزینه ثبت داره، نه هزینه تمدید سالانه.
✔️ امنیت و اعتماد: چون اوپن‌سورسه و پشتش یه موسسه خیریه معتبره، نگرانی کمتری بابت پریدن دامین یا سوءاستفاده وجود داره.

💡 کجا به کارمون میاد؟

✔️ وقتی میخوای یه پروتوتایپ (Prototype) سریع بیاری بالا.
✔️ برای پروژه‌های دانشجویی و آموزشی.
✔️ ساختن بلاگ شخصی یا پورتفولیو بدون هزینه.
✔️ تست کردن تنظیمات سرور و شبکه قبل از خرید دامین اصلی.

🚀 چطوری بگیریم؟
کافیه برید توی دشبورد سایتشون، اسم دامین مد نظرتون رو سرچ کنید و اگه خالی بود، ثبتش کنید و DNS ها رو ست کنید.

🔗 لینک پروژه و داشبورد:

https://dash.domain.digitalplat.org/


🔗منبع پست:

https://www.opensourceprojects.dev/post/1959600649026302372



—-

💡 مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily

تولدمون مبارک باشه 🎁

امروز MdDaily در کنار تک تک شما عزیزان ۳ ساله شد ❤️

ایده ی کانال از کجا اومد؟

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

اسم Md از کجا اومد؟

خب اسم خودم ماهان عه، گفتم ایول بذار Mahan رو با Developer ترکیب کنم

مخففش میشه Md و اینجوری شد که Md Daily خلق شد :)


برای فصل جدید کانال خوشحال میشم نظرات و پیشنهادات شما رو بدونم :)

و در اخر قدردان تک تک شما عزیزان هستم که با وجودتون قلب md daily میزنه 🫶

وقتی عشق به کد زدن ته می‌کشه: قصه تلخ برن‌آوت (Burnout)

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

اکثراً فکر می‌کنن برن‌آوت یعنی فقط خستگی وحشتناک یا اضطراب شدید. اینا هستن، ولی نشونه‌ی اول معمولاً ساده‌تر و موذی‌تره: چیزی که قبلاً عاشقش بودی، دیگه بهت حال نمیده. واسه خیلی از ما دولوپرها، کد زدن فقط شغل نیست؛ عشقه. ولی وقتی این حس عوض میشه و کد زدن میشه یه «وظیفه»، یه «زور» یا صرفاً «فشار کار»، یعنی زنگ خطر به صدا دراومده.

نقطه جوش: وقتی مغز شات‌دان می‌کنه

ددلاین‌ها که روی هم تلنبار می‌شن، اوضاع بیریخت‌تر میشه. خسته بیدار میشی، خسته می‌شینی پشت سیستم، آخر شب هم جنازه‌تری. این فقط خستگی جسمی نیست؛ یه پوچیِ ذهنیه. ادیتور رو باز می‌کنی، زل می‌زنی به کدها ولی دریغ از یه ذره حس؛ نه ایده‌ای، نه جرقه‌ای، نه اون غریزه همیشگی. مغزت رسماً خالیه.

تله‌ی «برنامه‌نویسِ سریع و خفن»

برنامه‌نویسا همش می‌خوان ثابت کنن که سریع و قابل اعتمادن. این ویژگی خوبیه، ولی می‌تونه تبدیل بشه به یه تله‌ی خطرناک. وقتی نشون بدی که سریعی، حس می‌کنی مجبوری همیشه سریع بمونی و کم‌کم «فشار» میشه حالتِ دیفالت تو. فول‌-استک کار کردن، راضی نگه داشتن کلاینت‌ها و تحویل مداوم فیچرها، همه‌ش با هم میشه حس دائمی «غرق شدن».

فشار تکنولوژی و فرهنگی که باهات روراست نیست

دولوپرها دائماً با «سندروم ایمپاستر» درگیرن. فشارِ اینکه باید مدام چیز یاد بگیری و با فریم‌ورک‌های جدید آپدیت باشی، واقعاً سنگینه. مقایسه کردن خودت با بقیه هم که قاتلِ حال‌خوبه. مشکل فرهنگِ «بهره‌وری سمی» (Toxic Productivity) و مقایسه‌ست که زیرپوستی اونایی رو که تا مرز ذوب شدنِ مغز کار می‌کنن، تشویق می‌کنن.

راه واقعی برگشت (چی جواب میده، چی نه)

چیزی که می‌تونه جلوی این سقوط آزاد رو بگیره، «دیسیپلین» نیست؛ استراحت مطلقه.

چی واقعاً کمکت می‌کنه؟

✔️ دوری کامل از اسکرین: مانیتور، لپ‌تاپ، گوشی؛ همه رو بذار کنار.

✔️وقت گذروندن با آدمای واقعی: برو پیش رفقا و خانواده.

✔️بازگشت به تنظیمات کارخانه: برو سراغ تفریحات غیردیجیتالِ قدیمی.

✔️کارای غیرمفید: کارایی بکن که اصلاً قرار نیست خروجیِ خاصی داشته باشن.

چی کمک نمی‌کنه؟

ساید پراجکت (Side Project) زدن: برخلاف تصور، اینکه بری سراغ پروژه شخصی که فکر می‌کنی حالتو خوب می‌کنه، تو این شرایط فقط باطریت رو خالی‌تر می‌کنه.

ریکاوری شدن مثل دکمه‌ی خاموش/روشن نیست؛ یه ریست (Reset) آرومه که زمان می‌بره.

درسی که گرون تموم میشه

اگه می‌شد با گذشته حرف زد، باید به اون برنامه‌نویسی که تا پاسی از شب بیداره گفت: «آقا/خانم! مرخصی بگیر. حتی اگه عاشقِ کارتی. مخصوصاً اگه عاشقِ کارتی.» عاشقِ کار بودن تو رو ضدضربه نمی‌کنه، آسیب‌پذیرترت می‌کنه؛ چون مرزِ بین «اشتیاق» و «فشار» واسه عاشقای کار خیلی راحت گم میشه.

نشونه اصلی: وقتی تفریحت شروع کرد بهت حسِ «شغل» دادن، وقتشه بکشی کنار.

نقش تیم‌ها و شرکت‌ها

برن‌آوت درسته که یه تجربه شخصیه، ولی شرکت‌ها هم توش دخیـلن. یه تغییر کوچیک تو رویکرد تیم می‌تونه حیاتی باشه: قبل از اینکه سر یه فیچر یا ددلاین توافق کنید، با دولوپرها حرف بزنید؛ نه بعدش که کار از کار گذشت. این کار جلوی اون فشار خاموشی رو که ذره‌ذره آدم‌ها رو فرسوده می‌کنه، می‌گیره.

چندتا راهکار واسه اینکه کم نیاری

واسه دوام آوردن تو این مسیر، تغییرات کوچیک خیلی اثر دارن:

✔️ به محض دیدن اولین نشونه‌ها، واقعی استراحت کن.

✔️ وقتی لازمه، ریموت کار کن و واسه خودت فضای شخصی بساز.

✔️ جای اینکه هشدارهای اطرافیان رو ایگنور کنی، بهشون گوش بده.

✔️ واسه کم کردن بار ذهنی، همه چی رو نوت‌برداری کن.

ختم کلام: این یه باگ نیست، فیچره!

برن‌آوت «لوس‌بازیِ کارهای پشت‌میزنشینی» نیست. این قضیه ربطی به خستگیِ تایپ کردن نداره؛ بحثِ فشار ذهنی، انتظارات غیرواقعی، بحران هویت و حس همیشگیِ «عقب موندن از تکنولوژی»ـه. این فشار واقعیه و می‌تونه حتی عاشق‌ترین برنامه‌نویس‌ها رو هم از پا دربیاره.

اگه عاشقِ کدنویسی هستی، مجبور نیستی ۲۴ ساعته بدوی دنبالش. به خودت اجازه بده استراحت کنی و دیسکانکت شی. بذار اشتیاقت نفس بکشه. اگه واقعاً عاشقش باشی، لازم نیست به زور نگه‌ش داری؛ وقتی بهش فضا بدی، خودش برمی‌گرده.

—-

💡 مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily

کد تمیز افسانه نیست؛ فقط دوام نمیاره

مشکل این نیست که هیچ‌کس کد تمیز نمی‌نویسه.
مشکل اینه که کد تمیز تو پروژه‌های واقعی، زیر فشارِ کار کم‌کم داغون میشه.

اگه یه مدت تو یه تیم کار کرده باشی، حتماً دیدی: کدی که اوایل مرتب و قابل فهم بوده، با اضافه شدن فیچرهای عجله‌ای، ددلاین‌ها و تصمیم‌های لحظه‌ای، کم‌کم شلوغ و سخت‌فهم میشه. نه به این خاطر که برنامه‌نویسا بلد نیستن، به این خاطر که واقعیت پروژه این شکلیه.

✨ اصلاً کد تمیز یعنی چی؟

کد تمیز یه چیز کاملاً سلیقه‌ای نیست. بعضی چیزاش واضحه: اسم متغیر و فانکشن باید درست باشه، هر تیکه کد باید کار خودش رو بکنه، وابستگی‌ها نباید قاطی‌پاطی باشن و بشه راحت تغییرش داد بدون اینکه کل سیستم بریزه به هم.
البته همه‌چیز هم قانون خشک نداره. کدی که امروز تمیزه، ممکنه چند ماه دیگه فقط قابل تحمل باشه.

تعریف ساده‌ش اینه: کدی که تغییر دادنش از نوشتنش کم‌هزینه‌تره.

🖥 پروژه‌ها از اول داغون نیستن، داغون میشن.

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

🖥 پروتوتایپی که قرار نبود بمونه.

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

🖥 ریفکتوری که تموم نمیشه.

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

سنیور سخت‌گیر همیشه خوب نیست.

سنیوری که فقط ایراد می‌گیره و فضا رو ترسناک می‌کنه، به تمیز شدن کد کمک نمی‌کنه. باعث میشه بقیه یواشکی کد بزنن که فقط کار راه بیفته. اینجوری کد بد قایم میشه، نه اینکه درست بشه.

راه‌حل‌های موقت، وقتی دائم میشن دردسر می‌سازن.

یه هک سریع یا فلگ موقتی بعضی وقتا لازمه. مشکل وقتی شروع میشه که اسم درست نداره، کسی نمی‌دونه چرا هست، و معلوم نیست کی باید حذفش کنه. اون موقع میشه یه تیکه خطرناک که همه ازش فرار می‌کنن.

🤖 هوش مصنوعی کد زشت نمی‌نویسه، کد بی‌مسئولیت می‌نویسه.

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

📊 بیزنس و کد دشمن هم نیستن.

بیزنس می‌خواد زنده بمونه، برنامه‌نویس می‌خواد سیستم نخوابه. نه سرعت بدون فکر جواب میده، نه وسواس بیش از حد. کدی که نشه راحت تغییرش داد، بیزنس رو کند می‌کنه. بیزنسی هم که به کد اهمیت نده، بعداً هزینه‌شو میده.

🤔 پس بی‌خیال کد تمیز بشیم؟ نه.

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

🔗 برای نوشتن این پست از این منبع خیلی الهام گرفته شده:
https://dev.to/sylwia-lask/nobody-writes-clean-code-we-all-just-pretend-11d1

—-

💡 مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily