نوسازی نرمافزار قدیمی سازمان
هر سازمانی که بیش از چند سال نرمافزار داشته، یکی از اینها را دارد: سامانهای که کار میکند، هیچکس دقیقاً نمیداند چطور، و هر تغییر کوچکی در آن هفتهها طول میکشد و ریسک دارد.
معمولاً هم اسم این وضعیت را «بدهی فنی» میگذارند و بحث خیلی زود به «باید بازنویسی کنیم» میرسد.
اول: مطمئن شوید مسئله چیست
نوسازی گران است و بخشی از دلایلی که به آن منجر میشود با کار کمتری هم حل میشوند. قبل از تصمیم، مشخص کنید کدامیک از اینها را دارید:
نمیشود تغییرش داد. هر درخواست کسبوکاری ماهها طول میکشد. این جدیترین نشانه است، چون مستقیم به سرعت شرکت میخورد.
نمیشود به آن وصل شد. API ندارد و هر یکپارچهسازی جدید یک راهحل موقت میخواهد.
ریسک امنیتی دارد. روی نسخهای اجرا میشود که دیگر وصلهٔ امنیتی نمیگیرد. این یکی مهلت دارد و قابل تعویق نیست.
کسی بلد نیست. فناوریاش آنقدر قدیمی است که نیرو پیدا نمیشود، یا تنها کسی که میشناسدش نزدیک بازنشستگی است.
کند است. این تنهاترین دلیل ضعیف در فهرست است. کندی معمولاً مسئلهٔ بهینهسازی است نه معماری، و بازنویسی بهخاطر آن، گرانترین راه حل یک مشکل ارزان است.
اگر فقط مورد آخر را دارید، احتمالاً نیازی به این پروژه ندارید.
چهار مسیر، نه دو تا
بحث معمولاً بین «نگه داریم» و «از نو بنویسیم» قاب میشود. بین این دو، دو گزینهٔ دیگر هم هست که اغلب بهترند.
رها کردن. بخشی از سامانههای قدیمی کاری میکنند که دیگر لازم نیست، یا نرمافزار آمادهای امروز بهتر انجامش میدهد. قبل از هر چیز، این را چک کنید. ارزانترین نوسازی، حذف است.
پوشاندن. سامانهٔ قدیمی سر جایش میماند و یک لایهٔ API روی آن مینشیند تا بقیه بتوانند با آن حرف بزنند. برای وقتی که مشکل شما «نمیشود وصل شد» است و نه «نمیشود تغییرش داد». چند ماه کار است، نه چند سال.
جایگزینی تدریجی. بخشها یکییکی بیرون کشیده و بازنویسی میشوند در حالی که سامانهٔ قدیمی همچنان کار میکند. مسیر پیشنهادی ما در بیشتر موارد؛ چطوریاش را در مهاجرت تدریجی نوشتهایم.
بازنویسی کامل. همهچیز از نو، و در روز موعود جابهجایی.
چرا بازنویسی کامل معمولاً شکست میخورد
نه به دلیل فنی. به سه دلیل ساختاری:
سامانهٔ قدیمی متوقف نمیشود. کسبوکار در طول این دو سال تغییراتی میخواهد و شما مجبورید هم روی قدیمی کار کنید و هم روی جدید. عملاً دو تیم و دو هزینه.
دانشی که مکتوب نیست. آن سامانه پر از قواعدی است که کسی ننوشته — استثنای یک مشتری خاص، تصمیمی که ده سال پیش گرفته شده. اینها در تحلیل بیرون نمیآیند؛ در هفتهٔ اول بعد از راهاندازی بیرون میآیند، از زبان کاربری که میگوید «قبلاً این کار را میکرد».
هیچ ارزشی تا روز آخر تحویل نمیشود. پروژهای که هجده ماه هیچ خروجی قابل استفاده ندارد، در ماه دوازدهم پشتیبان مدیریتیاش را از دست میدهد.
بازنویسی کامل فقط دو جا منطقی است: وقتی سامانه کوچک است و در چند ماه تمام میشود، و وقتی واقعاً هیچ راهی برای جداسازی تدریجی وجود ندارد.
داده، بخشی که همیشه از برآورد بیرون میماند
در پروژههای نوسازی، مهاجرت داده تقریباً همیشه سختتر از انتظار است.
دادهٔ دهساله تمیز نیست: رکوردهای تکراری، فیلدهایی که معنایشان در طول زمان عوض شده، مقادیری که با قاعدهٔ امروز نامعتبرند ولی وجود دارند و نمیشود دورشان ریخت.
تصمیمی که باید صریح گرفته شود: چقدر از تاریخچه منتقل میشود؟ انتقال کامل گران است. نگهداشتن سامانهٔ قدیمی بهعنوان بایگانی فقطخواندنی، معمولاً ارزانتر و امنتر است — و کسی که به سابقهٔ ده سال پیش نیاز دارد، میتواند همانجا ببیندش.
و دستکم یک مهاجرت آزمایشی کامل انجام دهید و خروجی را با مبدأ تطبیق دهید: تعداد رکورد، جمع مبالغ، و نمونهگیری دستی. مغایرتی که در مهاجرت واقعی پیدا شود، وقت رفعش نیست.
قبل از شروع، اینها را داشته باشید
فهرست فرایندهایی که سامانهٔ فعلی پوشش میدهد، با نشانهگذاری اینکه کدامها هنوز استفاده میشوند. تقریباً همیشه بخشی از قابلیتها سالهاست لمس نشدهاند و بازنویسیشان هدررفت محض است. لاگ استفاده، این را بهتر از هر مصاحبهای میگوید.
فهرست اتصالهای ورودی و خروجی. هر سامانهای که به این یکی وصل است، در مهاجرت باید در نظر گرفته شود.
و کسی که قواعد کسبوکار را میداند و در دسترس است. اگر آن آدم وجود ندارد یا وقت ندارد، پروژه هر مسیری که برود به مشکل میخورد.
و یک توصیه
نوسازی را با «سامانهٔ جدید همان کارهای قبلی را میکند» تعریف نکنید. این هدف نه انگیزهای میسازد و نه قابل دفاع است، چون از دید کسبوکار پول خرج کردهاید تا به همانجایی برسید که بودید.
هدف را روی چیزی بگذارید که امروز ممکن نیست و بعد از نوسازی ممکن میشود — اتصالی که لازم دارید، تغییری که هر بار ماهها طول میکشد، کانالی که نمیشود اضافه کرد. آن چیز، هم دامنهٔ پروژه را تعیین میکند و هم دلیل ادامه دادنش را در ماه دهم.