[ Source >> @matlabtips ]
#کلین_کد
کد باید به شما بگوید چگونه، کامنت باید بگوید چرا!
فرض کنید کدی به شما تحویل می دهند که مربوط به یک سیستم پرداخت است. فایلی را باز می کنید و چیزی شبیه به این میبینید:
با خودتان فکر میکنید خب این کامنت به چه دردی می خورد؟ خود کد دقیقا همان کار را می کند. سوال این است که چرا چنین فایلی اصلا خوانده و پارس می شود؟ این کد چه فرض هایی دارد و در نهایت می خواهد چکار کند؟ ساعت ها کد را بالا پایین می کنید تا بالاخره میفهمید «آها» و دلیل نهایی آن را می فهمید.
حالا تصور کنید که کد پایین را می بینید:
به یکباره همه چیز روشن می شود:
حالا می دانید که چرا این کد اینجا نوشته شده است. این why به شما دقیقا می گوید مساله چیست. این همان تفاوت میان «کامنتهای چگونه» (توضیح دادن اینکه کد چه میکند) و «کامنتهای چرا» (توضیح دادن منطق و دلیل) است. و در دنیای توسعهٔ نرمافزار مدرن، کامنتهای چرا همیشه برندهاند.
کامنت های چگونه هیچ ارزش افزوده ای ایجاد نمی کنند شما باید کدتان آنقدر تمیز باشد که نیازی به کامنت «چگونه» نداشته باشید. برای این کار باید متغیر های با معنا انتخاب کنید و از منطق های پیچیده برای انجام کاری مشخص پرهیز کنید. با این حال چگونه انجام دادن چیزی به شما نمی گوید «چرا» این کار را انجام می دهیم. به صورت مشخص تر کد ها تهی از «نیت» (intention) و «چرایی» هستند. به مثال زیر توجه کنید:
بدون این کامنتها، یک توسعهدهندهٔ آینده ممکن است میانگین متحرک را حذف کند (با این تصور که لازم نیست) یا گرد کردن را تغییر دهد (بیآنکه بداند این باعث ایجاد خطا در خروجی این تابع می شود که جای دیگری استفاده می شود). اما با این توضیحات، فوراً میفهمد چرا این کد اینطور نوشته شده محدودیتهای تجاری، تصمیمات تاریخی و نیازمندیهای سیستمی.
این اطلاعاتی است که فقط با نگاه به کد نمیتوان به دست آورد. «کامنتهای چگونه» با تغییر پیادهسازی از بین میروند. «کامنتهای چرا» زنده میمانند چون هدف را توضیح میدهند، نه نحو کد را.
حالت های استثنایی وجود دارد که کامنت های چگونه می توانند مفید باشند. مثلا زمانی که خود عملیات کمی پیچیده بنظر می رسد. مثلا مورد زیر را در نظر بگیرید:
با این حال چنین مواردی استثنا هستند.
قاعدهٔ طلایی: بگذارید کد «چگونه» را توضیح دهد. بگذارید کامنت «چرا» را توضیح دهد. اگر میبینید کامنت فقط چیزی را که کد نشان میدهد تکرار میکند، ننویسید. اگر دارید توضیح میدهید چرا این خط وجود دارد بهخصوص وقتی دلیلش بدیهی نیست، درست عمل کردهاید.
🚁 Hicte Blog | (smm)
#کلین_کد
کد باید به شما بگوید چگونه، کامنت باید بگوید چرا!
فرض کنید کدی به شما تحویل می دهند که مربوط به یک سیستم پرداخت است. فایلی را باز می کنید و چیزی شبیه به این میبینید:
# Parse the JSON response
data = json.loads(response.text)
با خودتان فکر میکنید خب این کامنت به چه دردی می خورد؟ خود کد دقیقا همان کار را می کند. سوال این است که چرا چنین فایلی اصلا خوانده و پارس می شود؟ این کد چه فرض هایی دارد و در نهایت می خواهد چکار کند؟ ساعت ها کد را بالا پایین می کنید تا بالاخره میفهمید «آها» و دلیل نهایی آن را می فهمید.
حالا تصور کنید که کد پایین را می بینید:
# The payment gateway sometimes returns a 200 OK with an embedded error message in JSON.
# We parse the body here before the upstream validation so we can extract error codes early.
data = json.loads(response.text)
به یکباره همه چیز روشن می شود:
حالا می دانید که چرا این کد اینجا نوشته شده است. این why به شما دقیقا می گوید مساله چیست. این همان تفاوت میان «کامنتهای چگونه» (توضیح دادن اینکه کد چه میکند) و «کامنتهای چرا» (توضیح دادن منطق و دلیل) است. و در دنیای توسعهٔ نرمافزار مدرن، کامنتهای چرا همیشه برندهاند.
کامنت های چگونه هیچ ارزش افزوده ای ایجاد نمی کنند شما باید کدتان آنقدر تمیز باشد که نیازی به کامنت «چگونه» نداشته باشید. برای این کار باید متغیر های با معنا انتخاب کنید و از منطق های پیچیده برای انجام کاری مشخص پرهیز کنید. با این حال چگونه انجام دادن چیزی به شما نمی گوید «چرا» این کار را انجام می دهیم. به صورت مشخص تر کد ها تهی از «نیت» (intention) و «چرایی» هستند. به مثال زیر توجه کنید:
def calculate_settlement_amount(transactions):
"""
Calculates the final settlement amount.
Why:
- We apply a 3-day rolling average to smooth out FX fluctuations (requested by Finance, Jan 2024).
- Exclude refunds pending investigation (compliance requirement).
- Round to 2 decimal places because the downstream ledger rejects more precision.
"""
# Exclude suspicious refunds
filtered = [t for t in transactions if not t.pending_investigation]
# Apply rolling average for FX normalization
normalized = rolling_average(filtered, days=3)
# Sum and round
return round(sum(t.amount for t in normalized), 2)
بدون این کامنتها، یک توسعهدهندهٔ آینده ممکن است میانگین متحرک را حذف کند (با این تصور که لازم نیست) یا گرد کردن را تغییر دهد (بیآنکه بداند این باعث ایجاد خطا در خروجی این تابع می شود که جای دیگری استفاده می شود). اما با این توضیحات، فوراً میفهمد چرا این کد اینطور نوشته شده محدودیتهای تجاری، تصمیمات تاریخی و نیازمندیهای سیستمی.
این اطلاعاتی است که فقط با نگاه به کد نمیتوان به دست آورد. «کامنتهای چگونه» با تغییر پیادهسازی از بین میروند. «کامنتهای چرا» زنده میمانند چون هدف را توضیح میدهند، نه نحو کد را.
حالت های استثنایی وجود دارد که کامنت های چگونه می توانند مفید باشند. مثلا زمانی که خود عملیات کمی پیچیده بنظر می رسد. مثلا مورد زیر را در نظر بگیرید:
# Bit trick: drops the lowest set bit (faster than looping)
x &= x - 1
با این حال چنین مواردی استثنا هستند.
قاعدهٔ طلایی: بگذارید کد «چگونه» را توضیح دهد. بگذارید کامنت «چرا» را توضیح دهد. اگر میبینید کامنت فقط چیزی را که کد نشان میدهد تکرار میکند، ننویسید. اگر دارید توضیح میدهید چرا این خط وجود دارد بهخصوص وقتی دلیلش بدیهی نیست، درست عمل کردهاید.
🚁 Hicte Blog | (smm)
👍7❤2
[ Source >> @Digiato ]
#خبر
مایکروسافت پس از کنارهگیری توماس دومکه مدیرعامل گیتهاب، تصمیم گرفته است گیتهاب را بهصورت مستقیم در ساختار تیم CoreAI ادغام کند.
از زمانی که مایکروسافت در سال ٢٠١٨ با پرداخت ٧.۵ میلیارد دلار گیتهاب را خرید، این پلتفرم بهعنوان یک شرکت مستقل فعالیت میکرد. اما استعفای دومکه بخشی از یک تغییر سازمانی بزرگ است که نحوه مدیریت گیتهاب را دگرگون میکند.
مایکروسافت تصمیم گرفته جایگزینی برای مدیرعاملی گیتهاب تعیین نکند و تیم مدیریت گیتهاب حالا مستقیما به تیم CoreAI گزارش خواهند داد.
🚁 Hicte Blog | (smm)
#خبر
مایکروسافت پس از کنارهگیری توماس دومکه مدیرعامل گیتهاب، تصمیم گرفته است گیتهاب را بهصورت مستقیم در ساختار تیم CoreAI ادغام کند.
از زمانی که مایکروسافت در سال ٢٠١٨ با پرداخت ٧.۵ میلیارد دلار گیتهاب را خرید، این پلتفرم بهعنوان یک شرکت مستقل فعالیت میکرد. اما استعفای دومکه بخشی از یک تغییر سازمانی بزرگ است که نحوه مدیریت گیتهاب را دگرگون میکند.
مایکروسافت تصمیم گرفته جایگزینی برای مدیرعاملی گیتهاب تعیین نکند و تیم مدیریت گیتهاب حالا مستقیما به تیم CoreAI گزارش خواهند داد.
🚁 Hicte Blog | (smm)
💔5
#ابزار_لینوکس
اگه خواستین بجای استفاده از ابزار ping یه گراف real-time تو ترمینال داشته باشین gping اینجاست.
نصب در آرچ لینوکس:
🚁 Hicte Blog | (smm)
اگه خواستین بجای استفاده از ابزار ping یه گراف real-time تو ترمینال داشته باشین gping اینجاست.
نصب در آرچ لینوکس:
# pacman -S gping🚁 Hicte Blog | (smm)
👍7🔥2☃1🐳1😡1
Telegram
Hicte Bridge in HICTE Group
#مهندسی_نرم_افزار
یکی از مشکلاتی که پروتکل grpc دارد این است که هنوز به طور کامل توسط مرورگرها پشتیبانی نمی شود و برای راه اندازی اش یکی از روش های مرسوم استفاده از api gateway است تا قسمتی که هنوز درخواست کاربر به اپلیکشن نرسیده با http هندل می شود و باقی قسمت های داخلی اپ مایکروسرویس ما با grpc به عنوان مثال بیایم با یک مثال «سفارش تاکسی مثل اوبر» تصویرش کنیم:
سناریو: درخواست سفر
کاربر بیرونی چه میزند؟ (HTTP/REST)
اپ موبایل کاربر یک درخواست سادهی HTTP میفرستد به آدرس عمومی:
این درخواست فقط «متنِ معمولی وب» است؛ همان چیزی که همهی اپها و مرورگرها بلدند.
این API Gateway چه میکند؟
گِیتوی جلوی ورودی نشسته؛ هویت کاربر را چک میکند (توکن، محدودیت سرعت، لاگبرداری).
بعد طبق مسیر /v1/rides میفهمد این درخواست مربوط به «سرویس سفر» است.
دادهی سادهی کاربر را برمیدارد و آن را برای داخل شرکت تبدیل و ارسال میکند.
داخل شرکت چه میشود؟ (گفتوگوی سریع سرویسها)
گِیتوی به «سرویس سفر» میگوید: «یک سفر جدید لازم است» (سرویسها با زبان سریع و مخصوص خودشان حرف میزنند، همان gRPC، ولی لازم نیست جزئیاتش را بدانیم).
«سرویس سفر» برای کارهای مختلف با چند سرویس داخلی حرف میزند:
با «سرویس رانندهها» هماهنگ میکند ببیند چه رانندهای نزدیک است.
با «سرویس نقشه/مسیر» فاصله و زمان تقریبی را میپرسد.
با «سرویس پرداخت» چک میکند کارت معتبر است یا نه.
هر کدام از این مکالمات داخلی خیلی سریع، مستقیم و کمحجم انجام میشوند (همان gRPC داخلی).
پاسخ نهایی به کاربر
وقتی سرویس سفر از سرویسهای داخلی جوابها را گرفت (راننده پیدا شد، قیمت محاسبه شد، پرداخت اوکی شد)، نتیجه را به API Gateway برمیگرداند.
گِیتوی همان نتیجه را به شکل سادهی وب (JSON) به اپ موبایل برمیگرداند:
چرا این مدل خوب است؟
بیرون ساده میماند: همهی مشتریها فقط یک آدرس عمومی و JSON ساده میبینند.
داخل تند و مقرونبهصرفه است: سرویسهای داخلی با زبان سریعتر و کمحجمتر با هم حرف میزنند، تا تأخیر و هزینه پایین باشد.
مقیاسپذیر: میتوانی سرویسهای داخلی را مستقل زیاد/کم کنی، بدون اینکه به اپ مشتری دست بزنی.
امنیت و کنترل: همه چیز از گِیتوی میگذرد؛ پس ورود، سهمیه، لاگ و رصد یکجا انجام میشود.
یک مثال دیگر کوتاه (پیگیری سفر)
اپ کاربر هر چند ثانیه یک بار میزند:
گِیتوی درخواست را به «سرویس سفر» پاس میدهد؛ «سرویس سفر» وضعیت را از «سرویس راننده/نقشه» داخلی میگیرد (داخلی سریع).
پاسخ ساده به کاربر برمیگردد:
این دقیقاً همان الگویی است که شرکتهای بزرگی مثل Uber/Lyft/… هم به شکلهای مختلف از آن استفاده میکنند: بیرون REST، داخل گفتوگوی سریع سرویسها.
🚁 Hicte Blog | (Nariman Tj)
یکی از مشکلاتی که پروتکل grpc دارد این است که هنوز به طور کامل توسط مرورگرها پشتیبانی نمی شود و برای راه اندازی اش یکی از روش های مرسوم استفاده از api gateway است تا قسمتی که هنوز درخواست کاربر به اپلیکشن نرسیده با http هندل می شود و باقی قسمت های داخلی اپ مایکروسرویس ما با grpc به عنوان مثال بیایم با یک مثال «سفارش تاکسی مثل اوبر» تصویرش کنیم:
سناریو: درخواست سفر
کاربر بیرونی چه میزند؟ (HTTP/REST)
اپ موبایل کاربر یک درخواست سادهی HTTP میفرستد به آدرس عمومی:
POST https://api.example.com/v1/rides
Body: { "pickup": "...", "dropoff": "...", "payment": "visa" }این درخواست فقط «متنِ معمولی وب» است؛ همان چیزی که همهی اپها و مرورگرها بلدند.
این API Gateway چه میکند؟
گِیتوی جلوی ورودی نشسته؛ هویت کاربر را چک میکند (توکن، محدودیت سرعت، لاگبرداری).
بعد طبق مسیر /v1/rides میفهمد این درخواست مربوط به «سرویس سفر» است.
دادهی سادهی کاربر را برمیدارد و آن را برای داخل شرکت تبدیل و ارسال میکند.
داخل شرکت چه میشود؟ (گفتوگوی سریع سرویسها)
گِیتوی به «سرویس سفر» میگوید: «یک سفر جدید لازم است» (سرویسها با زبان سریع و مخصوص خودشان حرف میزنند، همان gRPC، ولی لازم نیست جزئیاتش را بدانیم).
«سرویس سفر» برای کارهای مختلف با چند سرویس داخلی حرف میزند:
با «سرویس رانندهها» هماهنگ میکند ببیند چه رانندهای نزدیک است.
با «سرویس نقشه/مسیر» فاصله و زمان تقریبی را میپرسد.
با «سرویس پرداخت» چک میکند کارت معتبر است یا نه.
هر کدام از این مکالمات داخلی خیلی سریع، مستقیم و کمحجم انجام میشوند (همان gRPC داخلی).
پاسخ نهایی به کاربر
وقتی سرویس سفر از سرویسهای داخلی جوابها را گرفت (راننده پیدا شد، قیمت محاسبه شد، پرداخت اوکی شد)، نتیجه را به API Gateway برمیگرداند.
گِیتوی همان نتیجه را به شکل سادهی وب (JSON) به اپ موبایل برمیگرداند:
200 OK
{
"rideId": "abc123",
"driver": { "name": "Sara", "car": "Prius" },
"eta": "3 min",
"price": "€8.40"
}
چرا این مدل خوب است؟
بیرون ساده میماند: همهی مشتریها فقط یک آدرس عمومی و JSON ساده میبینند.
داخل تند و مقرونبهصرفه است: سرویسهای داخلی با زبان سریعتر و کمحجمتر با هم حرف میزنند، تا تأخیر و هزینه پایین باشد.
مقیاسپذیر: میتوانی سرویسهای داخلی را مستقل زیاد/کم کنی، بدون اینکه به اپ مشتری دست بزنی.
امنیت و کنترل: همه چیز از گِیتوی میگذرد؛ پس ورود، سهمیه، لاگ و رصد یکجا انجام میشود.
یک مثال دیگر کوتاه (پیگیری سفر)
اپ کاربر هر چند ثانیه یک بار میزند:
GET https://api.example.com/v1/rides/abc123/statusگِیتوی درخواست را به «سرویس سفر» پاس میدهد؛ «سرویس سفر» وضعیت را از «سرویس راننده/نقشه» داخلی میگیرد (داخلی سریع).
پاسخ ساده به کاربر برمیگردد:
{"status":"driver_arriving","eta":"2 min"}این دقیقاً همان الگویی است که شرکتهای بزرگی مثل Uber/Lyft/… هم به شکلهای مختلف از آن استفاده میکنند: بیرون REST، داخل گفتوگوی سریع سرویسها.
🚁 Hicte Blog | (Nariman Tj)
❤2👍2🔥1
[ Source >> @srfirouzi_channel ]
#مهندسی_نرم_افزار
عملگرایی و تحلیلگرایی در توسعه نرمافزار
(دو روی یک سکه برای موفقیت تیمی)
در دنیای توسعه نرمافزار، اغلب دو رویکرد دیده میشود: عملگرایی و تحلیلگرایی.
اما نکته کلیدی این است که این دو هیچگاه در تقابل نیستند؛ بلکه یکدیگر را تکمیل میکنند.
در واقع، عملگرایی و تحلیلگرایی یک طیف هستند، نه دو مسیر جدا؛ تیمها و پروژهها میتوانند در هر نقطهای از این طیف قرار بگیرند و بسته به شرایط، تعادل مناسب را انتخاب کنند.
عملگراها عاشق حرکت و اجرا هستند.
آنها سریع دست به کد میزنند، پروتوتایپ میسازند و ایدهها را به واقعیت تبدیل میکنند.
برای آنها تجربه عملی و بازخورد سریع، موتور پیشرفت پروژههاست.
اما اگر بیش از حد عملگرا باشیم، خطر بدهی فنی و تصمیمات عجولانه وجود دارد؛ یعنی کدی نوشته میشود که شاید پایدار نباشد و نیازمند اصلاحات مداوم شود.
تحلیلگراها عاشق بررسی دقیق و جزئیات هستند.
آنها معماری و طراحی سیستم را به دقت میکاوند، ریسکها را شناسایی میکنند و قبل از اجرای کد، مشکلات احتمالی را پیشبینی میکنند.
این دقت باعث میشود پروژهها پایدار و قابل توسعه باقی بمانند.
اما اگر بیش از حد تحلیلگرا باشیم، ممکن است تیم دچار فلج تحلیلی شود؛ یعنی آنقدر در طراحی و بررسی جزئیات گرفتار شویم که هیچ محصول واقعی تولید نشود.
در واقع، یک تیم موفق نرمافزاری به هر دو نوع رویکرد نیاز دارد:
عملگراها تضمین میکنند که پروژه حرکت کند و ایدهها سریع آزمایش شوند.
تحلیلگراها تضمین میکنند که حرکت، با کیفیت و استحکام همراه باشد.
وقتی این دو با هم کار کنند، نتیجه چیزی فراتر از جمع تواناییهایشان است:
پروژهای که هم سریع پیش میرود و هم مستحکم و پایدار است.
یادمان باشد: در توسعه نرمافزار، عمل و تحلیل دو روی یک سکه هستند و یک طیف پیوسته را تشکیل میدهند، نه دو مسیر مخالف.
تعادل بین این دو، کلید جلوگیری از بدهی فنی و فلج تحلیلی و راز ساخت تیمهای موفق و پروژههای پایدار است.
🚁 Hicte Blog | (smm)
#مهندسی_نرم_افزار
عملگرایی و تحلیلگرایی در توسعه نرمافزار
(دو روی یک سکه برای موفقیت تیمی)
در دنیای توسعه نرمافزار، اغلب دو رویکرد دیده میشود: عملگرایی و تحلیلگرایی.
اما نکته کلیدی این است که این دو هیچگاه در تقابل نیستند؛ بلکه یکدیگر را تکمیل میکنند.
در واقع، عملگرایی و تحلیلگرایی یک طیف هستند، نه دو مسیر جدا؛ تیمها و پروژهها میتوانند در هر نقطهای از این طیف قرار بگیرند و بسته به شرایط، تعادل مناسب را انتخاب کنند.
عملگراها عاشق حرکت و اجرا هستند.
آنها سریع دست به کد میزنند، پروتوتایپ میسازند و ایدهها را به واقعیت تبدیل میکنند.
برای آنها تجربه عملی و بازخورد سریع، موتور پیشرفت پروژههاست.
اما اگر بیش از حد عملگرا باشیم، خطر بدهی فنی و تصمیمات عجولانه وجود دارد؛ یعنی کدی نوشته میشود که شاید پایدار نباشد و نیازمند اصلاحات مداوم شود.
تحلیلگراها عاشق بررسی دقیق و جزئیات هستند.
آنها معماری و طراحی سیستم را به دقت میکاوند، ریسکها را شناسایی میکنند و قبل از اجرای کد، مشکلات احتمالی را پیشبینی میکنند.
این دقت باعث میشود پروژهها پایدار و قابل توسعه باقی بمانند.
اما اگر بیش از حد تحلیلگرا باشیم، ممکن است تیم دچار فلج تحلیلی شود؛ یعنی آنقدر در طراحی و بررسی جزئیات گرفتار شویم که هیچ محصول واقعی تولید نشود.
در واقع، یک تیم موفق نرمافزاری به هر دو نوع رویکرد نیاز دارد:
عملگراها تضمین میکنند که پروژه حرکت کند و ایدهها سریع آزمایش شوند.
تحلیلگراها تضمین میکنند که حرکت، با کیفیت و استحکام همراه باشد.
وقتی این دو با هم کار کنند، نتیجه چیزی فراتر از جمع تواناییهایشان است:
پروژهای که هم سریع پیش میرود و هم مستحکم و پایدار است.
یادمان باشد: در توسعه نرمافزار، عمل و تحلیل دو روی یک سکه هستند و یک طیف پیوسته را تشکیل میدهند، نه دو مسیر مخالف.
تعادل بین این دو، کلید جلوگیری از بدهی فنی و فلج تحلیلی و راز ساخت تیمهای موفق و پروژههای پایدار است.
🚁 Hicte Blog | (smm)
👍4🔥2