با شمارهٔ موبایل وارد شوید تا بتوانید اشتراک بخرید و در گفتگو شرکت کنید.

مرور The Pragmatic Engineer · قسمت 1 از 1

کدنویسی با هوش مصنوعی سریع‌تر می‌شود. تحویل نرم‌افزار هم؟

۲:۵۲رایگان

با یک مثال از فروشگاه آنلاین، فرق سرعت نوشتن کد و سرعت رساندن تغییر به کاربر را بررسی می‌کنیم. نتیجهٔ آزمایش محدود مِتِر و سه سنجه برای مقایسه در تیم خودمان.

شنیدن این قسمت

رایگان

قسمت‌های این مجموعه

1 قسمت
  1. 1کدنویسی با هوش مصنوعی سریع‌تر می‌شود. تحویل نرم‌افزار هم؟این قسمت

دربارهٔ این قسمت

با یک مثال از فروشگاه آنلاین، فرق سرعت نوشتن کد و سرعت رساندن تغییر به کاربر را بررسی می‌کنیم. نتیجهٔ آزمایش محدود مِتِر و سه سنجه برای مقایسه در تیم خودمان.

توضیحات کامل و منابع

با یک مثال از فروشگاه آنلاین، فرق سرعت نوشتن کد و سرعت رساندن تغییر به کاربر را بررسی می‌کنیم. نتیجهٔ آزمایش محدود مِتِر و سه سنجه برای مقایسه در تیم خودمان.

این قسمت تولید مستقل شب‌گفتار است. صدا با هوش مصنوعی ساخته شده است.

منابع

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