ادامه قوانین مهندسی نرم افزار !
یه مفهومی توی تیمهای نرمافزاری هست به اسم Bus Factor. خیلی ساده یعنی چند نفر اگر از تیم حذف بشن، پروژه میخوابه؟ مثلا اگر فقط یک نفر بلد باشه سیستم پرداخت چطوری کار میکنه، فقط یک نفر دیتابیس رو بفهمه، یا فقط یک نفر بدونه دیپلوی چطوری انجام میشه، Bus Factor اون بخش میشه ۱. یعنی تیم عملا روی دانش یک نفر قفل شده و با نبودنش همهچیز کند، مبهم یا متوقف میشه.
هرچی Bus Factor بالاتر باشه، یعنی دانش بین آدمهای بیشتری پخش شده و تیم سالمتره. راهحلش هم خیلی پیچیده نیست: مستندسازی درست، کدریویو، جفتکار کردن، چرخوندن مسئولیتها، و اینکه هیچ آدمی تبدیل به تنها مرجع یک بخش حیاتی نشه. تیم خوب فقط با آدمهای باهوش ساخته نمیشه، با پخش شدن دانش و کم شدن وابستگیهای خطرناک ساخته میشه.
#lawsofsoftwareengineering
@codehalics | کدهالیک
یه مفهومی توی تیمهای نرمافزاری هست به اسم Bus Factor. خیلی ساده یعنی چند نفر اگر از تیم حذف بشن، پروژه میخوابه؟ مثلا اگر فقط یک نفر بلد باشه سیستم پرداخت چطوری کار میکنه، فقط یک نفر دیتابیس رو بفهمه، یا فقط یک نفر بدونه دیپلوی چطوری انجام میشه، Bus Factor اون بخش میشه ۱. یعنی تیم عملا روی دانش یک نفر قفل شده و با نبودنش همهچیز کند، مبهم یا متوقف میشه.
هرچی Bus Factor بالاتر باشه، یعنی دانش بین آدمهای بیشتری پخش شده و تیم سالمتره. راهحلش هم خیلی پیچیده نیست: مستندسازی درست، کدریویو، جفتکار کردن، چرخوندن مسئولیتها، و اینکه هیچ آدمی تبدیل به تنها مرجع یک بخش حیاتی نشه. تیم خوب فقط با آدمهای باهوش ساخته نمیشه، با پخش شدن دانش و کم شدن وابستگیهای خطرناک ساخته میشه.
#lawsofsoftwareengineering
@codehalics | کدهالیک
❤5👌1
کدهالیک | codehalic
ادامه قوانین مهندسی نرم افزار ! یه مفهومی توی تیمهای نرمافزاری هست به اسم Bus Factor. خیلی ساده یعنی چند نفر اگر از تیم حذف بشن، پروژه میخوابه؟ مثلا اگر فقط یک نفر بلد باشه سیستم پرداخت چطوری کار میکنه، فقط یک نفر دیتابیس رو بفهمه، یا فقط یک نفر بدونه…
یه مثال خیلی خوب برای Bus Factor، خود لینوکسه.
از بیرون بهنظر میاد پروژه خیلی به لینوس توروالدز وابستهست، ولی سوال اینه: چطوری کاری کرد که Bus Factor پروژه عملاً ۱ نمونه؟
یکی از جوابهای مهمش Git بود.
گیت کمک کرد توسعه لینوکس از حالت متمرکز خارج بشه؛ هر maintainer بتونه بخش خودش رو مدیریت کنه، تغییرات از چند لایه review رد بشه، و دانش و مسئولیت بین آدمهای مختلف پخش بشه.
لپ کلام: لینوس فقط آدم مهم پروژه نبود؛ سیستمی ساخت که پروژه بدون قفل شدن روی یک آدم، زنده بمونه.
فک نکنم از این قشنگ تر میشد باس فکتور و هندل کردنش توی لینوکس رو توضیح داد دی:
#lawsofsoftwareengineering
@codehalics | کدهالیک
از بیرون بهنظر میاد پروژه خیلی به لینوس توروالدز وابستهست، ولی سوال اینه: چطوری کاری کرد که Bus Factor پروژه عملاً ۱ نمونه؟
یکی از جوابهای مهمش Git بود.
گیت کمک کرد توسعه لینوکس از حالت متمرکز خارج بشه؛ هر maintainer بتونه بخش خودش رو مدیریت کنه، تغییرات از چند لایه review رد بشه، و دانش و مسئولیت بین آدمهای مختلف پخش بشه.
لپ کلام: لینوس فقط آدم مهم پروژه نبود؛ سیستمی ساخت که پروژه بدون قفل شدن روی یک آدم، زنده بمونه.
فک نکنم از این قشنگ تر میشد باس فکتور و هندل کردنش توی لینوکس رو توضیح داد دی:
#lawsofsoftwareengineering
@codehalics | کدهالیک
❤6
بریم ادامه قوانین مهندسی نرم افزار
لینوس لاو ( یا قانون لینوس ) یه ایده معروف تو دنیای برنامهنویسیه که میگه: «اگه آدمهای زیادی کد رو ببینن، پیدا کردن باگها راحتتر میشه.» یعنی وقتی یه پروژه اوپنسورس باشه و کلی دولوپر و کاربر بهش دسترسی داشته باشن، احتمال اینکه یکی مشکل رو پیدا کنه یا حتی براش راهحل بده خیلی بیشتره. چیزی که برای یه برنامهنویس پیچیده و گیجکنندهست، شاید برای یه نفر دیگه خیلی واضح باشه. به خاطر همین پروژههایی مثل لینوکس یا Apache معمولاً سریعتر باگهاشون کشف و درست میشه.
البته این قانون همیشه هم معجزه نمیکنه. فقط اوپنسورس بودن کافی نیست؛ باید آدمهایی واقعاً در حال بررسی و مشارکت باشن. مثلاً باگ معروف Heartbleed توی OpenSSL دو سال مخفی مونده بود، با اینکه پروژه کاملاً متنباز بود. یعنی «چشم زیاد» وقتی مفیده که واقعاً کسی داره نگاه میکنه. به همین خاطر این قانون بیشتر از اینکه یه حقیقت مطلق باشه، یه یادآوریه که همکاری، شفافیت و کد ریویو جمعی معمولاً کیفیت نرمافزار رو بهتر میکنه.
#lawsofsoftwareengineering
@codehalics | کدهالیک
لینوس لاو ( یا قانون لینوس ) یه ایده معروف تو دنیای برنامهنویسیه که میگه: «اگه آدمهای زیادی کد رو ببینن، پیدا کردن باگها راحتتر میشه.» یعنی وقتی یه پروژه اوپنسورس باشه و کلی دولوپر و کاربر بهش دسترسی داشته باشن، احتمال اینکه یکی مشکل رو پیدا کنه یا حتی براش راهحل بده خیلی بیشتره. چیزی که برای یه برنامهنویس پیچیده و گیجکنندهست، شاید برای یه نفر دیگه خیلی واضح باشه. به خاطر همین پروژههایی مثل لینوکس یا Apache معمولاً سریعتر باگهاشون کشف و درست میشه.
البته این قانون همیشه هم معجزه نمیکنه. فقط اوپنسورس بودن کافی نیست؛ باید آدمهایی واقعاً در حال بررسی و مشارکت باشن. مثلاً باگ معروف Heartbleed توی OpenSSL دو سال مخفی مونده بود، با اینکه پروژه کاملاً متنباز بود. یعنی «چشم زیاد» وقتی مفیده که واقعاً کسی داره نگاه میکنه. به همین خاطر این قانون بیشتر از اینکه یه حقیقت مطلق باشه، یه یادآوریه که همکاری، شفافیت و کد ریویو جمعی معمولاً کیفیت نرمافزار رو بهتر میکنه.
#lawsofsoftwareengineering
@codehalics | کدهالیک
❤3
بریم برای ادامه قوانین مهندسی نرمافزار بعد از مدتها. اینبار سراغ Pareto Principle یا قانون ۸۰/۲۰ بریم؛ قانونی که میگه معمولاً ۸۰ درصد نتیجهها از ۲۰ درصد علتها میاد. توی نرمافزار یعنی همهچیز به یک اندازه مهم نیست. مثلاً ممکنه ۲۰ درصد فیچرهای یک محصول، ۸۰ درصد استفاده کاربران رو بسازن؛ یا ۲۰ درصد باگها، عامل بیشتر کرشها و نارضایتیها باشن. پس بهجای اینکه انرژی تیم رو مساوی بین همهچیز پخش کنیم، باید بفهمیم اون بخشهای کمتعداد ولی پراثر کجان و اولویت رو بذاریم روی همونا.
#lawsofsoftwareengineering
@codehalics | کدهالیک
#lawsofsoftwareengineering
@codehalics | کدهالیک
❤1
کدهالیک | codehalic
confirmation bias
حالا که صحبت از سوگیری تاییدی یا کانفرمیشن بایاس شد داغ دل من تازه شد که چند روزه قوانین مهندسی نرم افزار رو نگفتم خب پس بریم ادامه قوانین مهندسی نرم افزار :
سوگیری تأییدی یعنی ذهن ما معمولاً دنبال چیزهایی میگردد که حرف، حدس یا باور قبلیمان را تأیید کند؛ نه چیزهایی که آن را به چالش بکشد. مثلا وقتی یک برنامهنویس فکر میکند باگ از ماژول A است، ممکن است فقط همان بخش را زیر و رو کند و خطاهای ماژول B را نبیند، چون از قبل تصمیم گرفته «مشکل آنجاست». این اتفاق در کد ریویو هم میافتد؛ اگر به یک نفر اعتماد زیادی داشته باشیم، شاید کدش را سطحیتر ببینیم، یا اگر از یک نیروی junior انتظار خطا داشته باشیم، ممکن است چیزهای کماهمیت را جدی تلقی کنیم.
#lawsofsoftwareengineering
@codehalics | کدهالیک
سوگیری تأییدی یعنی ذهن ما معمولاً دنبال چیزهایی میگردد که حرف، حدس یا باور قبلیمان را تأیید کند؛ نه چیزهایی که آن را به چالش بکشد. مثلا وقتی یک برنامهنویس فکر میکند باگ از ماژول A است، ممکن است فقط همان بخش را زیر و رو کند و خطاهای ماژول B را نبیند، چون از قبل تصمیم گرفته «مشکل آنجاست». این اتفاق در کد ریویو هم میافتد؛ اگر به یک نفر اعتماد زیادی داشته باشیم، شاید کدش را سطحیتر ببینیم، یا اگر از یک نیروی junior انتظار خطا داشته باشیم، ممکن است چیزهای کماهمیت را جدی تلقی کنیم.
#lawsofsoftwareengineering
@codehalics | کدهالیک
👀1
خب امروز یکی دیگ از قوانین مهندسی نرم افزار که داره به KISS صحه میزاره رو قراره بررسی کنیم !
قانون کرنیگان میگه وقتی کدی رو زیادی پیچیده و هوشمندانه مینویسی، بعداً برای پیدا کردن باگهاش چند برابر بیشتر اذیت میشی. موقع نوشتن کد، همهچیز توی ذهنت واضحه، ولی چند روز یا چند ماه بعد، همون کد میتونه برات تبدیل به یه معما بشه. پس بهتره کد رو ساده، خوانا و قابلفهم بنویسی؛ چون کدی که راحت فهمیده میشه، راحتتر هم درست و نگهداری میشه.
#lawsofsoftwareengineering
@codehalics | کدهالیک
قانون کرنیگان میگه وقتی کدی رو زیادی پیچیده و هوشمندانه مینویسی، بعداً برای پیدا کردن باگهاش چند برابر بیشتر اذیت میشی. موقع نوشتن کد، همهچیز توی ذهنت واضحه، ولی چند روز یا چند ماه بعد، همون کد میتونه برات تبدیل به یه معما بشه. پس بهتره کد رو ساده، خوانا و قابلفهم بنویسی؛ چون کدی که راحت فهمیده میشه، راحتتر هم درست و نگهداری میشه.
#lawsofsoftwareengineering
@codehalics | کدهالیک
❤2👍1
توی آموزش قوانین مهندسی نرم افزار به یه قانون جدید برمیخوریم که امروز هادی جان احمدی بررسیش کردن و من هم میخوام بهش بپردازم :
ADR (Architecture Decision Record)
یه جور سند کوتاه و سادهست که توی پروژههای نرمافزاری، تصمیمهای مهم معماری رو ثبت میکنه. تصور کن داری انتخاب میکنی کدوم دیتابیس رو استفاده کنی، یا بری سراغ میکروسرویس یا مونولیث؛ به جای اینکه فقط توی کد بزنی و بعداً همه یادشون بره چرا این کار رو کردید، یه فایل کوچیک markdown مینویسی، مشکل رو توضیح میدی، گزینهها رو مقایسه میکنی، میگی چرا این یکی رو انتخاب کردی و چه خوبی و بدیهایی داره. اینطوری تیم جدید که میاد گیج نمیشه، بعداً هم راحت میتونی ببینی تصمیمها چطور تکامل پیدا کردن. خیلی خودمونی بگم، مثل یه دفترچه خاطرات برای تصمیمهای فنی پروژهته که جلوی تکرار اشتباهات و دعواهای بیخودی رو میگیره.
عمو مارتین فولر راجبش تو بلاگش نوشته
https://martinfowler.com/bliki/ArchitectureDecisionRecord.html
#lawsofsoftwareengineering
سورس توییت از استاد هادی احمدی
@codehalics | کدهالیک
ADR (Architecture Decision Record)
یه جور سند کوتاه و سادهست که توی پروژههای نرمافزاری، تصمیمهای مهم معماری رو ثبت میکنه. تصور کن داری انتخاب میکنی کدوم دیتابیس رو استفاده کنی، یا بری سراغ میکروسرویس یا مونولیث؛ به جای اینکه فقط توی کد بزنی و بعداً همه یادشون بره چرا این کار رو کردید، یه فایل کوچیک markdown مینویسی، مشکل رو توضیح میدی، گزینهها رو مقایسه میکنی، میگی چرا این یکی رو انتخاب کردی و چه خوبی و بدیهایی داره. اینطوری تیم جدید که میاد گیج نمیشه، بعداً هم راحت میتونی ببینی تصمیمها چطور تکامل پیدا کردن. خیلی خودمونی بگم، مثل یه دفترچه خاطرات برای تصمیمهای فنی پروژهته که جلوی تکرار اشتباهات و دعواهای بیخودی رو میگیره.
عمو مارتین فولر راجبش تو بلاگش نوشته
https://martinfowler.com/bliki/ArchitectureDecisionRecord.html
#lawsofsoftwareengineering
سورس توییت از استاد هادی احمدی
@codehalics | کدهالیک
❤6
خیلی وقت بود نرفته بودیم سر قوانین مهندسی نرم افزار امروز یه قوانین بامزه رو که تقریبا هممون تا الان حسش کردیم رو بررسی میکنیم :
امروز یه قانون بامزه دیدم به اسم Putt’s Law که خیلی خلاصه میگه توی سازمانهای فنی، معمولاً اونایی که تکنولوژی رو عمیق میفهمن تصمیمگیر نهایی نیستن، و اونایی که تصمیم نهایی رو میگیرن، همیشه عمق فنی ماجرا رو نمیبینن. برای همین هم خیلی وقتها مدیر فکر میکنه «این که کاری نداره، تا هفته بعد آمادهست»، ولی تیم فنی میدونه پشت همون «کاری نداره» کلی وابستگی، تست، ریسک، زیرساخت، دیتابیس و بدبختی خوابیده. از اون طرف هم اگر آدمهای فنی از بیزینس و محصول دور بمونن، ممکنه بهترین راهحل فنی دنیا رو بسازن، اما دقیقاً مسئله درست رو حل نکنن. تهش انگار این قانون میگه درد اصلی تیمهای نرمافزاری فقط تکنولوژی نیست؛ فاصله بین فهم فنی و قدرت تصمیمگیریه.
#lawsofsoftwareengineering
@codehalics | کدهالیک
امروز یه قانون بامزه دیدم به اسم Putt’s Law که خیلی خلاصه میگه توی سازمانهای فنی، معمولاً اونایی که تکنولوژی رو عمیق میفهمن تصمیمگیر نهایی نیستن، و اونایی که تصمیم نهایی رو میگیرن، همیشه عمق فنی ماجرا رو نمیبینن. برای همین هم خیلی وقتها مدیر فکر میکنه «این که کاری نداره، تا هفته بعد آمادهست»، ولی تیم فنی میدونه پشت همون «کاری نداره» کلی وابستگی، تست، ریسک، زیرساخت، دیتابیس و بدبختی خوابیده. از اون طرف هم اگر آدمهای فنی از بیزینس و محصول دور بمونن، ممکنه بهترین راهحل فنی دنیا رو بسازن، اما دقیقاً مسئله درست رو حل نکنن. تهش انگار این قانون میگه درد اصلی تیمهای نرمافزاری فقط تکنولوژی نیست؛ فاصله بین فهم فنی و قدرت تصمیمگیریه.
#lawsofsoftwareengineering
@codehalics | کدهالیک
❤2
میدونم که دلتون برای قوانین مهندسی نرم افزار تنگ شده بود (الکی)
یه تصور خطرناک توی تیمسازی هست که میگه: «کار عقب افتاده؟ آدم اضافه کن.»
ولی اثر رینگلمان دقیقاً همینجا میزنه زیر میز.
میگه هرچی تعداد آدمهای یک گروه بیشتر میشه، الزاماً خروجی بیشتر نمیشه؛ حتی گاهی تلاشِ هر نفر کمتر هم میشه. نه چون آدمها بدتر میشن، نه چون کسی قصد کمکاری داره. مسئله اینه که وقتی جمع بزرگ میشه، مسئولیت بین آدمها پخش میشه، سهم هر نفر کمتر دیده میشه، هماهنگی سختتر میشه و آدمها ناخودآگاه عقبتر میایستن.
یه جلسه سهنفره رو تصور کن. تقریباً همه حرف میزنن، نظر میدن، مسئولیت میگیرن. حالا همون موضوع رو ببر توی جلسه پونزدهنفره. چند نفر حرف میزنن؟ چند نفر فقط گوش میدن؟ چند نفر ته ذهنشون میگن «یکی دیگه بالاخره میگه»؟
توی تیم فنی هم همین داستانه. همیشه اضافه کردن دولوپر یعنی سرعت بیشتر نیست. گاهی یعنی کانفلیکت بیشتر، مرج بیشتر، جلسه بیشتر، وابستگی بیشتر، منتظر موندن بیشتر. یعنی تیم به جای اینکه انرژیاش بره پای ساختن محصول، خرج هماهنگ کردن خودش میشه.
#lawsofsoftwareengineering
@codehalics | کدهالیک
یه تصور خطرناک توی تیمسازی هست که میگه: «کار عقب افتاده؟ آدم اضافه کن.»
ولی اثر رینگلمان دقیقاً همینجا میزنه زیر میز.
میگه هرچی تعداد آدمهای یک گروه بیشتر میشه، الزاماً خروجی بیشتر نمیشه؛ حتی گاهی تلاشِ هر نفر کمتر هم میشه. نه چون آدمها بدتر میشن، نه چون کسی قصد کمکاری داره. مسئله اینه که وقتی جمع بزرگ میشه، مسئولیت بین آدمها پخش میشه، سهم هر نفر کمتر دیده میشه، هماهنگی سختتر میشه و آدمها ناخودآگاه عقبتر میایستن.
یه جلسه سهنفره رو تصور کن. تقریباً همه حرف میزنن، نظر میدن، مسئولیت میگیرن. حالا همون موضوع رو ببر توی جلسه پونزدهنفره. چند نفر حرف میزنن؟ چند نفر فقط گوش میدن؟ چند نفر ته ذهنشون میگن «یکی دیگه بالاخره میگه»؟
توی تیم فنی هم همین داستانه. همیشه اضافه کردن دولوپر یعنی سرعت بیشتر نیست. گاهی یعنی کانفلیکت بیشتر، مرج بیشتر، جلسه بیشتر، وابستگی بیشتر، منتظر موندن بیشتر. یعنی تیم به جای اینکه انرژیاش بره پای ساختن محصول، خرج هماهنگ کردن خودش میشه.
#lawsofsoftwareengineering
@codehalics | کدهالیک
👍6❤3🔥1