آیا از شنیدن اینکه توسعه دهندگان نرم افزار نرم افزار خود را آزمایش می کنند شگفت زده خواهید شد؟ ممکن است با تمام قطعی‌های امسال اینطور نباشد، اما توسعه‌دهندگان به طور متوسط ​​42 درصد از هفته کاری خود را صرف تعمیر و نگهداری می‌کنند. بعد این همه قطعی چه خبر؟

Crowdstrike ممکن است رعد و برق ترین صدا را ایجاد کرده باشد، اما در سال 2024، قطعی ها باعث توقف تحویل فست فود، آفلاین کردن واتس اپ و اینستاگرام ، سرگردانی مسافران در فرودگاه هیترو و توقف غذای تازه در مرز برگزیت شده است.

این قطعی ها به این دلیل رخ ندادند که توسعه دهندگان نرم افزار را آزمایش نکردند. آنها به دلیل پیکربندی های نرم افزاری بیش از حد پیچیده رخ دادند - تغییرات بسیار زیاد در محصولات توسط افراد زیادی به دلایل بسیار زیاد. بسیاری از شرکت‌ها در حال آزمایش کد در معماری نرم‌افزاری هستند که دیگر هیچ‌کس آن را درک نمی‌کند. این یک برج بسیار بزرگ جنگا است. فقط یک «بلوک ویژگی» دیگر ممکن است همه چیز را خراب کند. هیچ کس نمی خواهد به آن دست بزند. هیچ کس حتی به یاد نمی آورد که چگونه ساخته شده است. اما دیر یا زود، یک فرمان اجرایی "این محصول به هوش مصنوعی نیاز دارد."

این نبرد ابدی مهندسی نرم افزار است: نوآوری در مقابل تعمیر و نگهداری، و در حال فرسایش بافت نرم افزار جهان است.

چرا نرم افزار در حال فرسایش است؟

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

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

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

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

هزینه انسانی فرسایش نرم افزار

اگر بیش از 40 درصد از زمان توسعه فقط زنده نگه داشتن کد باشد، ارزش گفت ه ای برای محصول ایجاد نمی کند. وقتی جلسات، زمان برای نظرات و بازخوردها و غیره را در نظر بگیرید، مطمئناً کمتر از نیمی از هفته برای توسعه ارزش گفت ه باقی مانده است.

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

اتفاق بعدی که می افتد فرسایش مهندسینی است که به اندازه کافی مصرف کرده اند. سپس استفاده از مهندسان جدید زمان را برای بازار طولانی تر می کند و همه دست اندرکاران را ناامید می کند. اشتباهات قدیمی دوباره ظاهر می شوند، افراد بیشتری می روند، با این تفاوت که اکنون کهنه سربازان باتجربه نیز هستند. به کجا ختم می شود؟

خود "تغییر به چپ" را اصلاح می کند

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

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

تعمیر دیرهنگام راه حلی پرهزینه است. کم هزینه ترین راه حل این است که معماری خود را درست زمانی که هنوز در حال طراحی آن هستید، درست کنید. قبل از نوشتن همه کدها، نه بعد از آن، QA را محکم در توسعه نرم افزار خود ببافید. اگر در مراحل اولیه ساخت نمونه اولیه هستید، مطمئناً QA ممکن است هزینه های اضافی غیر ضروری باشد. اما لحظه ای که یک کسب و کار بادوام ایجاد می کنید که مشتریان را جذب می کند، به کد با کیفیت نیاز دارید. شما نمی خواهید مشتریان خود را در اوایل عمر محصول خود از دست بدهید. اگر محصول شما هفته آینده ارسال شود و مجبور باشید معماری خود را دوباره مهندسی کنید تا از فراخوانی محصول جلوگیری کنید، این یک فاجعه با ابعاد حماسی است. وقت شما را به سمت بازاریابی، هزینه توسعه بالون و همه را از بین می برد.

چگونه کد با کیفیت را دریافت می کنید؟ شما به چندین منبع اطلاعات نیاز دارید. در تجزیه و تحلیل کدهای استاتیک و تست های عملکردی، که باید با نوشتن کد جدید اجرا شوند، کوتاهی نکنید. شما باید بدانید که چه مقدار کد را شبیه سازی می کنید، وابستگی های پنهان شما در کجا قرار دارند، اجزای شما چگونه با یکدیگر ارتباط برقرار می کنند و غیره. وقتی این موارد را می دانید و تأیید معماری خود را اجرا می کنید، شناسایی مشکلات آسان تر می شود. اگر نمی توانید هر نوع آزمایشی را فوراً زیر نور خورشید انجام دهید، خوب است، اما به مرور زمان این فرآیندها را شروع کنید.

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

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

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

ما بهترین لپ تاپ ها را برای برنامه نویسی معرفی کرده ایم.

این مقاله به عنوان بخشی از کانال Expert Insights TechRadarPro تهیه شده است که در آن بهترین و باهوش ترین ذهن ها در صنعت فناوری امروز را معرفی می کنیم. نظرات بیان شده در اینجا نظرات نویسنده است و لزوماً نظرات TechRadarPro یا Future plc نیست. اگر علاقه مند به مشارکت هستید، اطلاعات بیشتری را در اینجا بیابید: https://www.techradar.com/news/submit-your-story-to-techradar-pro