تقریبا این روزها همه بر روی پلتفرم های حرفه ای ارتباطی دوست دارند در مورد تکنولوژی های روز، پیشرفت ها و نوآوری ها صحبت کنند. اما واقعیت تلخی که وجود دارد این است که بسیاری از مهندسان حرفه ای نرم افزار بیشتر در حال کار بر روی سیستم های قدیمی و نرم افزار های Legacy هستند تا کار بر روی راهکار های تمیز با معماری های نوین و تکنولوژی های به روز!
اما چرا؟ دلیل این امر بسیار ساده تر از آن چیزی است که به نظر می رسد. در حالت اول سازمان با خرید یک نرم افزار Of-Shelf و قرار دادن تمام تمرکز خود بر روی توسعه جنبه های کسب و کار گذاشته و اکنون که به عمق نیاز به تغییر و بازنویسی نرم افزارهای کسب و کار پی برده اند؛ می بینند که نرم افزار در تمامی جنبه های سازمان تا فرهنگ کاری ریشه دوانده و تغییر نرم افزار مستلزم تغییر تمامی رویه ها، فرهنگ ها و ذهنیت ها در سازمان است. از آنجا که این تغییرات نیازمند خروج افراد و حتی سازمان از دایره راحتی و دست و پنجه نرم کردن با مشکلات بوده بسیار ترسناک است و معمولا تا جایی که بقا و سودآوری سازمان را به خطر بیاندازند، به تعویق می افتند
در حالت دوم به ما تولید کنندگان نرم افزار بر میگردد. در دنیای جدید ما هر ساله نرم افزار ها، فیچر ها و خط های بسیاری کد تولید میکنیم و بسیاری از این نرم افزارها حتی مورد بررسی مجدد و ریفکتورینگ قرار نمیگیرند. گاهی اوقات این نرم افزار ها به صورت متوالی خلق ارزش کرده و به موتور حرکتی سازمان تبدیل می شوند و سازمان با دنبال کرده اضافه نمودن خدمات جدید و ایجاد ارزش جدید انگیزه لازم برای اضافه کردن کد های جدید به نرم افزار قبلی را بدون بهینه سازی و منطبق سازی با تکنولوژی روز را ایجاد میکند. این فرآیند تا جایی پیش میرود که با یک کد بیس قدیمی و بسیار پیچیده روبه رو خواهیم شد که درهم تنیدگی بسیار بالایی میان اجزا و کامپوننت های آن وجود دارد.
البته حالات دیگری نیز وجود دارد که شاید کمتر از این دو حالت فراگیر باشند فلذا از اشاره به آنها خودداری می کنیم.
چه دوست داشته باشیم چه نداشته باشیم هر روز نرم افزار های Legacy بیشتری در حال به وجود آمدن هستند و هیچ راه فراری وجود ندارد.!!!
اما همین موضوع دلیل محکمی برای رویارویی با نرم افزار های قدیمی است. در این مقاله (یا ممکن است یک سری از مقالات به دلیل طولانی شدن به بررسی علل شکست بازنویسی نرم افزار های قدیمی می پردازیم و راه های پیشگری از شکست را با یکدیگر بررسی می کنیم.) با من در ادامه همراه باشید…
به چه نرم افزاری Legacy می گویند؟
قبل از هر گونه بررسی بیشتری باید به به تفاهم برسیم که نرم افزار Legacy چیست؟ یکی از راه‌های تعریف این مفهوم، نگاه کردن به فناوری زیربنایی نرم افزار است. وقتی صحبت از نرم افزارهای Legacy به میان می آید، معمولا ذهنیت افراد به سمت نرم افزارهای بزرگ پیاده سازی شده بر روی mainframe ها با زبان های برنامه نویسی Cobol یا PL/I یا غیره می رود. برخی نیز فکرشان سمت برنامه های دو لایه با منطق های غنی پیاده سازی شده در سطح دیتابیس رفته و حتی میتوانیم تعدادی از خواهر و برادرهای کوچک‌تر مانند برنامه‌های قدیمی Java/JEE و .NET را نیز در این زمره بگنجانیم.
سال به سال، تعداد فناوری و زبان های توسعه نرم افزار افزایش می یابد. سال به سال، تعداد فناوری‌هایی که میتوانیم آنها را Legacy بنامیم نیز به همان سرعت در حال افزایش است. با توجه به این روند، بسیاری از برنامه های جاوا اسکریپت و یا هر زبان دیگری، که ممکن است جدید و مدرن به نظر برسند، نیز باید در حال حاضر به عنوان Legacy در نظر گرفته شوند.
به طور خلاصه، برخی از فناوری‌ها (مانند Cobol) بدون هیچ سؤالی Legacy محسوب می شوند، در حالی که برای دسته بندی برخی دیگر از استک های تکنولوژی (مانند JS)، نرم افزار را باید عمیق‌تر مورد بررسی قرار داد.
برای نگاه عمیق تر می توان مشکلات و مسائل ریز دیگری را مورد بررسی قرارداد تا این دسته بندی ملموس تر باشد. از فاکتور های دیگری که میتواند در دسته بندی یک نرم افزار در زمره Legacy تاثیرگذار باشد Practice های دواپس، مستندات، فعال بودن انجمن یا کامیونیتی آن تکنولوژی، چرخه عمر آن تکنولوژی و مسائل کوچک دیگر هستند.
با توجه به این تعاریف میتوان نتیجه گرفت بسیاری از ما در طول عمر حرفه ای خود با چندین نمونه از این نوع نرم افزار ها دست و پنجه نرم کرده ایم.
همچنین در این میان Anti-Pattern هایی هم وجود دارند که باید حواسمان باشد قوه تصمیم گیری ما را تحت تاثیر نگذاشته و به اشتباه به یک نرم افزار برچسب Legacy نزنیم. یکی از این اشتباهات buzz-Word ها تکنولوژی هستند. به عنوان مثال برای برخی افراد اگر نرم افزاری که امروزه تولید میشود؛ مطابق معماری میکروسرویس نباشد خود به خود در ذهن این افراد در دسته بندی Legacy قرار می گیرد.
چقدر از تلاش ها برای بازنویسی یک نرم افزار Legacy بزرگ به شکست مواجه می شوند؟
در آخرین گزارشات و بررسی های صورت گرفته (البته تقریبی هستند چرا که کلمه موفقیت و شکست عبارات کیفی هستند نه کمی) تقریبا از هر ۵ تلاش برای بازنویسی یک نرم افزار Legacy کلان ۴ مورد آن با شکست مواجه می شود. البته تعریف شکست نسبی بوده و باید عامل های شکست بررسی شود. اما شکست اینجا به معنی شکست است!!
۴ شکست از هر ۵ تلاش عدد بسیار بالایی مخصوصا با توجه به هزینه های توسعه یک نرم افزار کلان می باشد. در ادامه به سناریو های معمولی که سازمان در صدد بازنویسی نرم افزار های Legacy می پردازد اشاره میکنیم.
چه زمانی سازمان ها تصمیم به بازنویسی نرم افزار های Legacy می گیرند؟
معمولا سناریو هایی که در آنها سازمان نیاز به باز نویسی نرم افزار های Legacy خود دارند بر اکثر مدیران و رهبران سازمان آشکار است. در زیر به تعدادی از این سناریو ها اشاره میکنیم: (سناریو های زیر بر اساس اولویت، دسته بندی نشده اند.)
- نیاز به ورود به بازار های جدید که با نرم افزار فعلی امکان پذیر نیست.
- نیاز به مقیاس پذیری نرم افزار برای پاسخ دهی به تقاضا های رو به رشد کسب و کار
- افزایش هزینه های نگهداری و توسعه نرم افزار های قدیمی
- کاهش سرعت توسعه و افزودن توانمندی های جدید به نرم افزار
- عدم دسترسی به نیروی کار جوان و جامعه بزرگتر نیروی کار
- افزایش هزینه ها نگهداری تجهیزات میزبانی نرم افزار های Legacy
- پایان یافتن چرخه عمر استک تکنولوژی
- مسائل امنیتی و نیازهای به روز رسانی برای در امان ماندن از حفره های امنیتی
- نیاز به توسعه سرویس های جدید
- نیاز به Integration با سیستم های دیگر
- نیاز به خلق ارزش جدید و سرویس های VAS
- مهاجرت به رایانش ابری و رایانش Edge
- تطبیق با نیاز های regulatory جدید
- و …….
همانطور که در بالا اشاره کردیم دلایل یک سازمان برای بازنویسی نرم افزار های کسب و کار می تواند بسیار متنوع باشد اما در نهایت هدف یک چیز است. بازنویسی نرم افزار!!!
در ادامه به سناریو و روش اول و اصلی بازنویسی نرم افزار و بررسی دلایل شکست آن می پردازیم.
بازنویسی کامل از ریشه!
اولین و بارزترین راه حلی که برای بازنویسی یک نرم افزار به ذهن مدیران، رهبران و توسعه دهندگان یک سازمان و هر شخص دیگری خطور میکند توسعه سیستم جدید از ریشه با معماری های نوین و همچنین کد تمیز و تکنولوژی های به روز است.
این راهکار در نگاه اول به طور بالقوه، همه مشکلات سازمان را حل می کند، که عالی است! و ممکن است ساده به نظر برسد، اما اصلا اینطور نیست. در واقع هر ۴ شکست از ۵ تلاش برای بازنویسی نرم افزار های کلان و بزرگ متعلق به بازنویسی این نرم افزارها با رویکرد بازنویسی از ریشه بوده اند! اما چرا؟
البته این رویکرد در یک سناریو ممکنه به کار بیاد اونم اینه که شما مسئول بازنویسی یک نرم افزار Legacy باشید که مسئول توسعه اش نباشید و مدام به روز نشود!!!!
دلیل اول: پیچیدگی! آن هم از همه مدل!!!!
یکی از دلایل بزرگ شکست پروژه های بازنویسی از ریشه نرم افزارهای Legacy از حجم پیچیدگی در نرم افزار اصلی و همچنین حل این مشکلات با افزایش پیچیدگی در معماری های جدید نشات می گیرید. معمولا نرم افزار های Legacy دارای پیچیدگی های فنی، منطقی و خاص بوده، فهم این پیچیدگی ها تنها با نگاه کردن به نرم افزار قابل فهم نبوده و گاهی حل کردن همین پیچیدگی ها در استک تکنولوژی جدید پیچیدگی های بیشتری را اضافه می کند.
اغلب در پشت یک سیستم قدیمی هزاران هزاران نفر روز کار توسط انواع مختلف توسعه‌دهندگان وجود دارد که شامل توسعه دهندگان خیلی تنبل، خیلی باهوش، سینیورها، جونیورها، متوسط‌ها، قدیمی ها، پاره وقت‌ها یا افراد سرسخت می شود. همه این افراد با همکاری هم یک جانور پیچیده را ایجاد کرده اند. اگر این واقعیت را نادیده بگیرید، تلاش لازم را برای بازنویسی این جانور دست کم گرفته خواهد شد.
یک نرم افزار Legacy که به زبان Cobol نوشته شده است را در نظر بگیرید. این نرم افزار دارای لاجیک های بسیار زیادی در سطح اپلیکیشن و دیتابیس بوده که بر روی یک Mainframe پیاده سازی شده است. تصور کنید در تلاش برای بازنویسی این نرم افزار شما میخواهید نرم افزار را مقیاس پذیر کرده و سرعت آن را بهبود ببخشید و نرم افزار جدید را با معماری میکروسرویس پیاده سازی کنید.
خب همین جا یک لحظه صبر میکنیم…….
معماری میکروسرویس خودش عامل بسیاری از پیچیدگی ها از Consistency، Distributed Transaction، Distributed Locks، Logging، Deployment و …. است.
حال شما باید یک نرم افزار را با بسیاری پیچیدگی منطقی را به معماری میکروسرویس تبدیل کنید. احتمال اینکه یک نقطه از کار اشتباهی صورت بپذیرد بسیار زیاد است.
دلیل دوم: ارزیابی اشتباه!!!
نرم افزارهای Legacy را معمولا کسی دوست ندارد و کسی هم کامل نمیشناسد چرا که سالیان سال و توسط افراد مختلف توسعه داده شده اند. خب همین جمله و دلیل اول با یکدیگر دو نکته مهم در خود دارند که هر دو میتواند به دست کم گرفتن و یا بیش از حد پیچیده نگاه کردن به تلاش مورد نیاز برای بازنویسی نرم افزار بیانجامد.
هم دست کم گرفتن و هم بیش از حد دست بالا گرفتن یک نرم افزار میتواند تیم بازنویسی را با مشکلاتی مواجه کند. دست کم گرفتن میتواند توسعه را با شکست مواجه کرده و دست بالا گرفتن نیز میتواند باعث نگاه پیچیده به مسائل ساده تر شود و در نهایت بازنویسی را با مشکلات جدی رو به رو کند و یا به سیستمی ختم شود که چیزی دست کم از نرم افزار Legacy پیشین ندارد.
دلیل سوم: نگاه پروژه محور به یک محصول استراتژیک!
همان طور که در پست های پیشین هم اشاره کردم امروزه نرم افزار ها به توانمندی های استراتژیک کسب و کار ها تبدیل شده اند. نگاه پروژه محور به یک محصول استراتژیک چیزی جز یک فاجعه رقم نمیزند. همانطور که اشاره کردیم نرم افزار های Legacy پیچیدگی های بسیاری دارند و همچنین اغلب مورد ارزیابی اشتباه قرار میگیرند.
نگاه پروژه محور نیازمند تعریف Baseline هایی برای Scope، زمان و هزینه می باشد. حال سوال اینجاست؟ بر چه اساسی میخواهید قبل از شروع کد نویسی بودجه و برنامه زمانی یک سیستم با این حجم پیچیدگی را تعریف و مستند کنید؟
به شخصه هر شکستی که در توسعه نرم افزار های کلان و بازنویسی سیستم های Legacy دیده ام، بخشی از آن ریشه در این موضوع داشته است. حتی در مواقعی دیده ام که مدیرانی که بیش از بیست سال سابقه مدیریت پروژه را دارند با این جمله که «اگر این موارد را تعریف نکنید چگونه پیشرفت را اندازه گیری میکنید؟» محصولات پیچیده را وارد دنیای مدیریت پروژه سنتی کرده و باعث شکست حتمی پروژه می شوند. در صورتی که کار پیچیده نیازمند روش های متناسب با خودش برای مدیریت آن است.
دلیل چهارم: عدم جدا بودن تیم های توسعه و خودمختاری آنها
یکی دیگر از دلایل شکست تلاش های بازنویسی نرم افزارهای قدیمی استفاده از تیم توسعه دهنده فعلی برای توسعه نسخه جدید می باشد. اصولا برای توسعه نرم افزارها بهترین کار این است که هر تیم متمرکز بخش کاری خود باشند. در ابتدا می توان تصور کرد که استفاده از نیرو هایی که ۱۰ سال گذشته خود را صرف توسعه یک سیستم نرم افزاری کرده اند برای بازنویسی همان نرم افزار بهترین گزینه موجود هستند. اما معمولا در این مواقع پرتاب شما دورتر از پرتاب قبلی نخواهد رفت و معمولا با جملاتی مانند «هیچ نرم افزاری بهتر از نرم افزاری که من ۱۰ سال گذشته را صرف توسعه آن نموده ام نمیتواند باشد» یا زمانی که نیاز به تغییر استک تکنولوژی وجود دارد معمولا بیان میکنند «مگر استک تکنولوژی ما چه مشکلی دارد؟». احتمالا کم و بیش هر یک از شما با این مشکل یا سخنان برخورد داشته اید! همچنین یک سناریوی محتمل در چنین مواقعی وجود دارد که بدین شرح است:
تیم در صدد بازنویسی سیستم legacy با مدیریت صحبت کرده و درخواست توقف درخواست های فیچر های جدید را تا پایان بازنویسی نرم افزار میدهد. مدیریت موافقت نموده و توسعه شروع می شود. پیش بینی میکنید ۱ ساله بازنویسی به نتیجه برسد. بعد از یک الی دو ماه یک باگ عجیب و غریب که کل کسب و کار را تهدید میکند در سیستم قبلی کشف می شود و هیچ راهی به جز درست کردن باگ ندارید. بنابراین کد قبلی را تصحیح کرده و همچنین به دلیل اینکه نرم افزار جدید از روی کد های قبلی در حال بازنویسی است نسبت به اعمال تغییرات در کد جدید هم اقدام میکنید. یک ماه بعد یکی از مشتریان که دارای روابط قراردادی سفت و سختی با شماست نیاز دارد که درخواست فیچر جدیدش پیاده سازی شود وگرنه شما مجبور به پرداخت غرامت می شوید. بنابراین شما فیچر جدید را در کد قدیمی پیاده سازی کرده و همچنین چون نرم افزار جدید باید جایگزین قبلی شود تغییرات را نیز در نرم افزار جدید باید پیاده سازی کنید. بعد از ۷ ماه متوجه میشود که در زمانبندی که تعیین کرده بودید بازنویسی قبلی امکان پذیر نیست. (دست کم گرفتن). بنابراین شروع به اضافه کاری و دست و پا زدن بیشتری میکنید. بعد از یک سال و سه ماه نرم افزار جدید را پایلوت کرده ولی مهندسان تست شما و مشتریان ایرادات بسیاری را از آن استخراج می کنند که باید قبل از مهاجرت به نرم افزار جدید درست شوند. یک سال و نیم زمان سپری شده، مدیریت از وضعیت نرم افزار جدید خوشحال نیست. روند ایجاد تغییرات و خلق ارزش در یک سال گذشته کند بوده. الان دو مشکل دارید ایجاد تغییرات در کد قدیمی و همچنین اضافه نمودن فیچر ها به کد جدید. وضعیت بسیار آشفته می شود و همگی ناراضی هستند (در نهایت عامل اصلی سنجش یک محصول موفق نه زمان و هزینه بلکه رضایت طرفین است.). در نهایت تلاش به دو سیستم مواضی ختم می شود. نرم افزار قدیمی و جدید که نرم افزار جدید هنوز توانایی مهاجرت کامل نرم افزار قدیمی را ندارد و هر درخواستی نیازمند پیاده سازی دوباره است. اوضاع زمانی وحشتناک می شود که هر دو سیستم را در پروداکشن قرار داده و یا به مشتریان مختلف نسخه های مختلفی از نرم افزار قدیمی و جدید را فروخته باشید.
سناریو بالا شاید برای بسیاری از افراد با تجربه آشنا و یادآور خاطرات تلخی باشد.
اما نگران نباشید. تغریبا همه افرادی که بالای ۱۰ سال در این حرفه بوده اند یا تجربه چنین شرایطی را داشته یا حداقل در مورد آن شنیده و یا دیده اند.
دلیل پنجم: تجربه یا انتخاب استک بازنویسی اشتباه
دلیل پنجم تا حدودی بر گرفته از ترکیب اندکی از هر یک از دلایل پیشین بوده است. اما نکته مهم این است که آیا توانایی و تجربه چنین کاری را داریم؟
یکی از سوالاتی که هر سازمانی باید قبل از شروع مورد پرسش قرار دهد این است که آیا ما تجربه چنین تلاشی را داریم؟
آیا شخصی را داریم که در تنگنا های حساس بتواند تصمیمات فنی و مدیریتی درستی بگیرد؟
آیا میتوانیم بخشی از تیم فنی را بر روی این پروژه متمرکز کنیم؟
آیا میتوانیم با هزینه های مناسب نیروی جدید جذب کنیم تا از عهده این کار برآییم؟
آیا استک تکنولوژی و روش بازنویسی ما درست است؟
آیا قابلیت ایجاد فرهنگ، فرآیند ها و سازمان بازنویسی درستی در درون سازمان هستیم؟
در این قسمت مدیریت ارشد باید تمامی اعتماد به نفس های کاذب و شعار و همچنین تلاش برای انگیزش تیم را کنار گذاشته و با واقعیت ها رو به رو شود و با نهایت استقلال فکری و دوری از سوگیری های شناختی به این سوالات پاسخ دهد.
دلایل ذکر شده تنها دلایل شکست بازنویسی نرم افزار های کلان کسب و کاری نبوده و همچنین معمولا به تنهایی دلیل شکست یک تلاش برای بازنویسی نرم افزار های Legacy را رقم نمی زنند. اغلب معمولا مقداری از هر دلیل با دست در دست هم گذاشتن، تلاش های سازمان را در این موارد بی اثر کرده و گاهاً شکست های سنگین و گران قیمتی را رقم می زنند.
در مقاله بعدی به نحوه بازنویسی نرم افزار های Legacy و به حداقل رساندن خطرات شکست صحبت خواهیم کرد.
لطفا با من همراه باشید.
همچنین اگر نقطه نظر یا توصیه و یا موردی هست که به نظر شما اشاره به آن باعث بهتر شدن مطلب می شود ممنون میشوم با من در ارتباط باشید.
دیدگاه خود را بنویسید