عادات کیفیت نرم افزار و هوش مصنوعی

کیفیت نرم افزار به عادت ها بستگی دارد. کیفیت پست های ما به کیفیت عادت های ما بستگی دارد. هیچ کس نسخه پر از نقص را نمی فرستد زیرا کیفیت نمی خواهد. آنها احتمالاً به این دلیل آن را می فرستند که رفتارهای روزانه کوچکی که مانع از آن می شد – عادت های کوچک – بی سر و صدا متوقف شد. یک تست از دست رفته، یکی روابط عمومی تایید شده بدون خواندن، یکی “بعداً آن را برطرف خواهیم کرد”.

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

عادت های کوچک

عادات کوچک (یا اتمی) به اندازه کافی کوچک هستند تا شما را از یک روز بد عبور دهند و آنقدر ارزان هستند که بدون فکر کردن به آن تکرار کنید. هیچ کدام به تنهایی چشمگیر نیستند. دقیقاً به همین دلیل است که آنها واحدی هستند که هر چیز دیگری از آن ساخته شده است.

نوشتن و تست:

• نوشتن تست ناموفق قبل از نوشتن پچ، نه بعد از آن
• بررسی حروف خالی، لیست خالی، رشته خالی، تهی، صبر کنید
• عبارتی بنویسید که در واقع رفتار را بررسی کند
• حذف تستی که دیگر هیچ چیز معنی‌داری را آزمایش نمی‌کند، به‌جای اینکه آن را به‌عنوان تزیین رها کنیم
• اجرای بسته کامل به صورت محلی قبل از فشار دادن، نه فقط فایلی که روی آن ضربه زده اید
• افزودن یک تست رگرسیون در همان روز رفع اشکال، نه “وقتی زمان وجود دارد”

بررسی کد و همکاری:

• در واقع خواندن یک تفاوت خط به خط قبل از تأیید آن
• وقتی چیزی را متوجه نشدید به جای سرکوب آن، نظر بدهید
• در هر روابط عمومی که یک تماس شبکه یا دیسک اضافه می کند، پرسیدن “اگر این تماس با شکست مواجه شود چه اتفاقی می افتد”.
• درخواست بازبینی دوم برای هر چیزی که مربوط به احراز هویت، پرداخت‌ها یا انتقال داده باشد بدون اینکه به او گفته شود
• قبل از اینکه از شخص دیگری بخواهید یک بار تفاوت های خود را مرور کنید

نامگذاری، ساختار و مستندات:

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

نظم و انضباط روزانه:

• قبل از جستجوی پیام خطا را به طور کامل بخوانید
• بازتولید یک باگ قبل از اینکه ادعا شود رفع شده است
• علامت گذاری یک تست ناپایدار در اولین باری که آن را می بینید به جای اجرای مجدد آن تا زمانی که موفق شود
• با صدای بلند گفتن “نمی دانم چرا این کار می کند” به جای اینکه آن را کنار هم بگذاریم

عادت های بزرگ

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

• یک مجموعه آزمایشی که به اندازه کافی قابل اعتماد است که یک ساخت قرمز در واقع ادغام را هر بار، بدون فرهنگ لغو دستی متوقف می کند.
• پس از مرگ بی عیب و نقص که تغییرات واقعی ایجاد می کند، نه فقط سندی که هیچ کس دوباره آن را بازخوانی نمی کند
• یک دروازه با کیفیت در خط لوله انتشار که به جای هدایت مجدد تحت فشار ضرب الاجل، انتشار را مسدود می کند
• یک برنامه حضوری که فرهنگ آزمایش و بررسی را به استخدام‌کنندگان جدید منتقل می‌کند، نه فقط دسترسی به مخزن و دعوت به Slack
• بررسی‌های معماری که قبل از اینکه «این کار را انجام می‌دهد» می‌پرسند «چگونه شکست می‌خورد» و «چه اتفاقی می‌افتد تحت بار ۱۰ برابری»
• کاتالوگ زنده از تصمیمات معماری و استدلال پشت آنها، به اندازه کافی جاری است که مردم در واقع به آن مراجعه کنند.
• نظارت بر تولید و تنظیم هشدار به اندازه کافی تنظیم شده است که در یک تماس به جای خاموش کردن هشدارها به آنها اعتماد می کند.
• فرآیند استهلاک و بدهی فنی با بودجه واقعی و سررسید واقعی
• مهندسی آشوب یا تزریق سیستماتیک شکست به طور معمول انجام می شود، نه یک بار پس از یک حادثه بد
• فرهنگی که در آن مطرح کردن نگرانی‌های مربوط به کیفیت حتی زمانی که انتشار را به تأخیر می‌اندازد پاداش می‌گیرد

چقدر عادت های کوچک بزرگ می شوند

یک عادت بزرگ همان چیزی است که یک عادت کوچک بعد از چند صد تکرار و کمی داربست سازمانی اطراف آن به نظر می رسد. چند مثال خاص:

• نوشتن یک آزمون واحد با هر تغییر، به طور مداوم، در طول یک سال، چیزی است که مجموعه آزمون واحد واقعی از آن تشکیل شده است. مجموعه‌های آزمایش واحد اغلب، روابط عمومی پس از روابط عمومی، به دلیل عادت اتمی عدم ادغام منطق آزمایش‌نشده، انباشته می‌شوند. مجموعه آزمایشی با حفظ بسیاری از تست‌های مجزا و قابل اعتماد بودن در برابر رگرسیون محافظت می‌کند و به اندازه کافی قابل اعتماد است که یک شکست مانع ادغام می‌شود.
• گذاشتن یک نظر بازبینی صادقانه هنگامی که چیزی نامشخص است، که در صدها PR تکرار می شود، در نهایت فرهنگ بررسی درست را ایجاد می کند. فرهنگی که در آن مهندسان جوان از پرسیدن سؤالات احساس امنیت می کنند و مهندسان ارشد احساس می کنند موظف هستند با دقت به آنها پاسخ دهند. هیچ سند سیاستی این را ایجاد نمی کند. این بقایای عادتی است که به اندازه کافی برای تبدیل شدن به یک عادت انجام شده است.
• ثبت این که چرا یک باگ در یک مکان مشترک رخ می دهد، چیزی است که یک پس از مرگ واقعاً بی عیب و نقص است. چند ورودی اول فقط یادداشت هستند. هنگامی که به اندازه کافی از این موارد جمع آوری می شوند، به آنها ارجاع داده می شود و گهگاهی بازخوانی می شوند، تبدیل به یک خاطره سازمانی می شوند که تیم قبل از انجام دوبار اشتباه دسته بندی با آن مشورت می کند.
• به روز رسانی یک سند یا نوشتن یک یادداشت تصمیم کوتاه در هر بار تصمیم گیری، چیزی است که در نهایت به یک رکورد زنده معماری تبدیل می شود. این چیزی است که استخدام‌کنندگان جدید می‌توانند بخوانند تا نه تنها بفهمند که سیستم چه کار می‌کند، بلکه بفهمند چرا آن‌طور که هست طراحی شده است.
• علامت گذاری یک آزمایش ناپایدار به جای اجرای مجدد آن چیزی است که، ضرب در تیم و سال، تفاوت بین خط لوله CI که مردم به آن اعتماد دارند و خط لوله ای است که مردم مسیریابی می کنند. عادت بزرگ – دروازه‌ای با کیفیت که در واقع ما را در مورد انتشارها آگاه می‌کند – نمی‌تواند وجود داشته باشد مگر اینکه افراد کافی عادت کوچک را به طور مداوم انجام دهند.

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

ترکیبی از عادات – هر دو طرف

تیمی که برای دو سال متوالی یک PR نهایی بیشتر از قبل می نویسد، در نهایت به جایی کاملاً متفاوت از تیمی که یکی کمتر می نویسد، می رسد. هیچ تیمی نمی تواند روزی را مشخص کند که کیفیت به نقطه قوت یا ضعف تبدیل شد. این یک خطای گرد کردن هر روز و تعدادی از مشتریان ناراضی در یک سال است.

نسخه عادت بد به همان اندازه قابل اعتماد ترکیب می شود. “ما بعداً آزمایش را اضافه خواهیم کرد” بعداً اتفاق می افتد هرگز نمی آید. اینگونه مجموعه های آزمایشی ساخته می شوند که هیچ کس کاملاً به آنها اعتماد ندارد. همچنین اینگونه است که یک CI قرمز که نادیده گرفته می شود به درب باکیفیتی تبدیل می شود که به جای حل آنها مشکلاتی را ایجاد می کند. سازمان اکنون بر این باور است که کنترل کیفیت دارد که ندارد – و این شکاف باور خطرناک است.

جایی که هوش مصنوعی واقعا کمک می کند

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

جایی که خطرناک می شود

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

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

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

ترنس تائو در مورد هوش مصنوعی در ریاضیات

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

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

بیایید یک لحظه از منظر مهندسی به این موضوع فکر کنیم. آیا مشکلات باز و درک ما از آنها یکی از دلایل اصلی نوآوری مهندسی نیست؟ مبارزه برای سازگار و در دسترس نگه داشتن سیستم های توزیع شده منجر به قضیه CAP شد. با درک قضیه CAP، پروتکل های اجماع مانند Paxos و Raft در حال حاضر در یک زیرساخت قابل اعتماد وجود دارند. تلاش برای اجرای نرم افزار در مقیاسی که هیچ تیمی نتواند به صورت دستی درباره آن استدلال کند، منجر به هماهنگی کانتینرها و شبکه های خدماتی شد. چنین مشکلات کشف شده منجر به ایجاد مهندسی قابلیت اطمینان سایت به عنوان یک رشته جداگانه شد. دشواری اعتماد به کدی که هرگز نمی‌توان آن را به طور کامل آزمایش کرد، باعث ایجاد تست مبتنی بر ویژگی، فازبندی و ابزارهای تأیید رسمی مانند TLA+ شد. درک اینکه آزمایش همه چیز اغلب بیهوده و ناکارآمد است (در صورت امکان) آزمایش نرم افزار را به عنوان یک رشته طراحی کرد. مهندسی آشوب به این دلیل وجود دارد که یک تیم با «سیستم‌های ما به روش‌هایی که نمی‌توانیم پیش‌بینی کنیم خراب می‌شوند» به‌عنوان مشکلی که ارزش زندگی در آن را دارد، برخورد می‌کند، نه به‌عنوان مشکلی که بدون درک راه‌حل بلافاصله حل می‌شود.

مشکلات نرم افزاری و کیفیت پیدا شد

نسخه ما از “مسائل باز” حوادث تولید، اشکالات سخت برای بازتولید، و بخش های ناخوشایند است که در آن هیچ کس کاملاً مطمئن نیست که چرا سیستم به این شکل عمل می کند. از لحاظ تاریخی، این شکاف‌ها مسیر آهسته را می‌بندند: کسی شکست را ردیابی می‌کند، یک مدل ذهنی می‌سازد، آن را یادداشت می‌کند و قضاوت جمعی تیم کمی بهتر می‌شود. این نسخه ما از “ساختار مجاور نقشه‌برداری شده در حالی است که مسدود شده است” – یادداشت‌های اشکال‌زدایی، راه‌حلی که به یک الگوی طراحی تبدیل شد، مهندس شش ماه بعد گفت: “اوه، من قبلاً این شکل را دیده‌ام.”

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

برای دست نخورده نگه داشتن حلقه، می توانیم:

• با یک راه حل ایجاد شده توسط هوش مصنوعی مانند روابط عمومی یک مهندس جوان برخورد کنید، نه قضاوت یک مهندس ارشد – یکی از مسئولین هنوز به قول خودش توضیح می دهد که چرا قبل از ادغام کار می کند.
• اجازه ندهید سرعت هوش مصنوعی بی سر و صدا کالبد شکافی را لغو کند – اگر یک تصادف واقعی بود، کسی همچنان اتفاقات رخ داده را می نوشت، حتی اگر اصلاح آن به جای دو روز ده دقیقه طول بکشد.
• از هوش مصنوعی برای فشرده کردن بخش مکانیکی حلقه عادت – یک داربست، یک الگو – استفاده کنید، اما به تشخیص “چرا این واقعاً شکست خورد” یک تمرین انسانی را ادامه دهید، حداقل تا زمانی که توضیح هوش مصنوعی تأیید شود، نه اینکه فقط قابل قبول باشد.
• از شکاف اعتقادی آگاه باشید: یک خط لوله سبز که تا حدی بر روی اصلاحات اثبات نشده هوش مصنوعی ساخته شده است ممکن است شبیه به خط لوله ای باشد که بر اساس اصلاحات قابل درک ساخته شده است.
• هنگام سوار شدن به هواپیما، مهندسین جدید را در معرض تلاش های ناموفق قرار دهید، نه فقط تفاوت های نهایی با هوش مصنوعی – تلاش های ناموفق هنوز جایی هستند که قضاوت می شود.

تکمیل

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

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