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

این قانون دقیقاً همینه: توی بازطراحی یا همون 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 | کدهالیک