بریم برای ادامه قوانین مهندسی نرم‌افزار بعد از مدت‌ها. این‌بار سراغ Pareto Principle یا قانون ۸۰/۲۰ بریم؛ قانونی که میگه معمولاً ۸۰ درصد نتیجه‌ها از ۲۰ درصد علت‌ها میاد. توی نرم‌افزار یعنی همه‌چیز به یک اندازه مهم نیست. مثلاً ممکنه ۲۰ درصد فیچرهای یک محصول، ۸۰ درصد استفاده کاربران رو بسازن؛ یا ۲۰ درصد باگ‌ها، عامل بیشتر کرش‌ها و نارضایتی‌ها باشن. پس به‌جای اینکه انرژی تیم رو مساوی بین همه‌چیز پخش کنیم، باید بفهمیم اون بخش‌های کم‌تعداد ولی پراثر کجان و اولویت رو بذاریم روی همونا.

#lawsofsoftwareengineering

@codehalics | کدهالیک

حالا که صحبت از سوگیری تاییدی یا کانفرمیشن بایاس شد داغ دل من تازه شد که چند روزه قوانین مهندسی نرم افزار رو نگفتم خب پس بریم ادامه قوانین مهندسی نرم افزار :

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


#lawsofsoftwareengineering

@codehalics | کدهالیک

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

#lawsofsoftwareengineering

@codehalics | کدهالیک

توی آموزش قوانین مهندسی نرم افزار به یه قانون جدید برمیخوریم که امروز هادی جان احمدی بررسیش کردن و من هم میخوام بهش بپردازم :

ADR (Architecture Decision Record)

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

عمو مارتین فولر راجبش تو بلاگش نوشته

https://martinfowler.com/bliki/ArchitectureDecisionRecord.html


#lawsofsoftwareengineering

سورس توییت از استاد هادی احمدی

@codehalics | کدهالیک

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

امروز یه قانون بامزه دیدم به اسم Putt’s Law که خیلی خلاصه می‌گه توی سازمان‌های فنی، معمولاً اونایی که تکنولوژی رو عمیق می‌فهمن تصمیم‌گیر نهایی نیستن، و اونایی که تصمیم نهایی رو می‌گیرن، همیشه عمق فنی ماجرا رو نمی‌بینن. برای همین هم خیلی وقت‌ها مدیر فکر می‌کنه «این که کاری نداره، تا هفته بعد آماده‌ست»، ولی تیم فنی می‌دونه پشت همون «کاری نداره» کلی وابستگی، تست، ریسک، زیرساخت، دیتابیس و بدبختی خوابیده. از اون طرف هم اگر آدم‌های فنی از بیزینس و محصول دور بمونن، ممکنه بهترین راه‌حل فنی دنیا رو بسازن، اما دقیقاً مسئله درست رو حل نکنن. تهش انگار این قانون می‌گه درد اصلی تیم‌های نرم‌افزاری فقط تکنولوژی نیست؛ فاصله بین فهم فنی و قدرت تصمیم‌گیریه.

#lawsofsoftwareengineering

@codehalics | کدهالیک

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

یه تصور خطرناک توی تیم‌سازی هست که می‌گه: «کار عقب افتاده؟ آدم اضافه کن.»

ولی اثر رینگلمان دقیقاً همین‌جا می‌زنه زیر میز.

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

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

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

#lawsofsoftwareengineering

@codehalics | کدهالیک