در دنیای نرم افزار وقتی نقاط درد تسکین پیدا میکنه عطش توسعه اجازه نمیده به ریشه خرابی‌ها رسیدگی کنیم
راستش رو بخوای، #توسعه_نرم‌افزار یه #فرآیند پیچیده و چندلایه‌ست. وقتی میگیم تسکین نقاط درد، بیشتر منظورمون اینه که برای مشکلات فوری، راه‌حل‌های موقت پیدا کنیم. ولی این کار باعث میشه تیم‌ها به جای رفتن سراغ ریشه خرابی‌ها، فقط علائم ظاهری رو درمون کنن و وقتی هم درد از بین میره دیگه اولویت نداره و کسی برنمیگرده به حساب‌شون برسه!
میدونی چی میشه آخرش؟ کم کم مشکلات بزرگ‌تر و پیچیده‌تر سر و کله‌شون پیدا میکنه! 😅
کن تامپسون (Ken Thompson) که یکی از خالقان سیستم‌عامل #یونیکس هستش، یه حرف جالبی زده:
“زمانی که یک مشکل را حل میکنید، باید به راه‌حل‌های ساده و زیبا فکر کنید. پیچیدگی دشمن است.”
به نظرم راست میگه، پیچیدگی واقعاً دشمنه! ولی اکثر راه‌حل‌های فوری، خالق پیچیدگی‌ها هستن! با تزریق #مسکن ها، در دراز مدت پیچیدگی ایجاد میشه! 🙈
دونالد کنوت (Donald Knuth) هم که یکی از پیشگامان علوم کامپیوتره، میگه:
“بهینه‌سازی زودهنگام ریشه همه شرارت‌هاست.”
میدونی، خیلی از مُسَکن‌هایی که استفاده میکنیم هم از همین مدل شرارت‌هاست! مثلاً یه جایی کنده، اولین کاری که میکنیم اینه که یه کَش میذاریم روش، حالا چرا اینجا کنده مهم نیست! 😂 حالا اگه این نقطه درد با یه مشکل دیگه تلاقی کنه، مشکلات ضریب میخوره و گاهی دولوپر هم گیج میشه که چطوری حلشون کنه و اگه این چرخه‌ی "درد، مسکن، درد، مسکن و…" تکرار بشه، کم کم داریم برای خودمون یه #سیاهچاله میسازیم! 🕳️
فکر نکن این مشکلات فقط مال ماست، #توییتر هم یه زمانی همچین دردسری داشت! اسم مشکلشون رو گذاشته بودن “#FailWhale”. از سال ۲۰۰۷ تا ۲۰۰۹ حسابی درگیرش بودن و تا سال ۲۰۱۳ هم ادامه داشت! 🐳
الکس مک‌کاو (Alex Maccaw) که تو شرکت‌های بزرگ فناوری مثل #Stripe کار کرده، تو یه مقاله‌ای به نام “The Fail Whale: Paying Twitter’s Technical Debt” در سال 2013، مشکلات فنی توییتر و نقش بدهی‌های فنی رو بررسی کرده و گفته:
“مشکلات مقیاس‌پذیری توییتر که نماد بارز آن «نهنگ شکست» (Fail Whale) بود، عمدتاً ناشی از بدهی‌های فنی بود. در روزهای اولیه، تیم مهندسی توییتر تصمیماتی گرفت که به آنها امکان می‌داد ویژگی‌های جدید را به سرعت عرضه کنند، اما این کار به قیمت عدم سرمایه‌گذاری در زیرساخت‌های قوی‌تر و مقیاس‌پذیرتر تمام شد. با گذشت زمان، این موضوع منجر به انباشت بدهی‌های فنی شد که رفته رفته کار توییتر برای مدیریت رشد کاربران و حجم داده‌ها را دشوارتر می‌کرد.”
لینک مقاله هم اینه، البته مستقیم از سایت خود الکس نمیشه بازش کرد، ولی تو آرشیو اینترنت هست:
https://lnkd.in/evTF_jHZ
و در آخر، یادمون نره که اصل نهم #اجایل (از ۱۲ اصل) میگه: توجه مداوم به برتری #فنی و طراحی خوب باعث افزایش #چابکی میشه. 💪
پس اجایل شدن فقط با شعار ممکن نیست!
تو اصل چهارم در طراحی #معماری پردازنده‌ها در این موضوع هم صدق میکنه. یک طراحی خوب نیازمند مصالحه‌های خوب است. مصالحه یا compromise همیشه وجود داره. در هر تصمیمی ما trade off داریم. از یک طرف، پرفورمنس سیستم در حال حاضر و آینده نزدیک و دور و از طرف دیگه بحث هزینه‌ها و سرعت #توسعه و دسترسی به نتایج مطرح هستن. به هر حال هر سیستمی برای همیشه کار نخواهد کرد و عمری خواهد داشت مرتبط و متناسب با دامنه اون سیستم. ایجاد توازن مهم‌ترین چیز هست و مشکلی که تلاش کردم در این نوشته شرح موازنه یا مصاحله غلطه، موازنه‌ای که تاثیر مُسَکن‌های زیاد و ندیدن بدهی‌های فنی رو در نظر نمیگیره
تا جایی که میشه (و البته اصولی داره که یکم در موردش در مقاله "موازنه پولساز" نوشتم) نباید تا حد ممکن زیر بار " زود بزن بعدا ریفکتور میکنیم " نباید رفت، چون معمولا سلوشن هایی که بهش برچسب " موقت " میزنن توی اون پروژه ریشه میکنه و بعدا هزینه ی بیشتری می‌تراشه
این نکته رو هم بد نیست بگم که شما با هر زبان #برنامه_نویسی مستقل یا #فریم_وورک که نرم افزار تولید کنید بالاخره ذاتا وابستگی و #پیچیدگی دو اصل کنار هم هستند که امکان تمیز دادن این دو تا به این سادگی‌ها نیست.
مثلا شما وقتی از زبان کامپایلری استفاده میکنید قطعا تلاش میکنید که از آخرین نسخه استفاده کنید همین موضوع برای استانداردهای زبان هم صادق هست، خوب شما هر چقدر هم که زبان و استانداردها رو به خوبی بشناسید و بسیار هم که حرفه ای باشید بازهم نمیتونید از همه امکانات زبان طوری استفاده کنید که ۵ سال بعد منجر به بدهی فنی نباشه، چرا چون اصولا تغییرات تکنولوژی در سخت افزارها خیلی سریعتر از ابزارهای تولید نرم افزار حرکت میکنن بنابراین سرویس دهنده ای که در حال حاضر خیلی خوب بنطر میرسه تا ۵ سال دیگه قطعا دیگه خوب نخواهد بود اما خیلی مهمه که بدونیم بدهی فنی ایی که من ازش صحبت کردم و در مورد مسکن‌هاش گفتم، چیزهایی هستن که عمدتا ربطی به گذشت زمان نداره، مواردی مثل: طراحی بد، اجرای بد، پیچیدگی اضافه، آینده نگاری اشتباه، دیتا مدل ضعیف و ... مد نظر منه
چطوره تجربه خودت رو از مواجهه با بدهی‌های فنی و راه‌حل‌هایی که به کار بردی با بقیه به اشتراک بذاری؟ مطمئنم بحث جذابی میشه و همه می‌تونیم از هم یاد بگیریم. منتظر شنیدن نظرات و تجربیات ارزشمندت هستم! 🙌
