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

بخش اول .

دوستی در یکی از کامنتهای لینکداین فرموده بودن شرکت داره به تو نون میرسونه و تو باید خیلی خوشحال باشی که ماهانه بهت حقوق میدهند.

اگر حالش را دارید ، این داستان راجع به تحرکات من و ما در این شرکت است که البته طولانی است.

در حدود سال 2014 من با شرکتی که الان براش کار میکنم آشنا شدم. این شرکت توسط یک مرد نیوزلندی که همسری چینی دارد تاسیس شده و در زمان تولید محصول تقریبا هیچی از نرم افزار تحت وب نمی دانسته. زمان تولید محصول حدود سال 2011 تا 2013 بوده و توسط یک تیم 60 نفره هندی در خود هند تولید شده است.

این سیستم یک SaaS است روی بستر آژور Host شده و هر مشتری دیتابیس خودش را دارد. ضمنن بعضی از مشتریها همین رو روی سرورهای خودشان دارند.

محصول این شرکت در جهت انجام محاسبات پیچیده مالیاتی تولید شده و کلیه قوانین درون فرمولها یا حتی تعداد کنترلهای هر فرم می تواند بر اساس ابلاغیه اداره مالیات سال به سال یا حتی ماه به ماه متفاوت باشد. در نتیجه فکر اینکه طراح بگیرید و او هم با گذاشتن Label و Input و .... فرمها رو دستی بزند را سر از سر بیرون کنید !.

مشکل بعدی نرم افزار شرکت این است که نرم افزار قرار نیست از یک ماژول مشخص شروع شود. فرض کنید بدون تعریف کالا در انبار هم در یک حسابداری بشود فاکتور زد. هیچ گونه قانونی روی جداول نمیشه بگذارید چون سبب میشه مجبور بشید مثلن اول دیتا رو درون فلان جدول بریزید و بعد در جداول بعدی. در نرم افزار ما نقطه شروع مشخصی وجود ندارد و کاربر می تواند از هر جایی شروع به وارد کردن دیتا کند. تقریبا جداول ما از لحاظ طراحی هیچ ارتباطی با هم ندارند و 99 درصد فیلدها هم باید nullable باشند چون مشخص نیست نقطه ای که کاربر با آن شروع کرده قرار باشد همه فیلدهای جدول را پر کند.

سیستم توسط یک تیم هندی نوشته شده که البته به دلیل توضیحاتی که دادم و سختی تولید سیستم تیم را در 4 ماهه اول نابود میکند و مدیر فنی و شاخهای تیم ول میکنند و میروند.سپس هر برنامه نویس برای خودش شروع به ایجاد جدول میکند و داده ها مثلن در جدولی میرود که خودش ساخته بوده، نه جدولی که باید دیتا میرفته. این بنده های خدا هم موقع تحویل سیستم تست میکردند و خوب صفحه به درستی رفرش میشده. ولی بعدن در ماژولهای دیگر داده ای به درستی وجود نداشته است!.

ایراد بعدی داشتن حدود 350 عدد Session در سیستم است. تیم هندی وقتی به دردسر Stateless بودن وب می افتد، از لحظه لاگین یا حرکت در صفحات؛ شروع به ایجاد و ذخیره کردن همه چیز در سشنهای متعدد میکند. اگر کاربر از یک صفحه 2 تا Tab باز کند، عملن دیتای صفحه قبلی به دلیل تغییر مقادیر درون سشن دیگر بدرد نمیخورد و با ذخیره کردن دیتا عملن سیستم گرفتار Dirty Data میشود.

پرفورمنس سیستم هم یک افتضاح بین المللی است و شرکت دائم در حال پرداخت پول به ماکروسافت برای ارتقای پلنهای Azure بوده و هست.

سیستم گزارشاتی دارد که به دلیل تعدد بیهوده جداول و کپی بی دلیل داده ها در جداول مختلف با 30 دقیقه هم طول میکشد و دهن سرورهای دیتابیس رسمن سرویس میشود.

مشکل بعدی صفحاتی است که با تغییر یک آیتم در یک DropDown ، چندین کنترل باید حذف بشوند یا نمایش داده شوند با مثلن بر اساس سال مالی یک Grid ستونهای متفاوتی خواهد داشت یا اینکه یک لینک بر اساس فرمولهای سیستم به صفحات مختلفی باید برود. هیچی رو نمیشه بدون توجه به Business Logic از پیش تایین کرد. حتی منوهای سیستم هم بر اساس فرمولهای مالی شاید به جاهای مختلفی برود.

یکی دیگر از مسخره بازیهای سیستم ، Automate کردن پرتال مالیاتی کشور با چیزی مثل CapserJs و پر کردند فرمهای ثبت مالیات و ثبت داده های مشتری در درون دیتابیس روی پرتال مالیات و گرفتن نتیجه با Screen shoot خطا و اعلام آن به مشتری است که روندی است سنگین و زمانبر و مشتری باید می نشست تا این روند خلاص بشه و گاهی هم Http Request دیگه خسته میشد و ول میکرد. این سبب میشد مشتری این روند را مرتب تکرار کنه و دهن سرور و سرور دیتابیس سرویس بشه و ضمنن مشتری هم باید می نشست به یک صفحه مشخص با یک Wait نگاه میکرد تا نتیجه بیاد !.

سیستم خوشگل ما به Telerik بند شده و هیچ Grid در سیستم Paging ندارد و مثلن 4000 تا رکورد Fetch میشد و بعد داده میشد به Telerik تا خودش یک خاکی بر سر Paging بنماید.

یک کارمند هندی هم مسئول برطرف کردن مشکلات سیستم بود که فرق متغیر Int و Decimal را بدرستی نمیدانست. از سالها قبل یک سری پاکستانی و هندی و بنگلادشی آمده بودند و رفته بودند و عمل هیچ تغییری در سیستم داده نشده بود.

از نظر فنی به ASP.NET WebForm و SQL Server و Telerik و مقادیر زیادی Update Panel و اندکی JavaScript آن هم به صورت آشفته و جزیره ای فکر کنید. ضمنن EF 4 با آن Edmx فایل خوشگل هم هسته و ORM مورد استفاده در سیستم است.

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