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

این قانون تبدیل شده به یکی از قوانین نانوشته مهندسی نرم افزار که خیلی خوبه که یادش بگیرید !

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

یه مثال واقعی و عجیب از دنیای لینوکس:
یه بار مهندس‌های گوگل دیدن توی خروجی لیست فایل‌های لینوکس چندتا فاصله خالی (Space) بیخود وجود داره. اونا هم از روی دلسوزی این اسپیس‌ها رو حذف کردن که خروجی تمیز بشه. به محض منتشر شدن این تغییر، کلی از برنامه‌های دنیا از کار افتاد! چرا؟ چون برنامه‌نویس‌های دیگه کدشون رو جوری نوشته بودن که مثلا می‌گفت: برو کاراکتر شماره ۲۰ رو بردار. اونا از اون فاصله‌های بیخود به عنوان خط‌کش استفاده می‌کردن و با حذف اونا، کل محاسباتشون غلط شد.

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

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

تا حالا بهش برخوردین ؟ دوست دارم نظرتونو بدونم راجبش !

#lawsofsoftwareengineering

@codehalics | کدهالیک

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

این قانون دقیقاً همینه: توی بازطراحی یا همون Migration سیستم‌ها، نباید فقط به فیچرهای رسمی نگاه کرد.

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

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

#lawsofsoftwareengineering

@codehalics | کدهالیک

خب امروز میخوام راجب یه قانون دیگ در توسعه نرم افزار صحبت کنم که بیشتر جنبه محصولی داره !

قانون زاوینسکی

قانون زاویِنسکی میگه: هر برنامه‌ای وقتی موفق میشه، کم‌کم شروع می‌کنه به اضافه کردن فیچرهای جدید، تا جایی که از هدف اصلی خودش فاصله می‌گیره و حتی تبدیل میشه به یه محصول «همه‌فن‌حریف» که هیچ کاری رو واقعاً عالی انجام نمی‌ده. همون چیزی که میگن: Jack of all trades, master of none.

مثلاً تلگرام اول فقط یه پیام‌رسان ساده بود، اما کم‌کم تبدیل شد به یه پلتفرم کامل: تماس صوتی و تصویری، کانال، استوری، بات، پرداخت و حتی مینی‌اپ‌ها. الان دیگه فقط «چت» نیست، یه اکوسیستمه.

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

پ.ن: البته در بعضی بازارها (به‌خصوص کشورهای در حال توسعه)، سوپر‌اپ شدن خودش یه مزیت رقابتیه. چون یه اپ می‌تونه چندین سرویس رو یکجا جمع کنه؛ مثل تاکسی، غذا، خرید، خدمات پزشکی و… نمونه‌هاش هم توی ایران زیاده.

#lawsofsoftwareengineering

@codehalics | کدهالیک

خب امروز میخوام برم ادامه قوانین مهندسی نرم افزار رو بازگو کنم براتون و امروز راجب یه اصل بسیار پر تکرار قراره صحبت کنیم که قطعا خیلیاتون اسمشو شنیدید !

اصل KISS (Keep It Simple, Stupid) تو مهندسی نرم‌افزار میگه تا جای ممکن راه‌حل‌هات رو ساده نگه دار و الکی پیچیدش نکن. یعنی اگر میشه یه مسئله رو با یه کد کوتاه و قابل فهم حل کرد، لازم نیست بری سمت معماری‌های سنگین و عجیب فقط برای اینکه «باحال» به نظر بیاد. واقعیت اینه که هر خط کد اضافه، یه فرصت جدیده برای باگ و دردسر. کد ساده هم سریع‌تر خونده میشه، هم راحت‌تر دیباگ میشه، هم وقتی چند ماه بعد خودت برمی‌گردی سراغش کمتر فحش میدی به گذشته‌ات.

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

#lawsofsoftwareengineering

@codehalics | کدهالیک

مثل همیشه یه مثال واقعی از دنیای کار خودم بزنم درباره KISS.

قرار بود تو یه پروژه خیلی خفن جوین بشم، تیم هم واقعاً قوی بود و همه‌چیز عالی پیش می‌رفت تا اینکه یه مدیرفنی به تیم اضافه شد. از روز اول شروع کرد به اینکه این باندد کانتکست‌ها باید جدا شن، اینو میکروسرویس می‌کنیم، اینجا RabbitMQ می‌ذاریم، اونجا Kafka، مانیتورینگ با Zabbix، حتماً Kubernetes، بعدش هم Rancher بیارید بالا و خلاصه یه لیست بلندبالا از تکنولوژی‌ها که انگار بدون اینا پروژه اصلاً معنی نداره.

مشکل اینجا بود که ما کلاً از اصل ماجرا دور شدیم. به‌جای اینکه روی خود محصول تمرکز کنیم، افتادیم توی داستان بالا آوردن کلاستر، داکر، کوبرنتیز و هزار تا ابزار دیگه.

حالا شرایط چی بود؟
یکی اینکه time to market خیلی پایین بود، نهایتاً یه ماه وقت داشتیم محصول رو بدیم بالا. دوم اینکه بیزینس بودجه محدودی داشت و این همه زیرساخت پیچیده واقعاً هزینه‌بر بود.

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

بعد از ما یه تیم دیگه اومد و کاری که ما نتونستیم بکنیم رو انجام داد: یه مونولیت ساده ساختن که هسته بیزینس درست کار می‌کرد، روی یه سرور ویندوزی با IIS. نه خبری از داکر بود، نه کوبرنتیز، نه Vault، نه مانیتورینگ‌های عجیب.

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

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

و اینم بگم که تصور آدما از سنیور اینه که میاد یه کد خفن مینویسه که واو ولی نه سنیوری سنیوره که KISS اگ نتونه همین KISS رو بفهمه هیچی بارش نیست !
من یکیو میشناختم که الان سنیور یکی از لاین های بیزنسی مرسدس بنزه این بشر به قدری زیبا کد مینوشت و ساده مینوشت و ساده بیانش میکرد که لذت میبردی انگار داره برات خطاطی میکنه انقد قابل فهم بود کدی که مینوشت و با دلیل برات لایو مینوشت ! اون آدم مرسدس بنز که سهله جاهای دیگ رو سرشون میزاشتن یه نابغه به تمام معنا بود کسی که اوج پیچیدگی بیزینس رو تو چند خط کد شیوا بیانش میکرد !

#lawsofsoftwareengineering

@codehalics | کدهالیک

خب امروز میخوام برم ادامه قوانین مهندسی نرم‌افزار رو بگم

راجب یه اصل خیلی مهم و جالب قراره صحبت کنیم که احتمالاً هم تجربه‌ش کردید، هم دیدید تو بقیه

اثر Dunning-Kruger که توسط David Dunning و Justin Kruger معرفی شده، نکتش اینه :
هرچی کمتر بدونی، معمولاً اعتمادبه‌نفست بیشتره!

یعنی وقتی تازه وارد یه حوزه میشی ، چون هنوز عمق ماجرا رو نمی‌بینی، فکر می‌کنی همه‌چیز ساده‌ست و خیلی راحت می‌تونی از پسش بربیای. ولی هرچی جلوتر میری و بیشتر یاد می‌گیری، تازه می‌فهمی چقدر چیز هست که بلد نیستی… و اینجاست که اعتمادبه‌نفست میاد پایین (همون چیزی که بهش میگن valley of despair).

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

از اون طرف، یه پدیده دیگه هم هست به اسم impostor syndrome که توش آدم‌های حرفه‌ای فکر می‌کنن به اندازه کافی خوب نیستن، چون دقیقاً از پیچیدگی‌ها خبر دارن.

#lawsofsoftwareengineering

@codehalics | کدهالیک

اگر فن قوانین مهندسی نرم افزار هستید تا الان راجب این موضوعات باهم دیگه صحبت کردیم :

1- قانون هایروم

2-قانون زاوینسکی

3- قانون KISS

4- اثر Dunning-Kruger

ضمنا با هشتک #lawsofsoftwareengineering میتونین موارد مرتبط باهاش رو بخونین مثل نظرات و تجربیات شخصی خودم نسبت به هر کدوم
سعی میکنم هر روز یا هر 2 روز یک بار یک قانون جدید رو باهم دیگ بررسی کنیم بنظرم فهمشون خیلی خیلی بهمون دید کلی نسبت به محصول و برنامه نویسی و ... میده !

تمامی این موارد برگرفته از کتابی با همین اسم یعنی lawsofsoftwareengineering عه که سعی میکنم با نثری شیوا ( مثلا من خیلی خفنم ) براتون بیانش کنم
@codehalics | کدهالیک

امروز می‌خوام ادامه قوانین مهندسی نرم‌افزار رو ببرم سراغ یکی از خطرناک‌ترین باگ‌های ذهنی که حتی از باگ‌های کد هم بدتره؛ اثر Confirmation Bias یا سوگیری تأییدی. مغز ما دنبال حقیقت نیست، دنبال تأیید چیزیه که از قبل بهش باور داریم. وقتی یه فرض تو ذهنمون شکل می‌گیره (مثلاً مشکل از یه سرویسه)، فقط چیزهایی رو می‌بینیم که همونو تأیید کنه و بقیه نشونه‌ها رو نادیده می‌گیریم یا کم‌اهمیت می‌کنیم. همین باعث میشه تو دیباگ، طراحی سیستم یا تصمیم‌های معماری، مسیر اشتباه رو با اعتمادبه‌نفس بالا ادامه بدیم.

جالب اینجاست که هرچی مطمئن‌تر باشی “مشکل رو فهمیدی”، بیشتر تو این خطایی. چون ذهن دیگه دنبال رد فرضت نیست، فقط دنبال اثباتشه. برای همین آدم‌های باتجربه برعکس عمل می‌کنن؛ به جای اینکه بپرسن «چرا درسته؟» می‌پرسن «چرا ممکنه اشتباه باشه؟» و دنبال داده‌ای می‌گردن که فرضشون رو نقض کنه، نه تأیید. چون تو مهندسی نرم‌افزار، واقعیت به باور ما وفادار نیست، به چیزی وفاداره که واقعاً تو سیستم اتفاق می‌افته.

#lawsofsoftwareengineering
@codehalics | کدهالیک

خب امروزم قراره بریم به ادامه ی بحث جذاب قوانین مهندسی نرم افزار و قانون هافستدر (Hofstadter)

second t is silent

تلفظ دقیق فارسی : هافس (ساکن) تَ دِ ر

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

این موضوع مستقیم به استیمیت دادن توی Jira ربط داره، چون معمولاً تسک‌ها رو کمتر از واقعیت برآورد می‌کنیم و حتی وقتی سعی می‌کنیم محافظه‌کار باشیم باز هم خطا داریم. به همین خاطر تیم‌ها معمولاً از داده‌های اسپرینت‌های قبلی (velocity) و یه مقدار بافر استفاده می‌کنن تا استیمیت‌ها واقعی‌تر بشه و برنامه‌ریزی قابل اتکاتری داشته باشن.

#lawsofsoftwareengineering

@codehalics | کدهالیک

خب امروز که راجب ریداکس و اینکه اشتباهه ازش استفاده کنیم ولی قبلا خیلی ازش استفاده میشده صحبت کردیم پس قراره که ادامه قوانین مهندسی نرم افزار رو با همین موضوع ببریم جلو !

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

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

#lawsofsoftwareengineering

@codehalics | کدهالیک

از یک جلسه ۴ ساعته‌ی فرسایشی برای کانترکت api با یه شرکت خیلی خفن برگشتم ( من جلسه دوست ندارم و حوصلم سر میره وقتی طولانی شه )، ولی امروز میخوام ادامه قوانین مهندسی نرم افزار رو بهتون بگم و درباره قانون پرایس حرف می‌زنیم.

قانون پرایس می‌گه در هر تیم، ریشه دوم افراد (√N) حدود ۵۰٪ خروجی رو تولید می‌کنن. یعنی همیشه یک گروه کوچک بیشترین اثر رو روی نتیجه داره و بقیه نقش‌های مکمل دارن.

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

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

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

#lawsofsoftwareengineering

@codehalics | کدهالیک