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

اصل 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 | کدهالیک

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

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

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

#lawsofsoftwareengineering

@codehalics | کدهالیک

امروز میریم ادامه قوانین مهندسی نرم افزار رو بررسی کنیم و یک کانسپت بسیار جذاب در سیستم های توزیع شده رو بررسی میکنیم

قضیه‌ی CAP (Consistency – Availability – Partition Tolerance)
میگه تو سیستم‌های توزیع شده نمی‌تونی هر سه تا ویژگی رو هم‌زمان به‌طور کامل داشته باشی: اینکه همه نودها همیشه کانسیستنت باشه دیتای روشون ، سیستم همیشه در دسترس باشه و هر درخواست جواب بگیره، و حتی وقتی ارتباط بین سرورها قطع میشه (partition) سیستم همچنان کار کنه.

چون قطعی شبکه توی سیستم‌های واقعی اجتناب‌ناپذیره، عملاً باید موقع مشکل بین Consistency و Availability یکی رو انتخاب کنی. مثلاً MongoDB بیشتر سمت Consistency + Partition Tolerance میره؛ یعنی اگر بین سرورها مشکل پیش بیاد، ترجیح میده بعضی درخواست‌ها رو جواب نده تا مطمئن بشه داده‌ها دقیق و یکسان می‌مونن. در مقابل، Cassandra بیشتر سمت Availability + Partition Tolerance میره؛ یعنی همیشه به درخواست‌ها جواب میده حتی اگر موقتاً بعضی نودها داده‌های متفاوت یا قدیمی داشته باشن، و بعداً اون‌ها رو هماهنگ می‌کنه.


#lawsofsoftwareengineering

@codehalics | کدهالیک

خب بریم قوانین مهندسی نرم افزار امروز و یک قانون از آنکل باب معروف

قانون Boy Scout Rule که توسط Robert C. Martin معروف شد، یه اصل ساده داره: *هر جا به کد دست می‌زنی، یه ذره بهترش کن قبل از اینکه ولش کنی*. لازم نیست پروژه رو از اول بنویسی یا همه‌چیز رو کامل کنی؛ فقط همون بخشی که داری روش کار می‌کنی رو تمیزتر کن. مثلاً اسم متغیرها رو واضح‌تر کن، کد تکراری رو جمع کن، یا یه فانکشن خیلی طولانی رو کوچیک‌تر کن.

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

#lawsofsoftwareengineering

@codehalics | کدهالیک

ادامه قوانین مهندسی نرم افزار !

یه مفهومی توی تیم‌های نرم‌افزاری هست به اسم Bus Factor. خیلی ساده یعنی چند نفر اگر از تیم حذف بشن، پروژه می‌خوابه؟ مثلا اگر فقط یک نفر بلد باشه سیستم پرداخت چطوری کار می‌کنه، فقط یک نفر دیتابیس رو بفهمه، یا فقط یک نفر بدونه دیپلوی چطوری انجام میشه، Bus Factor اون بخش میشه ۱. یعنی تیم عملا روی دانش یک نفر قفل شده و با نبودنش همه‌چیز کند، مبهم یا متوقف میشه.

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

#lawsofsoftwareengineering

@codehalics | کدهالیک

یه مثال خیلی خوب برای Bus Factor، خود لینوکسه.

از بیرون به‌نظر میاد پروژه خیلی به لینوس توروالدز وابسته‌ست، ولی سوال اینه: چطوری کاری کرد که Bus Factor پروژه عملاً ۱ نمونه؟

یکی از جواب‌های مهمش Git بود.

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

لپ کلام: لینوس فقط آدم مهم پروژه نبود؛ سیستمی ساخت که پروژه بدون قفل شدن روی یک آدم، زنده بمونه.

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

#lawsofsoftwareengineering

@codehalics | کدهالیک

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

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

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

#lawsofsoftwareengineering

@codehalics | کدهالیک

بریم برای ادامه قوانین مهندسی نرم‌افزار بعد از مدت‌ها. این‌بار سراغ 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 | کدهالیک