شرحی بر آنچه در شرکت به تنهایی انجام دادم و آنچه تیم فعلی در حال انجام آن است....

بخش سوم.

اگر دو قسمت قبلی را خوانده باشید ، عمق فاجعه ای که با آن روبرو بودیم و تحرکات اولیه برای حفظ سیستم را شرح دادم و اگر بخاطر بیاورید گفتم که در اینجا نظر من با نظر مدیر و صاحب شرکت فرق کرد چون او دوست داشت به شکلی سیستم فعلی را حتی اگر شده برای همیشه حفظ کند و من به شدت مخالفت کردم . فکر کنم این قسمت بیشتر صرف شرح دلایل مخالفت من با این ایده خواهد شد.

1- سیستم کاملن به صورت متلاشی نوشته شده بود و تعداد جداول سیستم عملن 5 برابر میزان لازمه بود.

2- نرم افزار با ASP.NET WebForm نوشته شده بود و یکی از نیازهای شدید شرکت داشتن Api بود تا بتواند حتی بصورت جدا Api بفروشد.

3- درست است که Session ها را با کمک Redis و یک سری کلکها توانستیم کمی جمع و جور کنیم ، ولی اصلن وجود این Session ها سیستم را به شدت ریسکی کرده بود و در هر Request کافی بود یکی از این مقادیر به هر دلیلی درست گرفته نشود تا سیستم منهدم شود.

4- از لحاظ UI هم سیستم کامل نابود بود. دهها Master Page ، تعدد استفاده غیر عقلانی از Update Panel و ازدیاد PostBack ها پرفورمنس سیستم را به شدت پایین آورده بود و ضمنن اضافه کردن مثلن یک کنترل به UI یک مصیبت بود.

5- مثلن برای کنترل دسترسیهای کاربر در سطح منوها از Tooltip های کنترلها استفاده شده بود که هنوز هم بابت چنین حرکت انتحاری به بالا تا پایین شرکت می خندیم هر روز.

6- هر برنامه نویس برای خودش یک سری متد ساخته بوده و با آنها کار میکرده. ممکن است یک عملیات GET در این سیستم توسط 20 متد جدا انجام شود و در هر Module یا UI یکی از آنها صدا زده شود!.

7- هسته ارتباط با دیتابیس EF 4 DataBase First است که توسط EDMX معروف که خود ماکروسافت هم بیخیالش شد هندل میشود و دستکاری و Refactor کردن آن ماجرایی است.

8- به دلیل پیاده سازی غلط SaaS ، هر مشتری 2 دیتابیس دارد و Connection String دیتابیس دوم که Transaction DataBase است بر اساس URL سیستم درون یک Session ذخیره میشود که این حتی بر خلاف اصول امنیت نرم افزار است.

9- به دلیل پیاده سازی غلط Design Pattern ها و عدم رعایت یک روال مشخص ، هر بخش از سیستم مبتنی بر یک استاندارد نوشته شده و به هیچ شکلی نمی شد فهمید آخر دقیقن درون سیستم چه متدولوژی پیاده شده است.

10- سیستم گرفتار یک عمق بی منطق است . مثلن وقتی شما دکمه Save را میزنید، بالای 20 متد به صورت تو در تو همدیگر را صدا میزنند و خود صاحب سیستم هم معترف است که نمیداند چرا و این Debug کردن را بسیار مشکل میکند.

11- در بسیاری از قسمتها از Transaction Scope جهت برقراری Transaction در سیستم استفاده شده و عملن بدور تحرکات دوست عزیزمان جناب EF 4 که پر اشکال و دردسر ساز بود یک غلاف برای پیاده سازی Transaction کشیده شده که در بیشتر موارد سبب Deadlock میشد و فریاد مشتری در می آمد.

بر اساس این موارد، از ابتدا اعلام کردم پس از Stable شدن سیستم و قطع تلفنها و فریادهای مشتریان، سیستم را رها میکنیم و به سراغ باز نویسی آن خواهیم رفت.

شرکت ما بر خلاف خیلی از شرکتهای دیگر مشکل نداشتن مشتری ندارد و مشتری پشت درب ایستاده است . حتی با اضافه کردن کوچکترین فیچر در سیستم، مشتری سریعن پول پرداخت میکند یا مشتری جدید پیدا میشود لذا تشویقشان کردم تا نترسند و آرام آرام به سیستم جدید فکر کنند.

در بخشهای بعدی به سراغ شرح ادامه روند Stable سازی سیستم خواهیم رفت.