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