چگونه ابزارهای مشاهده‌پذیری به نرم‌افزارهای قدیمی کمک می‌کنند

نرم افزار قدیمی فقط کدهای گرد و غباری روی مین فریم ها نیست. این مطالبی است که چند ماه یا سال پیش نوشتید. ابزارهای مشاهده‌پذیری و مستندات خوب به یافتن و رفع مشکلات کمک می‌کنند.

می دانید نرم افزار قدیمی چیست. این چیزی است که دیگران می نویسند و دیگران از آن استفاده می کنند. درست؟ اشتباه. «در لحظه ارسال کد، نرم افزار قدیمی دارید،» جین یانگ، بنیانگذار و مدیر عامل نرم افزار آکیتا، استدلال می کند. “چیزهایی وجود دارد که شما را مقید می کند. شما نمی توانید آن را تغییر دهید. من کارهایی را که هفته گذشته انجام دادم به خاطر نمی آورم، و فکر می کنم این در مورد هر فردی که کد ایجاد می کند صادق است.”

ما معمولاً «نرم‌افزار قدیمی» را به عنوان برنامه‌هایی می‌دانیم که با COBOL نوشته شده‌اند و در جایی روی برخی از رایانه‌های بزرگ قرار دارند. این نوع تفکر، توسعه‌دهندگان را به سمت ساخت کدهای نزدیک‌بین سوق می‌دهد، نه اینکه به این فکر کنند که چه کسی باید بعداً کد آنها را بخواند. همانطور که یانگ اشاره می کند، این تقریباً شامل همه افراد از جمله توسعه دهنده اصلی کد می شود.

چگونه می توانیم در مورد کد قدیمی خود هوشمندتر باشیم؟

تماس های شبکه و پیچیدگی

یکی از مشکلات کد این است که هرگز واقعاً ثابت نیست. هرگز فقط آنجا نمی نشیند. به عنوان یکی از بنیانگذاران Honeycomb و CTO مهم‌های خیریه در مصاحبه‌اش با یانگ می‌گوید: «هر زمان که به شبکه می‌پیوندد، شما در سرزمین اسرارآمیز هستید. دیگر کنترلی بر آن ندارید.» مثل این است که برنامه شما می‌تواند در باغ بکر عدن زندگی کند، اما به محض اینکه به آن نیاز دارید تا مفید باشد، که معمولاً به تماس شبکه نیاز دارد، همه جهنم از بین می‌رود زیرا پیچیدگی را در برنامه وارد می‌کنید.

Majors استدلال می‌کند که تا زمانی که نرم‌افزار خود را وارد مرحله تولید نکنید، نمی‌توانید واقعاً بدانید که چگونه قرار است رفتار کند. تنها در زمان تولید، شکاف‌های کد «میراث» خود را نشان می‌دهند. او می‌گوید: «تکه‌ای از کد، سیستم پیچیده‌ای است، اما زمانی که فعال می‌شود، وقتی کاربران و الگوهای ترافیکی و زیرساخت‌های مختلف زیر آن وجود داشته باشد، پیچیده می‌شود.» پیچیده، بله، و پیچیده به روش هایی که «ناشناخته های ناشناخته» را معرفی می کند. میجرز ادامه می‌دهد: «شما نمی‌توانید پیش‌بینی کنید که وقتی چیزی را تغییر می‌دهید، چه اتفاقی می‌افتد. شما باید آن را تغییر دهید و تماشا کنید و ببینید در یک محیط کنترل شده چه اتفاقی می‌افتد.”

مشکلات افراد، نه مشکلات کد

همانطور که ماژورها تاکید می‌کنند، “مهندسین فردی می‌توانند نرم‌افزار را نوشتن کنند، اما فقط تیم ها می توانند نرم افزار را تحویل دهند، ارسال کنند، نگهداری کنند و صاحب نرم افزار شوند. کوچکترین واحد ارائه نرم افزار تیم است. مطمئن نیستید منظور او چیست؟ یانگ توضیح می‌دهد که می‌توانیم خودمان را فریب دهیم و فکر کنیم مشکلات (اشکالات، خطاها و غیره) مسائل فنی برنامه ما هستند. او می گوید: «این همیشه یک مشکل مردم است. همیشه باید به مردم اعتماد کرد. و بسیاری از کارهایی که ابزار انجام می دهد به شما کمک می کند باستان شناسی در مورد کارهایی که مردم در گذشته انجام دادند، کارهایی که اخیراً انجام دادند [و] چه چیزی باعث این مسائل شده است. همه مردم هستند.”

این ما را به میراث بازمی گرداند. و قابلیت مشاهده.

شناخت میراث

ماجرز در مصاحبه‌اش با یانگ خاطرنشان می‌کند: «هزینه یافتن و رفع مشکلات در نرم‌افزار ما هر چه بیشتر از زمان نوشتن آن می‌گذرد به‌طور تصاعدی بالا می‌رود». به این ترتیب، ابزارهای مشاهده‌پذیری مانند Akita یا Honeycomb می‌توانند برای کمک به رفع مشکلات در عرض چند دقیقه با اجرای کد در تولید کنترل‌شده، حیاتی باشند، و به توسعه‌دهندگان این امکان را می‌دهند تا کد قدیمی خود را بلافاصله پس از نوشتن آن به جای تلاش برای رمزگشایی آن ماه‌ها یا سال‌ها یا حتی دهه‌ها بعد، اشکال زدایی کنند. .

به همین دلیل است که اسناد خوب بسیار ضروری است. گاهی اوقات فکر می‌کنیم مستندسازی برای کمک به دیگران برای بهره‌وری بیشتر با کدی است که ما نوشته‌ایم، و این درست است. اما همانطور که بنیانگذار دیتاست، سیمون ویلیسون یک بار برای من توضیح داد، او اسنادی را برای خود می نویسد، زیرا در غیر این صورت تمایل دارد فراموش کند که چرا کد را به روشی خاص نوشته است. او می‌گوید: «وقتی دو ماه دیگر به پروژه برمی‌گردم، همه چیز کار می‌کند، و من می‌دانم همه چیز کجاست، زیرا اسناد دقیقی نوشته بود تا به او (یا شخص دیگری) کمک کند تا خودش را با کد تغییر دهد.

اسناد خوب، تست های واحد خوب و قابلیت مشاهده خوب. میجرز اصرار می‌ورزد: «بخشی از توسعه، بهره‌برداری از آن و دیدن نحوه رفتار آن تحت سیستم‌ها و محدودیت‌های مختلف است. شما هرگز کد خود را در IDE درک نخواهید کرد. شما باید آن را اجرا کنید، و سپس آن را مشاهده کنید.

در مورد کسانی که به کد شما نگاه می‌کنند و سعی می‌کنند آن را سال‌ها یا دهه‌ها بعد اجرا کنند چطور؟ حتی برای کسانی که فکر نمی کنند این برای آنها صدق می کند، آنچه را که اخیراً «آویشای ایش شالوم» استدلال کرده است، در نظر بگیرید. : زیرساخت‌های «مدرن» ما مانند لینوکس، MySQL، PostgreSQL، و غیره، ده‌ها سال قدمت دارند و حتی ابرهای «مدرن» هم اکنون در سنین نوجوانی هستند. نگران‌کننده‌تر، او گفت: «این زیرساخت، در حالی که خود را به‌طور قابل‌توجهی انعطاف‌پذیرتر و پایدارتر از خوش‌بینانه‌ترین پیش‌بینی‌های ما نشان می‌دهد، نشانه‌هایی از زنگ زدگی و کهنگی را نشان می‌دهد، و نگهداری و توسعه را سال به سال چالش‌برانگیزتر می‌کند.»

هم از نظر میراث جدید و هم از نظر میراث قدیمی، همه ما در دنیایی قدیمی زندگی می کنیم. ما در حال حرکت از یکپارچه‌ها به میکروسرویس‌ها هستیم (گاهی اوقات)، از دیسک به رم تغییر می‌کنیم، و وقتی با محدودیت‌های سخت‌افزاری یا نرم‌افزاری مواجه می‌شویم، یا فرصت‌هایی را برای بهره‌برداری از پیشرفت‌های جدید پیدا می‌کنیم، کارهای بیشتری انجام می‌دهیم. برای کسانی که با سیستم‌هایی سروکار دارند که سال‌ها یا دهه‌ها قدمت دارند، همانطور که یانگ توضیح می‌دهد که تولستوی درونی خود را هدایت می‌کند، بدتر می‌شود: «هر سیستمی که در سال گذشته ساخته شد، موارد مشابهی دارد، اما هر سیستمی که ۵،۱۰ سال پیش ساخته شده است، همه آنها به طرق مختلف قدیمی هستند… هر سیستم میراثی به روش منحصر به فرد خود میراث است.”

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

البته، این کار میراث بیشتری ایجاد می کند. اما این مشکلی ندارد، تا زمانی که از ابزارهای مشاهده‌پذیری برای درک و مهار آن میراث استفاده می‌کنید. راهی برای اجتناب از میراث وجود ندارد. اکنون دلیلی برای تمایل وجود ندارد.