ماه گذشته، GitClear تحلیلی از ۲۱۱ میلیون خط کد را در گزارش کیفیت کد هوش مصنوعی Copilot خود منتشر کرد. یکی از یافتههای کلیدی این است که سیگنالهای بازسازی در حال سقوط هستند، در حالی که تکرار کد و چرخش در حال افزایش است. در واقع، سال ۲۰۲۴ اولین سالی است که معرفی کد تکراری بیشتر از فعالیت بازسازی است.
این روند به افزایش دستیاران کدنویسی هوش مصنوعی نسبت داده میشود، و اگر این روند ادامه یابد، ممکن است به سمت یک بحران نرمافزاری پیش برویم.
مسابقه برای پذیرش هوش مصنوعی
اگر در توسعه نرمافزار کار میکنید، شخصی به شما گفته است که "هوش مصنوعی جایگزین توسعهدهندگان نخواهد شد؛ توسعهدهندگانی که از هوش مصنوعی استفاده میکنند جایگزین توسعهدهندگانی خواهند شد که این کار را نمیکنند." پیام روشن است: یا از هوش مصنوعی استفاده کنید یا منتظر تغییر شغل باشید. پیامهای مثبتتر نشان میدهند که میتوانیم کارهای طاقتفرسا - وظایفی که نیاز به تکرار زیاد و تفکر کم دارند - را حذف کنیم.
نظرسنجی Stack Overflow State of Development اخیر نشان داد که بیش از ۶۰٪ از توسعهدهندگان اکنون از هوش مصنوعی به عنوان بخشی از کار خود استفاده میکنند و بسیاری دیگر قصد انجام این کار را دارند. انگیزه اصلی برای پذیرش هوش مصنوعی افزایش بهرهوری است. همانطور که گزارش GitClear نشان میدهد، جنبه منفی چشمگیر تمایل به افزایش بهرهوری این است که ممکن است زنجیر دوچرخه خود را باز کنید تا سریعتر رکاب بزنید.
در مورد توسعه نرمافزار، ما اکنون به سرعت در حال افزایش سرعت تغییر در پایگاههای کد خود هستیم. پیشبینی میشود که در سال ۲۰۲۵، میزان تغییر تقریباً دو برابر تعداد قبل از هوش مصنوعی (۲۰۲۱) باشد.
این جهش در بهرهوری احتمالاً از نظر بسیاری، به ویژه کسانی که هوش مصنوعی را میفروشند، خبر خوبی تلقی میشود. با این حال، باید خرد پیشینیان خود را به یاد داشته باشیم. بهرهوری دیدگاه ضعیفی از کار دانش ارائه میدهد و در اندازهگیری خود همواره گریزان بوده است.
«مطمئناً هیچ چیز به اندازه انجام دادن با کارایی زیاد کاری که اصلاً نباید انجام شود، بیفایده نیست.» - پیتر دراکر، ۱۹۶۳.
دور انداختن روشهای خوب
قبل از اینکه به بهرهوری وسواس پیدا کنیم، برخی از شیوههای اساسی وجود داشت که صنعت نرمافزار آنها را بسیار ارزشمند میدانست. یکی از این موارد بازسازی است. هنگامی که به طور مداوم کد خود را بازبینی میکنید تا اجزا را به طور سست به هم متصل نگه دارید و اطمینان حاصل کنید که مفاهیم را فقط یک بار تعریف میکنید، سیستمهای قابل اعتمادتری میسازید. اگر به دلیلی مشابه تغییر میکردند، آنها را با هم نگه میداشتید و اگر محرکهای متفاوتی برای تغییر داشتند، آنها را از هم جدا میکردید.
قفسه کتاب من زیر بار وزن ادبیات طراحی نرمافزار توسط کنت بک، امیلی باخ، مارتین فاولر، رابرت سی. مارتین، مایکل فیدرز، ربکا پارسونز، استیو مککانل و دیگران به سختی تحمل میکند. این کتابها حاوی تکنیکها و شیوههای ماندگاری هستند که برای موفقیت نرمافزار در درازمدت حیاتی هستند. دستیاران کدنویسی اصول توسعه نرمافزار را تغییر نمیدهند.
اگر سرعت تغییر را افزایش دهیم، باید با همگام شدن با ساختار داخلی نرمافزار، این را جبران کنیم. به عبارت دیگر، برای اینکه این امر منجر به یک استراتژی موفق توسعه نرمافزار بلندمدت شود، باید بتوانیم با همان سرعتی که کد را تغییر میدهیم، بازسازی کنیم.
اما گزارش نشان میدهد که در حال حاضر اینطور نیست.
فعالیت بازسازی با استفاده از دستهای از تغییرات به نام "کد منتقل شده" ردیابی میشود. این جایی است که منطق اساسی یکسان باقی میماند اما برای بهبود طراحی کد جابجا شده است. این شامل الگوهای کلاسیک بازسازی مانند "استخراج متد" یا "تغییر نام متغیر" است، که معمولاً توسط ابزارهای توسعهدهنده خودکار میشوند تا تضمین کنند که بازسازیهای ایمنی هستند (ناگفته نماند که عمل توسعه مبتنی بر آزمون باید به این معنی باشد که آزمایشهای شما هرگونه تغییر رفتاری تصادفی را تشخیص میدهند).
از سال ۲۰۲۱، نسبت تغییرات بازسازی از ۲۴٪ به زیر ۱۰٪ کاهش یافته است. در همان زمان، تعداد خطوط کد کپی/پیست شده، یا تکرار، از زیر ۱۰٪ به نزدیک به ۱۵٪ افزایش یافته است.
درس خیلی دیر میرسد
به یاد سازمانی افتادم که در آن با موفقیت یک فرآیند آشفته و شکننده را با تحویل مداوم جایگزین کردم. شیوههای کلیدی نصب شده، اتوماسیون تست، اتوماسیون استقرار و یک سیستم نظارت و هشدار قوی بودند. ترکیب این ابزارها به طور چشمگیری قابلیت اطمینان را بهبود بخشید و سطح اعتماد بین توسعهدهندگان و ذینفعان تجاری را افزایش داد.
پس از رفتن من، تیم تصمیم گرفت که مدیریت دادههای تست یک کار نامطلوب است. آنها اسکریپت پایگاه داده را که در محیطهای تست اجرا میشد تا دادهها را به حالت شناخته شده بازنشانی کند، حذف کردند. برای ماههای متمادی، تستهای یکپارچهسازی همچنان کار میکردند و اگر هیچکس به صورت دستی دادههای تست را برای رکورد تستی که برای تست یکپارچهسازی پیکربندی شده بود، تغییر نداده بود، به کار خود ادامه میدادند.
هنگامی که دادههای تست خراب شدند، تیم با یک انتخاب سخت مواجه شد. آنها میتوانستند اسکریپت مدیریت دادههای تست را دوباره ایجاد کنند و آن را به روز کنند تا با تمام تغییرات پایگاه دادهای که ایجاد کرده بودند کار کند. از طرف دیگر، میتوانستند تستهای ناموفق را حذف کنند. تحت فشار برای ارائه ویژگیها (و حفظ "بهرهوری")، تیم تستها را حذف کرد.
حذف تستها هیچ تأثیر فوری ندارد. این ویژگی برای مدتی به کار خود ادامه داد، اما در نهایت خطاها معرفی شدند و سپس به یک موضوع تکراری تبدیل شدند.
این مشکلی است که هنگام انتخاب بهرهوری بر پایداری بلندمدت ایجاد میشود. مدت زیادی طول میکشد تا متوجه شوید که خسارتی وارد شده است. هنگامی که تأثیر تصمیمات گذشته آشکار میشود، اغلب برای کاهش آن خیلی دیر است.
پرواز در مقابل سقوط
دستیاران کد هوش مصنوعی شرایط عالی را برای سرعت نرمافزار سهمیوار فراهم میکنند. درست مانند پروازهای هواپیمای بدون گرانش، که از یک منحنی سهمی برای ایجاد احساس بیوزنی استفاده میکنند، دستیاران کد باعث میشوند باور کنیم که در حال پرواز هستیم در حالی که در واقع در حال دنبال کردن یک مسیر بالستیک در سقوط آزاد هستیم.
برای اینکه هوش مصنوعی به طور پایدار بهرهوری شما را افزایش دهد، نمیتوانید اجازه دهید کیفیت کد شما را دیکته کند.