بخش دوم.
در قسمت قبلی تا حدودی در مورد فاجعه ای که در 10 روز اول ورود به شرکت جدید با آن روبرو شدم صحبت کردم. حالا مشکل اینجا بود که این شرکت مثل شرکتهای ایرانی دست و پای من را نبسته بود و نمیخواست من دنبال آنها راه بیفتم. کاملن برعکس بود. قشنگ گفتن خوب برو بشین برای همه پرسنل شرکت برنامه تا اقلن 3 ماه دیگر را به صورت ماهانه - هفتگی و روزانه برنامه بریز، ما هم مثل بز دنبالت راه می افتیم ، فقط هدف از هر پلن و نتیجش رو هم مشخص کن !!!.
گوووووو خوردم. شر شد. آمدیم اظهار فضل کنیم، گیر کردیم. حالا کی میتونه سیستمی که هیچیش مشخص نیست را براش برنامه ریزی هم بکنه !!!.
شر بزرگ اینجا بود که هر چی میگفتی ، 200 تا سوال در مورد ابعاد تصمیمت می پرسیدن و باید می نشستی برای یک Native Speaker مشتاق ریز به ریز همه چیز را شرح میدادی.
تازه یک مشکل دیگه هم بود. وقتی یکی چیزی میگفتی ، میگفتن خوبه ، ولی اولویت ما نیست !. عملن حاصل مثلن نصف رورز برنامه ریزی به سطل آشغال منتقل میشد !.
دیدم اینطوری نمیشه. پاچه ها رو زدم بالا و گفتم یک هفته کسی سلام و علیک هم با من نکنه. رفتم افتادم به جون سورس کد و از طرف دیگر هم مشاهده Graph های Azure و Execution پلنها. صحرای کربلایی بود. مثال میزنم :
Select * from Accounts
مثلن این داشت اجرا میشد و بعدش توی سی شارپ فقط Count نتیجه رو میگرفت، وارد یک IF میشد بعدش توی بدنه IF باز با EF یک Select کاملن و 100 درصد مشابه زده بود تا دیتا رو داشته باشه و ازش استفاده کنه!. تعدد Query ها رسمن با خار و مادر دیتابیس عروسی کرده بود و دقیقن می تونستی ببینی یک Query را میشود یکبار زد و 200 جا در یک محاسبه استفاده کرد، کاری که در سورس کد 200 بار انجام شده بود. حالا من نوشتم برای مثال Select * from ولی اینطوری هم نبود. قشنگ یک Query بود اندازه یک فیل با 15 تا Join و نتیجش هم میشد 1200 تا رکورد!.
خوب این گرفت. گوش طرف را گرفتم و همه اینها رو نشونش دادم. کف کرد. تازه داشت براش مجسم میشد چرا این همه داره به Azure پول میده و مشتریها هم دائم فحش میدهند !.
این را نوشتیم در برنامه کاری و رفتم سراغ اصل جنایتی که توی سیستم انجام شده بود. در قسمت قبلی گفتم برنامه نویسهای عزیز قبلی برای هر حرکتی یک سشن ساخته بودند و این سبب شده بود VM های Azure رم کم بیارن و با افزایش کلاینتها حتی گاهی VM ها Restart میشدن و این دیگه خیلی مسخره بود. هرچی داد و فریاد کردم بابا بزار یک NO-SQL بتپونیم توش تا این سشنها رو بکینم توش، گفت نه و بلد نیستم و سخته و .. منم گفتم جهنم ، من اقلن همه سشنها رو میبرم توی SQL . خوب بدم نشد. رم VM ها ول کرد، ولی مشکل این بود که به دلیل مراجعه زیاد سیستم به سشنها و تغییر مداوم، فشار افتاد روی دیتابیس و SQL Azure دائم پیام میداد که دهنم صاف شد و باید پلن را آپگرید کنید و بیشتر پول بدید ولی اقلن سیستم دیگه Stable شده بود.
بعد از 2 ماه کم کم نرم شدن و مجبورشون کردم به Redis فکر کنند. خوب حالا مشکل اینجا بود یک نفر در کل این خراب شده نبود ما بهش سرور بدهیم و اون کانفیگش کنه برای Redis و ... خوب چه باید کرد ؟.
دانیال گردی وارد میشود. دانیال گردی یکی از مغزهای لینوکس و Devops ایران است (بود !. رفت هلند). 2 تا سرور گرفتیم تو Digital Ocean و کلی التماسش رو کردیم تا برامون Redis تا تنظیماتی که می خواستم را بالا آورد و خودم هم یک Repository نوشتم و DI کردم توی سرویسی که ساخته بودیم برای کار با SQL Session ها. حالا توی WebConfig میشد تایین کرد سیستم با SQL Session کار کنه یا Redis . اینطوری اگر ییهو Redis به چخ بره، میشه Switch کرد به همون SQL قبلی.
سرعت سیستم با Redis اقلن 5 برابر شد .مشتریها برای اولین باز زنگ می زدند و ابراز خوشحالی و تعجب میکردند. ضمنن میشد راحت فهمید هر مشتری دقیق چند سشن باز داره و اینطوری کمی میشد بعضی تحرکات را مدیریت کرد.
در طول 10 روزی که درگیر Redis بودیم، اون برادر هندی را گرفتم و گفتم اگر توی سیستم حتی یک Grid ببینم که Paging صرفا به Telerik سپرده شده و 1000 تا رکورد کشیدی و دادی به Telerik خودش Paging بکنه ، خودم میکشمت !.
نشست خودش را جر داد و همش را اول لیست کرد و بر اساس Task های روزانه عوض میکرد و شب به شب تحویل تسترها میداد. کم کم فشار Fetch کردن هزار هزاری یا بالاتر از روی دیتابیس ها داشت برداشته میشد.
هنوز ولی اتفاق خاصی توی سیستم نیفتاده بود. برنامه من اینجا کمی چرخید و رفتم به سمت Stable کردن سیستم تا بشه نشست فکر کرد و سیستم را از صفر باز نویسی کرد . چیزی که رئیس دوست نداشت و دلش می خواست همین را به شکلی دستکاری کنیم که اقلن 10 سال دیگه کیفش را ببرد .
در قسمت بعد خواهم گفت چرا من مخالف دستکاری سیستم در حدی که بشه 10 سالی باز نگهش داشت بودم و پس از آن به ادامه داستان Stable کردن سیستم خواهم پرداخت.