تا حالا شده توی خونه مبل رو جوری بذاری که جلوی پریز رو بگیره ولی بعد یه مدت به همون وضعیت عادت کنی؟ حالا اگه یکی بیاد مبل رو جابهجا کنه که خونه رو قشنگ کنه، شاکی میشی چون تمام نظم ذهنی تو به هم ریخته. این دقیقا خلاصه اتفاقیه که بهش میگن قانون هایروم.
این قانون تبدیل شده به یکی از قوانین نانوشته مهندسی نرم افزار که خیلی خوبه که یادش بگیرید !
حرف حساب این قانون ساده است: اگه کدی که زدی کاربر زیادی داشته باشه، دیگه مهم نیست توی داکیومنت و راهنما چی نوشتی. مردم به جای اینکه بخونن تو چی گفتی، نگاه میکنن کدت در عمل چیکار میکنه و دقیقا روی همون رفتار (حتی اگه غلط یا اتفاقی باشه) حساب باز میکنن.
یه مثال واقعی و عجیب از دنیای لینوکس:
یه بار مهندسهای گوگل دیدن توی خروجی لیست فایلهای لینوکس چندتا فاصله خالی (Space) بیخود وجود داره. اونا هم از روی دلسوزی این اسپیسها رو حذف کردن که خروجی تمیز بشه. به محض منتشر شدن این تغییر، کلی از برنامههای دنیا از کار افتاد! چرا؟ چون برنامهنویسهای دیگه کدشون رو جوری نوشته بودن که مثلا میگفت: برو کاراکتر شماره ۲۰ رو بردار. اونا از اون فاصلههای بیخود به عنوان خطکش استفاده میکردن و با حذف اونا، کل محاسباتشون غلط شد.
یا مثلا یه کتابخونه قدیمی بود که وقتی فضای هارد خیلی زیاد میشد، به خاطر باگ، عدد رو منفی نشون میداد. بقیه به جای گزارش باگ، توی کدشون نوشتن: اگه عدد منفی بود یعنی فضا خیلی زیاده! حالا اگه سازنده بیاد این باگ رو درست کنه و عدد رو مثبت نشون بده، برنامه تمام اون آدمها میترکه چون فکر میکنن فضای هارد تموم شده.
ته داستان اینه که وقتی نرمافزارت بزرگ و پرکاربر میشه، تو دیگه صاحب ۱۰۰ درصد کدت نیستی. هر حرکت کوچیکی که بزنی، یه جای دنیا یه نفر هست که به اون مدل "تپق" زدن کدت عادت کرده و اگه اصلاحش کنی، زندگیش به هم میخوره. توی ابعاد بزرگ، دیگه فرقی بین باگ و ویژگی وجود نداره؛ هر چیزی که کاربر میبینه، براش میشه قانون.
تا حالا بهش برخوردین ؟ دوست دارم نظرتونو بدونم راجبش !
#lawsofsoftwareengineering
@codehalics | کدهالیک
این قانون تبدیل شده به یکی از قوانین نانوشته مهندسی نرم افزار که خیلی خوبه که یادش بگیرید !
حرف حساب این قانون ساده است: اگه کدی که زدی کاربر زیادی داشته باشه، دیگه مهم نیست توی داکیومنت و راهنما چی نوشتی. مردم به جای اینکه بخونن تو چی گفتی، نگاه میکنن کدت در عمل چیکار میکنه و دقیقا روی همون رفتار (حتی اگه غلط یا اتفاقی باشه) حساب باز میکنن.
یه مثال واقعی و عجیب از دنیای لینوکس:
یه بار مهندسهای گوگل دیدن توی خروجی لیست فایلهای لینوکس چندتا فاصله خالی (Space) بیخود وجود داره. اونا هم از روی دلسوزی این اسپیسها رو حذف کردن که خروجی تمیز بشه. به محض منتشر شدن این تغییر، کلی از برنامههای دنیا از کار افتاد! چرا؟ چون برنامهنویسهای دیگه کدشون رو جوری نوشته بودن که مثلا میگفت: برو کاراکتر شماره ۲۰ رو بردار. اونا از اون فاصلههای بیخود به عنوان خطکش استفاده میکردن و با حذف اونا، کل محاسباتشون غلط شد.
یا مثلا یه کتابخونه قدیمی بود که وقتی فضای هارد خیلی زیاد میشد، به خاطر باگ، عدد رو منفی نشون میداد. بقیه به جای گزارش باگ، توی کدشون نوشتن: اگه عدد منفی بود یعنی فضا خیلی زیاده! حالا اگه سازنده بیاد این باگ رو درست کنه و عدد رو مثبت نشون بده، برنامه تمام اون آدمها میترکه چون فکر میکنن فضای هارد تموم شده.
ته داستان اینه که وقتی نرمافزارت بزرگ و پرکاربر میشه، تو دیگه صاحب ۱۰۰ درصد کدت نیستی. هر حرکت کوچیکی که بزنی، یه جای دنیا یه نفر هست که به اون مدل "تپق" زدن کدت عادت کرده و اگه اصلاحش کنی، زندگیش به هم میخوره. توی ابعاد بزرگ، دیگه فرقی بین باگ و ویژگی وجود نداره؛ هر چیزی که کاربر میبینه، براش میشه قانون.
تا حالا بهش برخوردین ؟ دوست دارم نظرتونو بدونم راجبش !
#lawsofsoftwareengineering
@codehalics | کدهالیک
❤8👏4🤣1
کدهالیک | codehalic
تا حالا شده توی خونه مبل رو جوری بذاری که جلوی پریز رو بگیره ولی بعد یه مدت به همون وضعیت عادت کنی؟ حالا اگه یکی بیاد مبل رو جابهجا کنه که خونه رو قشنگ کنه، شاکی میشی چون تمام نظم ذهنی تو به هم ریخته. این دقیقا خلاصه اتفاقیه که بهش میگن قانون هایروم. این…
خودم توی شرکت قبلی دقیقاً با این داستان برخورد کردم. داشتیم سیستم سرچ رو بازطراحی میکردیم و من اصلاً حواسم به این نبود که یه سری از کاربرها عادت کردن «شناسه ملی» شرکت رو بزنن و اینتر کنن تا مستقیم برن توی پروفایل اون شرکت. این قابلیت اصلاً توی تسک من تعریف نشده بود، ولی چون کاربرها به این «میانبر» عادت کرده بودن، نبودنش رو به چشم یه باگ میدیدن. وقتی این قابلیت رو دوباره اضافه کردیم، تازه فهمیدیم چقدر توی زمان کاربرها صرفهجویی میشه و چقدر خوشحالتر شدن.
این قانون دقیقاً همینه: توی بازطراحی یا همون Migration سیستمها، نباید فقط به فیچرهای رسمی نگاه کرد.
اما این هایروم کیه؟
هایروم رایت یکی از مهندسهای ارشد گوگل هست که تخصصش تغییر دادن کدهایی در مقیاس میلیون خطیه. اون موقعی که داشت روی کتابخانههای مرکزی گوگل کار میکرد، متوجه شد حتی وقتی یه تغییر خیلی ساده و به ظاهر بیضرر مثل حذف یه «فاصله خالی» یا عوض کردن رنگ یه آیکون رو انجام میده، باز هم یه جایی یه چیزی خراب میشه.
هایروم به این نتیجه رسید که هر چقدر هم به کاربرها التماس کنی که «فقط به داکیومنت من اعتماد کنید»، باز هم اونا میرن و از رفتارهای غیررسمی و جانبی کد تو استفاده میکنن. واسه همین این قانون رو گذاشت تا به بقیه هشدار بده: وقتی کدت محبوب شد و آدمهای زیادی ازش استفاده کردن، دیگه اون کد فقط متعلق به تو نیست و نمیتونی به راحتی هر جاش رو که خواستی عوض کنی.
#lawsofsoftwareengineering
@codehalics | کدهالیک
این قانون دقیقاً همینه: توی بازطراحی یا همون Migration سیستمها، نباید فقط به فیچرهای رسمی نگاه کرد.
اما این هایروم کیه؟
هایروم رایت یکی از مهندسهای ارشد گوگل هست که تخصصش تغییر دادن کدهایی در مقیاس میلیون خطیه. اون موقعی که داشت روی کتابخانههای مرکزی گوگل کار میکرد، متوجه شد حتی وقتی یه تغییر خیلی ساده و به ظاهر بیضرر مثل حذف یه «فاصله خالی» یا عوض کردن رنگ یه آیکون رو انجام میده، باز هم یه جایی یه چیزی خراب میشه.
هایروم به این نتیجه رسید که هر چقدر هم به کاربرها التماس کنی که «فقط به داکیومنت من اعتماد کنید»، باز هم اونا میرن و از رفتارهای غیررسمی و جانبی کد تو استفاده میکنن. واسه همین این قانون رو گذاشت تا به بقیه هشدار بده: وقتی کدت محبوب شد و آدمهای زیادی ازش استفاده کردن، دیگه اون کد فقط متعلق به تو نیست و نمیتونی به راحتی هر جاش رو که خواستی عوض کنی.
#lawsofsoftwareengineering
@codehalics | کدهالیک
🤯4👏3
خب امروز میخوام راجب یه قانون دیگ در توسعه نرم افزار صحبت کنم که بیشتر جنبه محصولی داره !
قانون زاوینسکی
قانون زاویِنسکی میگه: هر برنامهای وقتی موفق میشه، کمکم شروع میکنه به اضافه کردن فیچرهای جدید، تا جایی که از هدف اصلی خودش فاصله میگیره و حتی تبدیل میشه به یه محصول «همهفنحریف» که هیچ کاری رو واقعاً عالی انجام نمیده. همون چیزی که میگن: Jack of all trades, master of none.
مثلاً تلگرام اول فقط یه پیامرسان ساده بود، اما کمکم تبدیل شد به یه پلتفرم کامل: تماس صوتی و تصویری، کانال، استوری، بات، پرداخت و حتی مینیاپها. الان دیگه فقط «چت» نیست، یه اکوسیستمه.
این قانون بیشتر برای پروداکت منیجرها مهمه، چون دائماً بین دو فشار گیر میکنن: رشد محصول با اضافه کردن قابلیتهای جدید، یا حفظ سادگی و تمرکز. چالش اصلی اینه که بدونی چی رو نباید اضافه کنی.
پ.ن: البته در بعضی بازارها (بهخصوص کشورهای در حال توسعه)، سوپراپ شدن خودش یه مزیت رقابتیه. چون یه اپ میتونه چندین سرویس رو یکجا جمع کنه؛ مثل تاکسی، غذا، خرید، خدمات پزشکی و… نمونههاش هم توی ایران زیاده.
#lawsofsoftwareengineering
@codehalics | کدهالیک
قانون زاوینسکی
قانون زاویِنسکی میگه: هر برنامهای وقتی موفق میشه، کمکم شروع میکنه به اضافه کردن فیچرهای جدید، تا جایی که از هدف اصلی خودش فاصله میگیره و حتی تبدیل میشه به یه محصول «همهفنحریف» که هیچ کاری رو واقعاً عالی انجام نمیده. همون چیزی که میگن: Jack of all trades, master of none.
مثلاً تلگرام اول فقط یه پیامرسان ساده بود، اما کمکم تبدیل شد به یه پلتفرم کامل: تماس صوتی و تصویری، کانال، استوری، بات، پرداخت و حتی مینیاپها. الان دیگه فقط «چت» نیست، یه اکوسیستمه.
این قانون بیشتر برای پروداکت منیجرها مهمه، چون دائماً بین دو فشار گیر میکنن: رشد محصول با اضافه کردن قابلیتهای جدید، یا حفظ سادگی و تمرکز. چالش اصلی اینه که بدونی چی رو نباید اضافه کنی.
پ.ن: البته در بعضی بازارها (بهخصوص کشورهای در حال توسعه)، سوپراپ شدن خودش یه مزیت رقابتیه. چون یه اپ میتونه چندین سرویس رو یکجا جمع کنه؛ مثل تاکسی، غذا، خرید، خدمات پزشکی و… نمونههاش هم توی ایران زیاده.
#lawsofsoftwareengineering
@codehalics | کدهالیک
👍4
خب امروز میخوام برم ادامه قوانین مهندسی نرم افزار رو بازگو کنم براتون و امروز راجب یه اصل بسیار پر تکرار قراره صحبت کنیم که قطعا خیلیاتون اسمشو شنیدید !
اصل KISS (Keep It Simple, Stupid) تو مهندسی نرمافزار میگه تا جای ممکن راهحلهات رو ساده نگه دار و الکی پیچیدش نکن. یعنی اگر میشه یه مسئله رو با یه کد کوتاه و قابل فهم حل کرد، لازم نیست بری سمت معماریهای سنگین و عجیب فقط برای اینکه «باحال» به نظر بیاد. واقعیت اینه که هر خط کد اضافه، یه فرصت جدیده برای باگ و دردسر. کد ساده هم سریعتر خونده میشه، هم راحتتر دیباگ میشه، هم وقتی چند ماه بعد خودت برمیگردی سراغش کمتر فحش میدی به گذشتهات.
خلاصه اینکه اول کاری کن برنامهات درست کار کنه، بعد اگر واقعاً لازم شد تمیزترش کن یا بهینهاش کن. سادگی نهتنها نشونه تنبلی نیست، بلکه نشونه درک درست مسئلهست.
#lawsofsoftwareengineering
@codehalics | کدهالیک
اصل KISS (Keep It Simple, Stupid) تو مهندسی نرمافزار میگه تا جای ممکن راهحلهات رو ساده نگه دار و الکی پیچیدش نکن. یعنی اگر میشه یه مسئله رو با یه کد کوتاه و قابل فهم حل کرد، لازم نیست بری سمت معماریهای سنگین و عجیب فقط برای اینکه «باحال» به نظر بیاد. واقعیت اینه که هر خط کد اضافه، یه فرصت جدیده برای باگ و دردسر. کد ساده هم سریعتر خونده میشه، هم راحتتر دیباگ میشه، هم وقتی چند ماه بعد خودت برمیگردی سراغش کمتر فحش میدی به گذشتهات.
خلاصه اینکه اول کاری کن برنامهات درست کار کنه، بعد اگر واقعاً لازم شد تمیزترش کن یا بهینهاش کن. سادگی نهتنها نشونه تنبلی نیست، بلکه نشونه درک درست مسئلهست.
#lawsofsoftwareengineering
@codehalics | کدهالیک
👍3❤2🔥1
کدهالیک | codehalic
خب امروز میخوام برم ادامه قوانین مهندسی نرم افزار رو بازگو کنم براتون و امروز راجب یه اصل بسیار پر تکرار قراره صحبت کنیم که قطعا خیلیاتون اسمشو شنیدید ! اصل KISS (Keep It Simple, Stupid) تو مهندسی نرمافزار میگه تا جای ممکن راهحلهات رو ساده نگه دار و الکی…
مثل همیشه یه مثال واقعی از دنیای کار خودم بزنم درباره KISS.
قرار بود تو یه پروژه خیلی خفن جوین بشم، تیم هم واقعاً قوی بود و همهچیز عالی پیش میرفت تا اینکه یه مدیرفنی به تیم اضافه شد. از روز اول شروع کرد به اینکه این باندد کانتکستها باید جدا شن، اینو میکروسرویس میکنیم، اینجا RabbitMQ میذاریم، اونجا Kafka، مانیتورینگ با Zabbix، حتماً Kubernetes، بعدش هم Rancher بیارید بالا و خلاصه یه لیست بلندبالا از تکنولوژیها که انگار بدون اینا پروژه اصلاً معنی نداره.
مشکل اینجا بود که ما کلاً از اصل ماجرا دور شدیم. بهجای اینکه روی خود محصول تمرکز کنیم، افتادیم توی داستان بالا آوردن کلاستر، داکر، کوبرنتیز و هزار تا ابزار دیگه.
حالا شرایط چی بود؟
یکی اینکه time to market خیلی پایین بود، نهایتاً یه ماه وقت داشتیم محصول رو بدیم بالا. دوم اینکه بیزینس بودجه محدودی داشت و این همه زیرساخت پیچیده واقعاً هزینهبر بود.
از همون اول هم معلوم بود این پروژه به مشکل میخوره. در نهایت هم همین شد، پروژه فیل شد و اون مدیرفنی هم از تیم کنار گذاشته شد.
بعد از ما یه تیم دیگه اومد و کاری که ما نتونستیم بکنیم رو انجام داد: یه مونولیت ساده ساختن که هسته بیزینس درست کار میکرد، روی یه سرور ویندوزی با IIS. نه خبری از داکر بود، نه کوبرنتیز، نه Vault، نه مانیتورینگهای عجیب.
پروژه اونا هم در نهایت به دلایل بیزینسی موفق نشد، ولی فرقش این بود که اونا حداقل خودشونو درگیر پیچیدگیهای الکی نکرده بودن و تمرکزشون روی اصل کار بود.
جمعبندی: وقتی برای یه پروژه ۵۰ تا یوزر داری میری سمت Kubernetes و کلی ابزار سنگین، داری عملاً کار رو خراب میکنی. هر جا دیدی داری بیشازحد کمالگرایی میکنی، یه KISS به خودت بگو و یه چیز ساده، قابل فهم و قابل نگهداری بساز.
و اینم بگم که تصور آدما از سنیور اینه که میاد یه کد خفن مینویسه که واو ولی نه سنیوری سنیوره که KISS اگ نتونه همین KISS رو بفهمه هیچی بارش نیست !
من یکیو میشناختم که الان سنیور یکی از لاین های بیزنسی مرسدس بنزه این بشر به قدری زیبا کد مینوشت و ساده مینوشت و ساده بیانش میکرد که لذت میبردی انگار داره برات خطاطی میکنه انقد قابل فهم بود کدی که مینوشت و با دلیل برات لایو مینوشت ! اون آدم مرسدس بنز که سهله جاهای دیگ رو سرشون میزاشتن یه نابغه به تمام معنا بود کسی که اوج پیچیدگی بیزینس رو تو چند خط کد شیوا بیانش میکرد !
#lawsofsoftwareengineering
@codehalics | کدهالیک
قرار بود تو یه پروژه خیلی خفن جوین بشم، تیم هم واقعاً قوی بود و همهچیز عالی پیش میرفت تا اینکه یه مدیرفنی به تیم اضافه شد. از روز اول شروع کرد به اینکه این باندد کانتکستها باید جدا شن، اینو میکروسرویس میکنیم، اینجا RabbitMQ میذاریم، اونجا Kafka، مانیتورینگ با Zabbix، حتماً Kubernetes، بعدش هم Rancher بیارید بالا و خلاصه یه لیست بلندبالا از تکنولوژیها که انگار بدون اینا پروژه اصلاً معنی نداره.
مشکل اینجا بود که ما کلاً از اصل ماجرا دور شدیم. بهجای اینکه روی خود محصول تمرکز کنیم، افتادیم توی داستان بالا آوردن کلاستر، داکر، کوبرنتیز و هزار تا ابزار دیگه.
حالا شرایط چی بود؟
یکی اینکه time to market خیلی پایین بود، نهایتاً یه ماه وقت داشتیم محصول رو بدیم بالا. دوم اینکه بیزینس بودجه محدودی داشت و این همه زیرساخت پیچیده واقعاً هزینهبر بود.
از همون اول هم معلوم بود این پروژه به مشکل میخوره. در نهایت هم همین شد، پروژه فیل شد و اون مدیرفنی هم از تیم کنار گذاشته شد.
بعد از ما یه تیم دیگه اومد و کاری که ما نتونستیم بکنیم رو انجام داد: یه مونولیت ساده ساختن که هسته بیزینس درست کار میکرد، روی یه سرور ویندوزی با IIS. نه خبری از داکر بود، نه کوبرنتیز، نه Vault، نه مانیتورینگهای عجیب.
پروژه اونا هم در نهایت به دلایل بیزینسی موفق نشد، ولی فرقش این بود که اونا حداقل خودشونو درگیر پیچیدگیهای الکی نکرده بودن و تمرکزشون روی اصل کار بود.
جمعبندی: وقتی برای یه پروژه ۵۰ تا یوزر داری میری سمت Kubernetes و کلی ابزار سنگین، داری عملاً کار رو خراب میکنی. هر جا دیدی داری بیشازحد کمالگرایی میکنی، یه KISS به خودت بگو و یه چیز ساده، قابل فهم و قابل نگهداری بساز.
و اینم بگم که تصور آدما از سنیور اینه که میاد یه کد خفن مینویسه که واو ولی نه سنیوری سنیوره که KISS اگ نتونه همین KISS رو بفهمه هیچی بارش نیست !
من یکیو میشناختم که الان سنیور یکی از لاین های بیزنسی مرسدس بنزه این بشر به قدری زیبا کد مینوشت و ساده مینوشت و ساده بیانش میکرد که لذت میبردی انگار داره برات خطاطی میکنه انقد قابل فهم بود کدی که مینوشت و با دلیل برات لایو مینوشت ! اون آدم مرسدس بنز که سهله جاهای دیگ رو سرشون میزاشتن یه نابغه به تمام معنا بود کسی که اوج پیچیدگی بیزینس رو تو چند خط کد شیوا بیانش میکرد !
#lawsofsoftwareengineering
@codehalics | کدهالیک
👍6❤4
کدهالیک | codehalic
خب امروز میخوام برم ادامه قوانین مهندسی نرم افزار رو بازگو کنم براتون و امروز راجب یه اصل بسیار پر تکرار قراره صحبت کنیم که قطعا خیلیاتون اسمشو شنیدید ! اصل KISS (Keep It Simple, Stupid) تو مهندسی نرمافزار میگه تا جای ممکن راهحلهات رو ساده نگه دار و الکی…
خب امروز میخوام برم ادامه قوانین مهندسی نرمافزار رو بگم
راجب یه اصل خیلی مهم و جالب قراره صحبت کنیم که احتمالاً هم تجربهش کردید، هم دیدید تو بقیه
اثر Dunning-Kruger که توسط David Dunning و Justin Kruger معرفی شده، نکتش اینه :
هرچی کمتر بدونی، معمولاً اعتمادبهنفست بیشتره!
یعنی وقتی تازه وارد یه حوزه میشی ، چون هنوز عمق ماجرا رو نمیبینی، فکر میکنی همهچیز سادهست و خیلی راحت میتونی از پسش بربیای. ولی هرچی جلوتر میری و بیشتر یاد میگیری، تازه میفهمی چقدر چیز هست که بلد نیستی… و اینجاست که اعتمادبهنفست میاد پایین (همون چیزی که بهش میگن valley of despair).
جالب اینجاست که آدمهای باتجربه دقیقاً برعکس رفتار میکنن. به جای جوابهای قطعی، میگن «بستگی داره»، سناریوهای مختلف رو در نظر میگیرن و کمتر با قطعیت حرف میزنن. چون میدونن دنیا خیلی پیچیدهتر از چیزیه که با یه جواب ساده جمع بشه.
از اون طرف، یه پدیده دیگه هم هست به اسم impostor syndrome که توش آدمهای حرفهای فکر میکنن به اندازه کافی خوب نیستن، چون دقیقاً از پیچیدگیها خبر دارن.
#lawsofsoftwareengineering
@codehalics | کدهالیک
راجب یه اصل خیلی مهم و جالب قراره صحبت کنیم که احتمالاً هم تجربهش کردید، هم دیدید تو بقیه
اثر Dunning-Kruger که توسط David Dunning و Justin Kruger معرفی شده، نکتش اینه :
هرچی کمتر بدونی، معمولاً اعتمادبهنفست بیشتره!
یعنی وقتی تازه وارد یه حوزه میشی ، چون هنوز عمق ماجرا رو نمیبینی، فکر میکنی همهچیز سادهست و خیلی راحت میتونی از پسش بربیای. ولی هرچی جلوتر میری و بیشتر یاد میگیری، تازه میفهمی چقدر چیز هست که بلد نیستی… و اینجاست که اعتمادبهنفست میاد پایین (همون چیزی که بهش میگن valley of despair).
جالب اینجاست که آدمهای باتجربه دقیقاً برعکس رفتار میکنن. به جای جوابهای قطعی، میگن «بستگی داره»، سناریوهای مختلف رو در نظر میگیرن و کمتر با قطعیت حرف میزنن. چون میدونن دنیا خیلی پیچیدهتر از چیزیه که با یه جواب ساده جمع بشه.
از اون طرف، یه پدیده دیگه هم هست به اسم impostor syndrome که توش آدمهای حرفهای فکر میکنن به اندازه کافی خوب نیستن، چون دقیقاً از پیچیدگیها خبر دارن.
#lawsofsoftwareengineering
@codehalics | کدهالیک
👍2👌1
کدهالیک | codehalic
خب امروز میخوام برم ادامه قوانین مهندسی نرمافزار رو بگم راجب یه اصل خیلی مهم و جالب قراره صحبت کنیم که احتمالاً هم تجربهش کردید، هم دیدید تو بقیه اثر Dunning-Kruger که توسط David Dunning و Justin Kruger معرفی شده، نکتش اینه : هرچی کمتر بدونی، معمولاً…
اگر فن قوانین مهندسی نرم افزار هستید تا الان راجب این موضوعات باهم دیگه صحبت کردیم :
1- قانون هایروم
2-قانون زاوینسکی
3- قانون KISS
4- اثر Dunning-Kruger
ضمنا با هشتک #lawsofsoftwareengineering میتونین موارد مرتبط باهاش رو بخونین مثل نظرات و تجربیات شخصی خودم نسبت به هر کدوم
سعی میکنم هر روز یا هر 2 روز یک بار یک قانون جدید رو باهم دیگ بررسی کنیم بنظرم فهمشون خیلی خیلی بهمون دید کلی نسبت به محصول و برنامه نویسی و ... میده !
تمامی این موارد برگرفته از کتابی با همین اسم یعنی lawsofsoftwareengineering عه که سعی میکنم با نثری شیوا ( مثلا من خیلی خفنم ) براتون بیانش کنم
@codehalics | کدهالیک
1- قانون هایروم
2-قانون زاوینسکی
3- قانون KISS
4- اثر Dunning-Kruger
ضمنا با هشتک #lawsofsoftwareengineering میتونین موارد مرتبط باهاش رو بخونین مثل نظرات و تجربیات شخصی خودم نسبت به هر کدوم
سعی میکنم هر روز یا هر 2 روز یک بار یک قانون جدید رو باهم دیگ بررسی کنیم بنظرم فهمشون خیلی خیلی بهمون دید کلی نسبت به محصول و برنامه نویسی و ... میده !
تمامی این موارد برگرفته از کتابی با همین اسم یعنی lawsofsoftwareengineering عه که سعی میکنم با نثری شیوا ( مثلا من خیلی خفنم ) براتون بیانش کنم
@codehalics | کدهالیک
❤9👏5
امروز میخوام ادامه قوانین مهندسی نرمافزار رو ببرم سراغ یکی از خطرناکترین باگهای ذهنی که حتی از باگهای کد هم بدتره؛ اثر Confirmation Bias یا سوگیری تأییدی. مغز ما دنبال حقیقت نیست، دنبال تأیید چیزیه که از قبل بهش باور داریم. وقتی یه فرض تو ذهنمون شکل میگیره (مثلاً مشکل از یه سرویسه)، فقط چیزهایی رو میبینیم که همونو تأیید کنه و بقیه نشونهها رو نادیده میگیریم یا کماهمیت میکنیم. همین باعث میشه تو دیباگ، طراحی سیستم یا تصمیمهای معماری، مسیر اشتباه رو با اعتمادبهنفس بالا ادامه بدیم.
جالب اینجاست که هرچی مطمئنتر باشی “مشکل رو فهمیدی”، بیشتر تو این خطایی. چون ذهن دیگه دنبال رد فرضت نیست، فقط دنبال اثباتشه. برای همین آدمهای باتجربه برعکس عمل میکنن؛ به جای اینکه بپرسن «چرا درسته؟» میپرسن «چرا ممکنه اشتباه باشه؟» و دنبال دادهای میگردن که فرضشون رو نقض کنه، نه تأیید. چون تو مهندسی نرمافزار، واقعیت به باور ما وفادار نیست، به چیزی وفاداره که واقعاً تو سیستم اتفاق میافته.
#lawsofsoftwareengineering
@codehalics | کدهالیک
جالب اینجاست که هرچی مطمئنتر باشی “مشکل رو فهمیدی”، بیشتر تو این خطایی. چون ذهن دیگه دنبال رد فرضت نیست، فقط دنبال اثباتشه. برای همین آدمهای باتجربه برعکس عمل میکنن؛ به جای اینکه بپرسن «چرا درسته؟» میپرسن «چرا ممکنه اشتباه باشه؟» و دنبال دادهای میگردن که فرضشون رو نقض کنه، نه تأیید. چون تو مهندسی نرمافزار، واقعیت به باور ما وفادار نیست، به چیزی وفاداره که واقعاً تو سیستم اتفاق میافته.
#lawsofsoftwareengineering
@codehalics | کدهالیک
👍8❤1🔥1
خب امروزم قراره بریم به ادامه ی بحث جذاب قوانین مهندسی نرم افزار و قانون هافستدر (Hofstadter)
قانون هافستدر میگه کارها همیشه بیشتر از چیزی که فکر میکنیم طول میکشن، حتی وقتی از قبل اینو در نظر میگیریم که احتمالاً داریم خوشبینانه تخمین میزنیم. دلیلش هم اینه که تو پروژههای واقعی، مخصوصاً نرمافزاری، چیزهای پیشبینینشده زیاد پیش میاد؛ مثل باگهای عجیب، وابستگی به کار بقیه، یا زمان بیشتر برای تست و ریویو.
این موضوع مستقیم به استیمیت دادن توی Jira ربط داره، چون معمولاً تسکها رو کمتر از واقعیت برآورد میکنیم و حتی وقتی سعی میکنیم محافظهکار باشیم باز هم خطا داریم. به همین خاطر تیمها معمولاً از دادههای اسپرینتهای قبلی (velocity) و یه مقدار بافر استفاده میکنن تا استیمیتها واقعیتر بشه و برنامهریزی قابل اتکاتری داشته باشن.
#lawsofsoftwareengineering
@codehalics | کدهالیک
second t is silent
تلفظ دقیق فارسی : هافس (ساکن) تَ دِ ر
قانون هافستدر میگه کارها همیشه بیشتر از چیزی که فکر میکنیم طول میکشن، حتی وقتی از قبل اینو در نظر میگیریم که احتمالاً داریم خوشبینانه تخمین میزنیم. دلیلش هم اینه که تو پروژههای واقعی، مخصوصاً نرمافزاری، چیزهای پیشبینینشده زیاد پیش میاد؛ مثل باگهای عجیب، وابستگی به کار بقیه، یا زمان بیشتر برای تست و ریویو.
این موضوع مستقیم به استیمیت دادن توی Jira ربط داره، چون معمولاً تسکها رو کمتر از واقعیت برآورد میکنیم و حتی وقتی سعی میکنیم محافظهکار باشیم باز هم خطا داریم. به همین خاطر تیمها معمولاً از دادههای اسپرینتهای قبلی (velocity) و یه مقدار بافر استفاده میکنن تا استیمیتها واقعیتر بشه و برنامهریزی قابل اتکاتری داشته باشن.
#lawsofsoftwareengineering
@codehalics | کدهالیک
👍3🤔1
کدهالیک | codehalic
اگر فن قوانین مهندسی نرم افزار هستید تا الان راجب این موضوعات باهم دیگه صحبت کردیم : 1- قانون هایروم 2-قانون زاوینسکی 3- قانون KISS 4- اثر Dunning-Kruger ضمنا با هشتک #lawsofsoftwareengineering میتونین موارد مرتبط باهاش رو بخونین مثل نظرات و تجربیات…
خب امروز که راجب ریداکس و اینکه اشتباهه ازش استفاده کنیم ولی قبلا خیلی ازش استفاده میشده صحبت کردیم پس قراره که ادامه قوانین مهندسی نرم افزار رو با همین موضوع ببریم جلو !
امروز یه مفهوم جالب توی دنیای نرمافزار مطرح شده به اسم «اثر لیندی». خلاصهاش اینه که هرچی یه تکنولوژی یا ابزار بیشتر عمر کرده باشه، احتمال اینکه توی آینده هم بمونه بیشتره. یعنی زمان خودش یه جور فیلتره؛ چیزای ضعیف و بیفایده کمکم حذف میشن و اونایی که میمونن معمولاً واقعاً به درد بخورن.
حالا نتیجهای که ازش میگیرن اینه که به جای اینکه هی دنبال ابزارهای خیلی جدید و ترندهای هر ماه باشیم، بهتره یه مقدار بیشتر بریم سمت چیزای امتحانپسداده. مثلاً مفاهیم پایه مثل الگوریتمها، SQL یا زبانهای قدیمیتر و جاافتاده. چون احتمال اینکه اینا فردا هم هنوز به کارت بیان، خیلی بیشتر از یه فریمورکیه که همین هفته معرفی شده.
#lawsofsoftwareengineering
@codehalics | کدهالیک
امروز یه مفهوم جالب توی دنیای نرمافزار مطرح شده به اسم «اثر لیندی». خلاصهاش اینه که هرچی یه تکنولوژی یا ابزار بیشتر عمر کرده باشه، احتمال اینکه توی آینده هم بمونه بیشتره. یعنی زمان خودش یه جور فیلتره؛ چیزای ضعیف و بیفایده کمکم حذف میشن و اونایی که میمونن معمولاً واقعاً به درد بخورن.
حالا نتیجهای که ازش میگیرن اینه که به جای اینکه هی دنبال ابزارهای خیلی جدید و ترندهای هر ماه باشیم، بهتره یه مقدار بیشتر بریم سمت چیزای امتحانپسداده. مثلاً مفاهیم پایه مثل الگوریتمها، SQL یا زبانهای قدیمیتر و جاافتاده. چون احتمال اینکه اینا فردا هم هنوز به کارت بیان، خیلی بیشتر از یه فریمورکیه که همین هفته معرفی شده.
#lawsofsoftwareengineering
@codehalics | کدهالیک
❤2👍1
از یک جلسه ۴ ساعتهی فرسایشی برای کانترکت api با یه شرکت خیلی خفن برگشتم ( من جلسه دوست ندارم و حوصلم سر میره وقتی طولانی شه )، ولی امروز میخوام ادامه قوانین مهندسی نرم افزار رو بهتون بگم و درباره قانون پرایس حرف میزنیم.
قانون پرایس میگه در هر تیم، ریشه دوم افراد (√N) حدود ۵۰٪ خروجی رو تولید میکنن. یعنی همیشه یک گروه کوچک بیشترین اثر رو روی نتیجه داره و بقیه نقشهای مکمل دارن.
اما این فقط یک الگوی آماریه، نه دستور مدیریتی. خروجی واقعی تیم فقط کد نیست؛ زیرساخت، امنیت، هماهنگی و پشتیبانی هم بخش حیاتی ارزش هستن و کمتر دیده میشن ولی ضروریان.
اشتباه وقتی شروع میشه که این قانون تبدیل به ابزار سادهسازی برای تصمیمهایی مثل تعدیل نیرو بشه. چون تیمها شبکهای از وابستگیان، نه جمعی از افراد مستقل.
در نهایت، پرایس فقط میگه اثرگذاری نابرابره، نه اینکه کسی بیارزشه. تصمیم درست ترکیبی از داده، شناخت نقشها و فهم سیستمه، نه یک فرمول ساده.
#lawsofsoftwareengineering
@codehalics | کدهالیک
قانون پرایس میگه در هر تیم، ریشه دوم افراد (√N) حدود ۵۰٪ خروجی رو تولید میکنن. یعنی همیشه یک گروه کوچک بیشترین اثر رو روی نتیجه داره و بقیه نقشهای مکمل دارن.
اما این فقط یک الگوی آماریه، نه دستور مدیریتی. خروجی واقعی تیم فقط کد نیست؛ زیرساخت، امنیت، هماهنگی و پشتیبانی هم بخش حیاتی ارزش هستن و کمتر دیده میشن ولی ضروریان.
اشتباه وقتی شروع میشه که این قانون تبدیل به ابزار سادهسازی برای تصمیمهایی مثل تعدیل نیرو بشه. چون تیمها شبکهای از وابستگیان، نه جمعی از افراد مستقل.
در نهایت، پرایس فقط میگه اثرگذاری نابرابره، نه اینکه کسی بیارزشه. تصمیم درست ترکیبی از داده، شناخت نقشها و فهم سیستمه، نه یک فرمول ساده.
#lawsofsoftwareengineering
@codehalics | کدهالیک
❤2👍1
خب خیلی عقب موندیم از قوانین مهندسی نرم افزار امروز میخوام راجب نظریه پنجره شکسته باهاتون صحبت کنم
نظریه «پنجره شکسته» در مهندسی نرمافزار میگه اگر مشکلات کوچک مثل باگهای جزئی، کدهای بد یا طراحیهای ناقص رو نادیده بگیریم و اصلاحشون نکنیم، این پیام رو به تیم منتقل میکنیم که کیفیت مهم نیست. در نتیجه بهمرور افراد هم حساسیتشون رو نسبت به کیفیت از دست میدن و مشکلات بیشتری وارد سیستم میشه.
این موضوع باعث میشه یک چرخهی نزولی شکل بگیره؛ یعنی هرچه بینظمی بیشتر بشه، بینظمی جدید هم راحتتر پذیرفته میشه و کل سیستم به سمت پیچیدگی و آشفتگی میره. در مقابل، اگر تیمها روی اصلاح سریع ایرادهای کوچک حساس باشن، یک فرهنگ کیفیت شکل میگیره که جلوی رشد بدهی فنی و خراب شدن تدریجی سیستم رو میگیره.
#lawsofsoftwareengineering
@codehalics | کدهالیک
نظریه «پنجره شکسته» در مهندسی نرمافزار میگه اگر مشکلات کوچک مثل باگهای جزئی، کدهای بد یا طراحیهای ناقص رو نادیده بگیریم و اصلاحشون نکنیم، این پیام رو به تیم منتقل میکنیم که کیفیت مهم نیست. در نتیجه بهمرور افراد هم حساسیتشون رو نسبت به کیفیت از دست میدن و مشکلات بیشتری وارد سیستم میشه.
این موضوع باعث میشه یک چرخهی نزولی شکل بگیره؛ یعنی هرچه بینظمی بیشتر بشه، بینظمی جدید هم راحتتر پذیرفته میشه و کل سیستم به سمت پیچیدگی و آشفتگی میره. در مقابل، اگر تیمها روی اصلاح سریع ایرادهای کوچک حساس باشن، یک فرهنگ کیفیت شکل میگیره که جلوی رشد بدهی فنی و خراب شدن تدریجی سیستم رو میگیره.
#lawsofsoftwareengineering
@codehalics | کدهالیک
❤3
امروز میریم ادامه قوانین مهندسی نرم افزار رو بررسی کنیم و یک کانسپت بسیار جذاب در سیستم های توزیع شده رو بررسی میکنیم
قضیهی CAP (Consistency – Availability – Partition Tolerance)
میگه تو سیستمهای توزیع شده نمیتونی هر سه تا ویژگی رو همزمان بهطور کامل داشته باشی: اینکه همه نودها همیشه کانسیستنت باشه دیتای روشون ، سیستم همیشه در دسترس باشه و هر درخواست جواب بگیره، و حتی وقتی ارتباط بین سرورها قطع میشه (partition) سیستم همچنان کار کنه.
چون قطعی شبکه توی سیستمهای واقعی اجتنابناپذیره، عملاً باید موقع مشکل بین Consistency و Availability یکی رو انتخاب کنی. مثلاً MongoDB بیشتر سمت Consistency + Partition Tolerance میره؛ یعنی اگر بین سرورها مشکل پیش بیاد، ترجیح میده بعضی درخواستها رو جواب نده تا مطمئن بشه دادهها دقیق و یکسان میمونن. در مقابل، Cassandra بیشتر سمت Availability + Partition Tolerance میره؛ یعنی همیشه به درخواستها جواب میده حتی اگر موقتاً بعضی نودها دادههای متفاوت یا قدیمی داشته باشن، و بعداً اونها رو هماهنگ میکنه.
#lawsofsoftwareengineering
@codehalics | کدهالیک
قضیهی CAP (Consistency – Availability – Partition Tolerance)
میگه تو سیستمهای توزیع شده نمیتونی هر سه تا ویژگی رو همزمان بهطور کامل داشته باشی: اینکه همه نودها همیشه کانسیستنت باشه دیتای روشون ، سیستم همیشه در دسترس باشه و هر درخواست جواب بگیره، و حتی وقتی ارتباط بین سرورها قطع میشه (partition) سیستم همچنان کار کنه.
چون قطعی شبکه توی سیستمهای واقعی اجتنابناپذیره، عملاً باید موقع مشکل بین Consistency و Availability یکی رو انتخاب کنی. مثلاً MongoDB بیشتر سمت Consistency + Partition Tolerance میره؛ یعنی اگر بین سرورها مشکل پیش بیاد، ترجیح میده بعضی درخواستها رو جواب نده تا مطمئن بشه دادهها دقیق و یکسان میمونن. در مقابل، Cassandra بیشتر سمت Availability + Partition Tolerance میره؛ یعنی همیشه به درخواستها جواب میده حتی اگر موقتاً بعضی نودها دادههای متفاوت یا قدیمی داشته باشن، و بعداً اونها رو هماهنگ میکنه.
#lawsofsoftwareengineering
@codehalics | کدهالیک
👍5
خب بریم قوانین مهندسی نرم افزار امروز و یک قانون از آنکل باب معروف
قانون Boy Scout Rule که توسط Robert C. Martin معروف شد، یه اصل ساده داره: *هر جا به کد دست میزنی، یه ذره بهترش کن قبل از اینکه ولش کنی*. لازم نیست پروژه رو از اول بنویسی یا همهچیز رو کامل کنی؛ فقط همون بخشی که داری روش کار میکنی رو تمیزتر کن. مثلاً اسم متغیرها رو واضحتر کن، کد تکراری رو جمع کن، یا یه فانکشن خیلی طولانی رو کوچیکتر کن.
ایده اصلی اینه که این بهبودهای کوچیک، روی هم جمع میشن و جلوی خراب شدن کدبیس رو میگیرن. وقتی همه تیم این کار رو بکنن، یه حس مسئولیت مشترک نسبت به کیفیت کد شکل میگیره و بدهی فنی کمتر میشه. خلاصهاش اینه: لازم نیست قهرمان باشی، فقط هر بار یه قدم کوچیک بردار تا پروژه به مرور تمیزتر و قابل نگهداریتر بشه.
#lawsofsoftwareengineering
@codehalics | کدهالیک
قانون Boy Scout Rule که توسط Robert C. Martin معروف شد، یه اصل ساده داره: *هر جا به کد دست میزنی، یه ذره بهترش کن قبل از اینکه ولش کنی*. لازم نیست پروژه رو از اول بنویسی یا همهچیز رو کامل کنی؛ فقط همون بخشی که داری روش کار میکنی رو تمیزتر کن. مثلاً اسم متغیرها رو واضحتر کن، کد تکراری رو جمع کن، یا یه فانکشن خیلی طولانی رو کوچیکتر کن.
ایده اصلی اینه که این بهبودهای کوچیک، روی هم جمع میشن و جلوی خراب شدن کدبیس رو میگیرن. وقتی همه تیم این کار رو بکنن، یه حس مسئولیت مشترک نسبت به کیفیت کد شکل میگیره و بدهی فنی کمتر میشه. خلاصهاش اینه: لازم نیست قهرمان باشی، فقط هر بار یه قدم کوچیک بردار تا پروژه به مرور تمیزتر و قابل نگهداریتر بشه.
#lawsofsoftwareengineering
@codehalics | کدهالیک
❤6
ادامه قوانین مهندسی نرم افزار !
یه مفهومی توی تیمهای نرمافزاری هست به اسم 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