Md Daily

описание

راجب مقالات و مستندات فنی یا غیر فنی که میخونم و علایقم اینجا مینویسم :) گروه کانال: https://t.me/MdDailyGap کورس ها: https://t.me/MdDaily/395 وبلاگ: https://mddaily.ir

← к каналу @MdDaily

754

подписчиков

Охват к подписчикам

108,4%

ERR

Реакции к просмотрам

1,45%

289 на 24 постов

Пересылки к просмотрам

2,24%

447

Постов в день

0,6

всего 24

Где отзываются чаще

доля реакций к просмотрам

7 авг.خِفتم کن! وقتی با AI کد می‌زنید، بزرگ‌ترین سم اینه که شما فقط بگی چی می‌خوای و اونم یه مشت کد بپاشه جلتون و شما هم بی‌فکر فقط «Accept» بزنید. اینجوری بعد از نیم ساعت کلاً پرت می‌شید که پروژه داره به کجا میره و کنترل از دستتون در میره. تکنیک اینه که بهش بگی: «Grill me» (خفتم کن!) درواقع داری بهش می‌گی قبل از اینکه دست به کد بشی، حتی قبل از اینکه به پلن برسی، زیر و بم قضیه رو ازم بکش بیرون. سوالای سخت بپرس، حالت‌های خاص (Edge cases) رو رو کن و همه‌چیز رو به چالش بکش. ایجنت شروع می‌کنه به سوال و جواب‌ها و در اکثر مواقع چند جواب ممکن رو پیشنهاد میده و گزینه پیشنهادی خودش رو هم با ذکر دلیل میگه، ولی تو همیشه میتونی جواب خودت رو اضافه کنی یا در مورد سوال باهاش بحث کنی. گاهی سوال‌های ارزشمندی می‌پرسه که تو حتی بهش فکر هم نکرده بودی. در نهایت یه پلن تر و تمیز و حساب شده تحویل میگیری که آماده پیاده‌سازیه. با این کار: ۱. فهم شما و AI از مسئله و نقشه راه دقیقاً یکی میشه. ۲. خودت هوشیار می‌مونی، می‌فهمی داری چیکار می‌کنی و فرمان دست خودته. ۳. برنامه‌نویسی با AI از حالت خسته‌کننده و رباتیک درمیاد و میشه یه همکاری واقعی. این مفهوم به نظر ساده میرسه و حتی اگه فایل skillهای مرتبط و مشابه grill-me رو نگاه کنید می‌بینید چند خط بیشتر نیست. ولی واقعاً تاثیر فوق‌العاده‌ای میذاره. اگه MCPهای کافی، به‌خصوص مربوط به resourceهای داخلی شرکت یا پروژه‌تون رو هم فعال داشته باشید، روند سوال‌وجواب‌ها و نتیجه کار واقعاً شگفت‌زده‌تون می‌کنه. پیشنهاد می‌کنم حتماً یک بار هم که شده امتحانش کنید. استاد @mattpocockuk توی این مقاله خیلی خوب و دقیق مفهومش رو باز کرده و خودِ skill رو هم پابلیش کرده که می‌تونید راحت نصبش کنید و رو ابزاراتون استفاده کنید: 🔗 https://www.aihero.dev/skills-grill-me —- 📲 منبع پست <Nick> 🆔 @MdDaily3,66%
21 дек.💡💡💡💡💡💡💡💡 🍸🍿. ❤️❤️❤️. 🍿🍸 🍉🍉🍉🍉🍉🍉🍉🍉 داشتم فکر میکردم به مناسبت یلدا چه متنی بنویسم، دیدم نیاز به پیچدگی خاصی نیست پس مستقیم میگم یلداتون مبارک و همیشه لبتون خندون باشه ❤️🫶 - ماهان —- 💡 امشب یک دقیقه ییشتر کنجکاو بمونید :) 🆔 @MdDaily3,54%
27 нояб.تولدمون مبارک باشه 🎁 امروز MdDaily در کنار تک تک شما عزیزان ۳ ساله شد ❤️ ایده ی کانال از کجا اومد؟ تویه گروه دوستانه بودیم و راجب چیزایی که میخوندم اونجا مینوشتم و همین انگیزه ای شد که تصمیم بگیرم تجربه هام و چیزایی که راجبشون میخونم رو تو یه جای عمومی تری منتشر کنم اسم Md از کجا اومد؟ خب اسم خودم ماهان عه، گفتم ایول بذار Mahan رو با Developer ترکیب کنم مخففش میشه Md و اینجوری شد که Md Daily خلق شد :) برای فصل جدید کانال خوشحال میشم نظرات و پیشنهادات شما رو بدونم :) و در اخر قدردان تک تک شما عزیزان هستم که با وجودتون قلب md daily میزنه 🫶3,52%
13 авг.без подписи3,13%
5 нояб.تا حالا فکر کردید وقتی تو «اسنپ» یا «گوگل مپس» مبدأ و مقصد رو می‌زنید، چطوری تو یه چشم به هم زدن «بهترین» مسیر رو از بین این همه کوچه و خیابون پیدا می‌کنه؟ یا مثلاً تو یه بازی کامپیوتری، اون هوش مصنوعی (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* پشت صحنه داره کار می‌کنه. —- 💡 مثل همیشه کنجکاو بمونید :) 🆔 @MdDaily2,71%
13 авг.без подписи2,70%
24 окт.بعد از این همه مدتی که تقریبا اکثر ما ابزار های هوش مصنوعی شده جزوی از زندگیشون چه کاری یا چه روزمره یا هرچی. طبق چیزی که از استفاده ی افراد و خودم دیدم، تا از قبل تویه چیزی اطلاعات نداشته باشی و best practice ها رو ندونی، هیچ ابزار هوش مصنوعی ای نمیتونه برات معجزه کنه! من تخصصی توی حوزه های هنری ندارم ولی دوس دارم مثال این پست رو یه مثال خروجی تصویر بزنم تا ملموس تر باشه. این دوتا پرامپت رو دادم به sora و خروجی هاشم که تو عکس های پست میتونید ببینید: 🎨 پرامپت اول (ساده و مبهم): "یه سیب که یدونه شیرموز دستشه و سوار یه ماشین تو بیابون داره میره" 🎬 پرامپت دوم (با خلاقیت و جزئیات): "یک سیب بامزه با چهره‌ی انسانی که دستش یک لیوان شیرموز سرد با خامه و نی رنگی گرفته، سوار بر یک ماشین کلاسیک قرمز در حال حرکت در جاده‌ای خاکی وسط بیابان طلایی است. نور خورشید در حال غروب، سایه‌های بلند و رنگ‌های گرم نارنجی و طلایی روی صحنه پخش کرده. گرد و غبار در هوا پخش شده و در پس‌زمینه کوه‌های نرم و آسمانی با ابرهای نازک دیده می‌شود. ترکیب‌بندی از زاویه‌ی پایین (low-angle) گرفته شده تا حس قدرت و ماجراجویی را القا کند. فوکوس روی سیب و ماشین است، پس‌زمینه کمی محو (bokeh) شده. سبک تصویر واقعی (cinematic realism) با رنگ‌های زنده و جزئیات بالا. عمق میدان (depth of field) و نور طبیعی رعایت شود. Ultra detailed, cinematic lighting, golden hour photography, 4K, high contrast, vibrant colors, shallow depth of field." پ ن: وی شیرموز خیلی دوس داره 😂 👈 همین نتایج رو شما میتونید توی تمام حوزه ها ببینید، یه برنامه نویسی که best practice ها رو میدونه و با اون تکنولوژی که داره ازش استفاده میکنه اشناس و میدونه کجا باید چی استفاده بشه خروجیه کارش میشه اون پرامپت دومیه و اونی هم که فقط به ابزار میگه خودت هرجوری میدونی بزن ، هر نوع خروجیه غیر قابل پیش بینی ایو میتونه بگیره . نکتش اینکه من راجب prompt engineering حرف نمیزنم! چون prompt engineering میاد میگه چطوری به ai بگیم چیکار کنه ولی من راجب مرحله ی قبل از اون دارم حرف میزنم و اون چیستیه :) اصلا اول بدونیم دقیقا چی میخوایم، باید چطوری باشه از چه چیز هایی باید استفاده بشه، best practice های اون چیز چیا هستند تا بعد حالا بیایم سراغ اینکه چطوری به ai بگیم چیکار کنه. در نتیجه ابزار های هوش مصنوعی با پیشرفتشون به کسی که میدونه میخواد چیکار کنه کمک میکنن سریع تر اون کار رو انجام بده و به کسی هم که نمیدونه میخواد چیکار کنه کمک میکنن سریع تر بفهمه احتمالا چه چیزایی رو نمیدونه و به خروجی ای که میخواد نرسه. کتاب بخونیم، تجربه کنیم و از تجربیات بقیه یاد بگیریم و لذت یاد گیری و کنجاویمون رو زنده نگه داریم 🧠 —- 💡 مثل همیشه کنجکاو بمونید :) 🆔 @MdDaily2,46%
5 дек.وقتی عشق به کد زدن ته می‌کشه: قصه تلخ برن‌آوت (Burnout) برن‌آوت یا همون فرسودگی شغلی، این‌طوری نیست که یهو مثل صاعقه بزنه بهت. داستان خیلی بی‌سروصداتر از این حرفاست و معمولاً ماه‌ها قبل از اینکه متوجه بشی یه جای کار می‌لنگه، شروع شده. حتی وقتی پروژه‌ها رو خوب هندل می‌کنی هم ممکنه این فرسودگی داشته زیرپوستی رشد می‌کرده. اکثراً فکر می‌کنن برن‌آوت یعنی فقط خستگی وحشتناک یا اضطراب شدید. اینا هستن، ولی نشونه‌ی اول معمولاً ساده‌تر و موذی‌تره: چیزی که قبلاً عاشقش بودی، دیگه بهت حال نمیده. واسه خیلی از ما دولوپرها، کد زدن فقط شغل نیست؛ عشقه. ولی وقتی این حس عوض میشه و کد زدن میشه یه «وظیفه»، یه «زور» یا صرفاً «فشار کار»، یعنی زنگ خطر به صدا دراومده. نقطه جوش: وقتی مغز شات‌دان می‌کنه ددلاین‌ها که روی هم تلنبار می‌شن، اوضاع بیریخت‌تر میشه. خسته بیدار میشی، خسته می‌شینی پشت سیستم، آخر شب هم جنازه‌تری. این فقط خستگی جسمی نیست؛ یه پوچیِ ذهنیه. ادیتور رو باز می‌کنی، زل می‌زنی به کدها ولی دریغ از یه ذره حس؛ نه ایده‌ای، نه جرقه‌ای، نه اون غریزه همیشگی. مغزت رسماً خالیه. تله‌ی «برنامه‌نویسِ سریع و خفن» برنامه‌نویسا همش می‌خوان ثابت کنن که سریع و قابل اعتمادن. این ویژگی خوبیه، ولی می‌تونه تبدیل بشه به یه تله‌ی خطرناک. وقتی نشون بدی که سریعی، حس می‌کنی مجبوری همیشه سریع بمونی و کم‌کم «فشار» میشه حالتِ دیفالت تو. فول‌-استک کار کردن، راضی نگه داشتن کلاینت‌ها و تحویل مداوم فیچرها، همه‌ش با هم میشه حس دائمی «غرق شدن». فشار تکنولوژی و فرهنگی که باهات روراست نیست دولوپرها دائماً با «سندروم ایمپاستر» درگیرن. فشارِ اینکه باید مدام چیز یاد بگیری و با فریم‌ورک‌های جدید آپدیت باشی، واقعاً سنگینه. مقایسه کردن خودت با بقیه هم که قاتلِ حال‌خوبه. مشکل فرهنگِ «بهره‌وری سمی» (Toxic Productivity) و مقایسه‌ست که زیرپوستی اونایی رو که تا مرز ذوب شدنِ مغز کار می‌کنن، تشویق می‌کنن. راه واقعی برگشت (چی جواب میده، چی نه) چیزی که می‌تونه جلوی این سقوط آزاد رو بگیره، «دیسیپلین» نیست؛ استراحت مطلقه. چی واقعاً کمکت می‌کنه؟ ✔️ دوری کامل از اسکرین: مانیتور، لپ‌تاپ، گوشی؛ همه رو بذار کنار. ✔️وقت گذروندن با آدمای واقعی: برو پیش رفقا و خانواده. ✔️بازگشت به تنظیمات کارخانه: برو سراغ تفریحات غیردیجیتالِ قدیمی. ✔️کارای غیرمفید: کارایی بکن که اصلاً قرار نیست خروجیِ خاصی داشته باشن. چی کمک نمی‌کنه؟ ساید پراجکت (Side Project) زدن: برخلاف تصور، اینکه بری سراغ پروژه شخصی که فکر می‌کنی حالتو خوب می‌کنه، تو این شرایط فقط باطریت رو خالی‌تر می‌کنه. ریکاوری شدن مثل دکمه‌ی خاموش/روشن نیست؛ یه ریست (Reset) آرومه که زمان می‌بره. درسی که گرون تموم میشه اگه می‌شد با گذشته حرف زد، باید به اون برنامه‌نویسی که تا پاسی از شب بیداره گفت: «آقا/خانم! مرخصی بگیر. حتی اگه عاشقِ کارتی. مخصوصاً اگه عاشقِ کارتی.» عاشقِ کار بودن تو رو ضدضربه نمی‌کنه، آسیب‌پذیرترت می‌کنه؛ چون مرزِ بین «اشتیاق» و «فشار» واسه عاشقای کار خیلی راحت گم میشه. نشونه اصلی: وقتی تفریحت شروع کرد بهت حسِ «شغل» دادن، وقتشه بکشی کنار. نقش تیم‌ها و شرکت‌ها برن‌آوت درسته که یه تجربه شخصیه، ولی شرکت‌ها هم توش دخیـلن. یه تغییر کوچیک تو رویکرد تیم می‌تونه حیاتی باشه: قبل از اینکه سر یه فیچر یا ددلاین توافق کنید، با دولوپرها حرف بزنید؛ نه بعدش که کار از کار گذشت. این کار جلوی اون فشار خاموشی رو که ذره‌ذره آدم‌ها رو فرسوده می‌کنه، می‌گیره. چندتا راهکار واسه اینکه کم نیاری واسه دوام آوردن تو این مسیر، تغییرات کوچیک خیلی اثر دارن: ✔️ به محض دیدن اولین نشونه‌ها، واقعی استراحت کن. ✔️ وقتی لازمه، ریموت کار کن و واسه خودت فضای شخصی بساز. ✔️ جای اینکه هشدارهای اطرافیان رو ایگنور کنی، بهشون گوش بده. ✔️ واسه کم کردن بار ذهنی، همه چی رو نوت‌برداری کن. ختم کلام: این یه باگ نیست، فیچره! برن‌آوت «لوس‌بازیِ کارهای پشت‌میزنشینی» نیست. این قضیه ربطی به خستگیِ تایپ کردن نداره؛ بحثِ فشار ذهنی، انتظارات غیرواقعی، بحران هویت و حس همیشگیِ «عقب موندن از تکنولوژی»ـه. این فشار واقعیه و می‌تونه حتی عاشق‌ترین برنامه‌نویس‌ها رو هم از پا دربیاره. اگه عاشقِ کدنویسی هستی، مجبور نیستی ۲۴ ساعته بدوی دنبالش. به خودت اجازه بده استراحت کنی و دیسکانکت شی. بذار اشتیاقت نفس بکشه. اگه واقعاً عاشقش باشی، لازم نیست به زور نگه‌ش داری؛ وقتی بهش فضا بدی، خودش برمی‌گرده. —- 💡 مثل همیشه کنجکاو بمونید :) 🆔 @MdDaily2,26%
13 авг.گوگل مدل Gemini 3.7 Flash رو معرفی کرد طبق گفته ی خودش توی پست اینستاگرام اکانت googlefordevs : با Gemini 3.7 Flash⚡️ آشنا بشید— باهوش‌ترین مدل همه‌فن‌حریف ما تا به امروز برای کدنویسی و ایجنت‌ها! این مدل، هوشمندی بالاتری رو برای جریان‌های کاری (ورک‌فلوهای) پیچیده ارائه می‌ده و تا پایان سال با قیمت معرفی ۰.۷۵ دلار به ازای هر ۱ میلیون توکن ورودی و ۳.۷۵ دلار به ازای هر ۱ میلیون توکن خروجی در دسترسه. همین حالا می‌تونید از طریق Google AI Studio و Android Studio، توی Google Antigravity و Gemini API بهش دسترسی داشته باشید پ ن : باید منتظر بنچمارک هاش باشیم ولی همه کامنت گذاشته بودن و منتظر 3.5 pro هستن. احساس میکنم گوگل حوصله اش سر میره یه نسخه فلش جدید میده بیرون. —- 💡 مثل همیشه کنجکاو بمونید :) 🆔 @MdDaily1,86%
13 авг.без подписи1,66%
12 февр.دردسرِ کدهای «تقریباً درست» 🔍 تصور کن سه‌شنبه هفته پیشه و یه برنامه‌نویس سه ساعت تمام وقتش رو گذاشته تا باگی رو پیدا کنه که اصلاً وجود خارجی نداره! کد در ظاهر حرف نداشت؛ ساختار تمیز، رعایت تمام اصول و حتی کامنت‌های دقیق برای هر تابع. اما مشکل از جای عجیبی آب می‌خورد: یکی از تابع‌ها داشت مسئله‌ای رو حل می‌کرد که اصلاً کسی ازش نخواسته بود! Claude با اون دانشِ الگویابیِ بی‌پایانش، خودش تصمیم گرفته بود که اندپوینت API حتماً به صفحه‌بندی نیاز داره. در حالی که اصلاً نیازی بهش نبود. همین کدِ اضافه، ساختار پاسخ‌ها رو جوری بهم ریخته بود که دیباگ کردنش بیشتر از زمانی که آدم خودش کد رو از صفر بنویسه، طول کشید. این دقیقاً همون مشکل ۶۶ درصدیه. 📉 طبق آخرین نظرسنجی «استک اورفلو» از ۹۰ هزار برنامه‌نویس، ۶۶ درصدشون گفتن بزرگترین کلافگی‌شون با هوش مصنوعی اینه که کدها «تقریباً درستن، اما نه کاملاً». ۴۵ درصد دیگه هم معتقد بودن که عیب‌یابی کدهای هوش مصنوعی، اصلاً به زحمتش نمی‌ارزه. ابزارهایی که قرار بود سرعت ما رو بالا ببرن، یه مدل باگ جدید ساختن که تا چند سال پیش اصلاً نبود: باگی که ظاهرش کاملاً شبیه کد سالمه. داستان کدی که کلاً غلطه واضحه؛ ارور می‌ده، اجرا نمی‌شه و توی تست‌ها معلوم میشه. اما کدی که «تقریباً درسته» چی؟ این همون کدیه که تست‌ها رو پاس می‌کنه، می‌ره روی سرور و بعد ساعت ۲ نصفه‌شب، وقتی مشتری داره یه کاری انجام می‌ده، یهو یه رفتار عجیب و غریب از خودش نشون میده که کل سیستم رو می‌بره زیر سوال. 🐞 باگ‌های قدیمی صادق بودن و خودشون رو لو می‌دادن. اما این باگ‌های جدید خیلی مودب هستن؛ صبر می‌کنن تا در بدترین زمانِ ممکن غافلگیرت کنن. برنامه‌نویس‌های قدیمی هر اشتباهی که فکرش رو بکنی انجام دادن؛ از سوتی‌های امنیتی تا پاک کردن دیتابیس اصلی. اون‌ها اشتباهات خودشون بود و وقتی سیستم می‌ترکید، سریع می‌فهمیدن چی شده. چرخه بازخورد سریع بود: یه کار اشتباه انجام می‌دادی، سیستم اطلاع میداد و یاد می‌گرفتی دیگه تکرارش نکنی. 🤖 اما باگ‌های هوش مصنوعی اینطوری نیستن. الان وقتی چیزی خراب می‌شه، اولین سؤال این نیست که «من کجای کار رو اشتباه کردم؟»، بلکه اینه که «هوش مصنوعی چه کاری انجام داده که من متوجهش نشدم؟». این یه مدل کاملاً متفاوت از عیب‌یابی‌یه. به جای فهمیدن منطق خودت، باید فرضیات یکی دیگه رو مهندسی معکوس کنی. 🧑‍💻 تحقیقات مایکروسافت هم این رو تایید می‌کنه. مدل‌های هوش مصنوعی توی تست‌های عیب‌یابی واقعی، حتی بهترین‌شون مثل Claude 3.7 Sonnet، زیر ۵۰ درصد موفق بودن. این نشون می‌ده مدل‌ها در نوشتن کد عالی‌ان، اما در اصلاح کردنش بدجوری لنگ می‌زنن. 🧩 چرا؟ چون تولید کد برای هوش مصنوعی یعنی «تکمیل الگو». اون بر اساس میلیاردها نمونه، پیش‌بینی می‌کنه کلمات بعدی چی باشن. این برای کدهای تکراری عالیه، اما دیباگ کردن یعنی «تست کردن فرضیه‌ها». هوش مصنوعی نمی‌دونه چرا ساختار سیستم تو این شکلیه یا فلان قانون بیزنس که منطقی به نظر نمی‌رسه، چقدر حیاتیه. اون فقط الگوها رو می‌بینه و تکرار می‌کنه. ⚡️ یه آزمایش جالب نشون داده برنامه‌نویس‌هایی که از هوش مصنوعی استفاده کردن، ۱۹ درصد کندتر بودن، اما حس می‌کردن ۲۴ درصد سریع‌تر شدن! یعنی اون لذتِ سریع آماده شدنِ کد، باعث شده بود بدهی فنی که پشت سرشون جمع می‌شد رو نبینن. 👨‍💻 قرار نیست کسی استفاده از این ابزارها رو کنار بذاره. اما باید جوری بهشون نگاه کرد که انگار یه برنامه‌نویس تازه‌کار اون‌ها رو نوشته؛ کسی که خیلی به خودش مطمئنه ولی مهارتش معمولیه. مشکل این نیست که این ابزارها بد هستن؛ مشکل اینجاست که اون‌قدر خوب هستن که می‌تونن خطرناک باشن. چکشی که کلاً به میخ نخوره رو اعصابه، اما چکشی که «تقریباً» جای درست می‌خوره، آخرش یه خونه کج و معوج بهت تحویل می‌ده. فعلاً راه حل قطعی وجود نداره. شاید در آینده هوش مصنوعی یاد بگیره به جای فرض کردن، سوال بپرسه. اما تا اون موقع، بهتره برنامه‌نویس‌ها حواسشون به تست‌ها و کدهای خودشون باشه. بعضی مهارت‌ها رو نباید سپرد به ماشین؛ باید اون‌ها رو دقیق‌تر کرد. ✅ —- 💡 مثل همیشه کنجکاو بمونید :) 🆔 @MdDaily1,64%
15 дек.کد تمیز افسانه نیست؛ فقط دوام نمیاره مشکل این نیست که هیچ‌کس کد تمیز نمی‌نویسه. مشکل اینه که کد تمیز تو پروژه‌های واقعی، زیر فشارِ کار کم‌کم داغون میشه. اگه یه مدت تو یه تیم کار کرده باشی، حتماً دیدی: کدی که اوایل مرتب و قابل فهم بوده، با اضافه شدن فیچرهای عجله‌ای، ددلاین‌ها و تصمیم‌های لحظه‌ای، کم‌کم شلوغ و سخت‌فهم میشه. نه به این خاطر که برنامه‌نویسا بلد نیستن، به این خاطر که واقعیت پروژه این شکلیه. ✨ اصلاً کد تمیز یعنی چی؟ کد تمیز یه چیز کاملاً سلیقه‌ای نیست. بعضی چیزاش واضحه: اسم متغیر و فانکشن باید درست باشه، هر تیکه کد باید کار خودش رو بکنه، وابستگی‌ها نباید قاطی‌پاطی باشن و بشه راحت تغییرش داد بدون اینکه کل سیستم بریزه به هم. البته همه‌چیز هم قانون خشک نداره. کدی که امروز تمیزه، ممکنه چند ماه دیگه فقط قابل تحمل باشه. تعریف ساده‌ش اینه: کدی که تغییر دادنش از نوشتنش کم‌هزینه‌تره. 🖥 پروژه‌ها از اول داغون نیستن، داغون میشن. تقریباً هیچ پروژه‌ای از همون اول شلخته شروع نمیشه. همه‌چی مرتب و با برنامه جلو میره. ولی کم‌کم ددلاین میاد، مشتری عجله داره، بازار فشار میاره. اگه حواست نباشه، اون نظم اولیه می‌پاشه. 🖥 پروتوتایپی که قرار نبود بمونه. یه کد موقتی می‌نویسن که فقط یه چیز رو نشون بده. قرار بوده یکی دو هفته بعد بندازنش دور. ولی بیزنس خوشش میاد، میگه یه چیز کوچولو هم بهش اضافه کن. بعد یکی دیگه. بعد یهو همون کد میره تو پروداکشن و میشه هسته‌ی سیستم. اینجا مشکل کد بد نیست، مشکل اینه که تصمیم بد جدی گرفته شده. 🖥 ریفکتوری که تموم نمیشه. اگه یه تمیزکاری سال‌ها طول کشیده، معمولاً مشکل از کد نیست. یا تست ندارین، یا معلوم نیست مسئول این بخش کیه، یا همه می‌ترسن دست بزنن چیزی خراب بشه. ریفکتور وقتی به کار واقعی وصل نباشه، میشه کاری که همیشه هست ولی هیچ‌وقت تموم نمیشه. سنیور سخت‌گیر همیشه خوب نیست. سنیوری که فقط ایراد می‌گیره و فضا رو ترسناک می‌کنه، به تمیز شدن کد کمک نمی‌کنه. باعث میشه بقیه یواشکی کد بزنن که فقط کار راه بیفته. اینجوری کد بد قایم میشه، نه اینکه درست بشه. راه‌حل‌های موقت، وقتی دائم میشن دردسر می‌سازن. یه هک سریع یا فلگ موقتی بعضی وقتا لازمه. مشکل وقتی شروع میشه که اسم درست نداره، کسی نمی‌دونه چرا هست، و معلوم نیست کی باید حذفش کنه. اون موقع میشه یه تیکه خطرناک که همه ازش فرار می‌کنن. 🤖 هوش مصنوعی کد زشت نمی‌نویسه، کد بی‌مسئولیت می‌نویسه. کدی که AI می‌ده معمولاً قشنگه، ولی نمی‌دونه پروژه قراره کجا بره، چرا این تصمیم گرفته شده، و آخرش کی قراره نگه‌داریش کنه. کدی که صاحب نداشته باشه، حتی اگه تمیز به نظر بیاد، آخرش دردسر میشه. 📊 بیزنس و کد دشمن هم نیستن. بیزنس می‌خواد زنده بمونه، برنامه‌نویس می‌خواد سیستم نخوابه. نه سرعت بدون فکر جواب میده، نه وسواس بیش از حد. کدی که نشه راحت تغییرش داد، بیزنس رو کند می‌کنه. بیزنسی هم که به کد اهمیت نده، بعداً هزینه‌شو میده. 🤔 پس بی‌خیال کد تمیز بشیم؟ نه. ولی واقع‌بین باشیم. کد تمیز یه مقصد نیست، یه تعهده. تعهد به تیم، به خودِ چند ماه بعدمون، و به پروژه‌ای که قراره زنده بمونه. نه وسواس، نه شل‌گیری. فقط مسئولیت. 🔗 برای نوشتن این پست از این منبع خیلی الهام گرفته شده: https://dev.to/sylwia-lask/nobody-writes-clean-code-we-all-just-pretend-11d1 —- 💡 مثل همیشه کنجکاو بمونید :) 🆔 @MdDaily1,63%