ترانسفورماتورها: 50٪ سریعتر، زمان خاموشی صفر. آیا کد قدیمی شما مانع شما می شود؟

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

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

کد قدیمی می تواند هر بخش از یک کسب و کار را کند کند. انتشار بیشتر طول می کشد، تغییرات کوچک باگ های غیرمنتظره ایجاد می کند و توسعه دهندگان جدید به هفته ها زمان نیاز دارند تا نحوه عملکرد سیستم را درک کنند. جایگزینی کل پلت فرم ممکن است جذاب به نظر برسد، با این حال یک بازنویسی بزرگ می تواند عملیات روزانه را مختل کند و خطرات جدیدی ایجاد کند. من رویکرد تدریجی را ترجیح می دهم. تیم محصول را در حال اجرا نگه می دارد و در عین حال پایه کد را در مراحل کنترل شده بهبود می بخشد. ### با یک نمای واضح از سیستم فعلی شروع کنید قبل از تغییر کد، بخش‌هایی را که بیشترین اهمیت را دارند نقشه‌برداری می‌کنم: - عملکردهای تجاری اصلی - سرویس‌های خارجی و APIها - اتصالات پایگاه داده - مراحل استقرار - مناطق با نقص‌های مکرر - ماژول‌هایی که آزمایش آن‌ها سخت است - ویژگی‌هایی که مشتریان هر روز استفاده می‌کنند این بررسی به تیم کمک می‌کند مشکلات فوری را از کدهای قدیمی‌تر که هنوز به خوبی کار می‌کنند جدا کند. یک سرویس صورتحساب که پرداخت‌ها را پردازش می‌کند، باید بیشتر از یک گزارش داخلی که یک بار در ماه استفاده می‌شود، مورد توجه قرار گیرد. سن کد به تنهایی به من نمی گوید چه چیزی را تغییر دهم. تأثیر کسب و کار، ریسک شکست و تلاش تعمیر و نگهداری راهنمای بهتری را ارائه می دهد. ### یک هدف نوسازی کوچک تعیین کنید وقتی تیم نقطه شروع روشنی را انتخاب کند، بهبود پایگاه کد آسان‌تر می‌شود. یک هدف مفید ممکن است این باشد: - کاهش مراحل استقرار برای یک سرویس - افزودن تست‌های خودکار به یک ماژول پرخطر - جایگزینی یک کتابخانه پشتیبانی‌نشده - انتقال یک تابع به یک سرویس جداگانه - بهبود ثبت خطا برای یک گردش کار کلیدی - ارتقا بخشی از برنامه به یک نسخه زبان پشتیبانی‌شده اهداف کوچک اندازه‌گیری پیشرفت را آسان‌تر می‌کنند. آنها همچنین به تیم روشی امن برای یادگیری قبل از دست زدن به بخش‌های بزرگ‌تر سیستم می‌دهند. ### محافظت از کد با تست‌ها مدرن‌سازی بدون آزمایش می‌تواند شبیه تغییر یک ماشین در حین کار باشد. تیم ممکن است ساختار را بهبود بخشد و همچنان گردش کار مشتری را بشکند. من معمولاً با آزمایش هایی درباره با ارزش ترین رفتار شروع می کنم. این تست ها نیازی به پوشش هر خط ندارند. آنها باید کاری را که برنامه باید به انجامش ادامه دهد را تأیید کنند. برای یک سیستم سفارش آنلاین، آزمایش‌های مفید ممکن است بررسی کنند که: - مشتری می‌تواند کالایی را به سبد خرید اضافه کند - سطح موجودی انبار پس از یک سفارش تأیید شده تغییر می‌کند - پرداخت ناموفق باعث ایجاد سفارش کامل نمی‌شود - بازپرداخت وضعیت سفارش را به‌روزرسانی می‌کند - تأیید سفارش به آدرس ایمیل صحیح می‌رسد. آنها رفتار فعلی را قبل از تغییر کد داخلی تیم ثبت می کنند. این رویکرد زمانی مفید است که اسناد محدود باشد و برنامه موجود حاوی سال‌ها قوانین تجاری باشد. ### بهبود ساختار در بخش های کوچک یک فایل بزرگ اغلب شامل چندین مسئولیت است. ممکن است ورودی ها را تأیید کند، قوانین تجاری را اعمال کند، داده ها را ذخیره کند، ایمیل بفرستد و گزارش ها را در یک مکان بنویسد. من این مسئولیت ها را یک حوزه در یک زمان جدا می کنم. فرآیند می تواند به این صورت باشد: 1. یک تابع یا ماژول را انتخاب کنید. 2. آزمایش هایی را در مورد رفتار فعلی آن اضافه کنید. 3. منطق مکرر را حذف کنید. 4. نام های بهتری به متغیرها و روش های نامشخص بدهید. 5. قوانین کسب و کار را از پایگاه داده یا کد رابط کاربری جدا کنید. 6. مجموعه آزمایشی را اجرا کنید. 7. تغییر را از طریق فرآیند زایمان طبیعی آزاد کنید. این روش مرور هر تغییر را آسان می کند. همچنین شناسایی منبع مشکل را آسان‌تر می‌کند اگر نسخه‌ای مطابق انتظار عمل نکند. ### اجزای قدیمی را با یک مسیر تدریجی جایگزین کنید. بازنویسی کامل اغلب با شکست مواجه می‌شود، زیرا تیم ماه‌ها را صرف ساختن یک جایگزین می‌کند در حالی که سیستم قدیمی همچنان به تغییر ادامه می‌دهد. نیازمندی‌ها تغییر می‌کنند، قوانین پنهان ظاهر می‌شوند و نسخه جدید دامنه آن افزایش می‌یابد. جایگزینی تدریجی این شکاف را کاهش می دهد. یک الگوی عملی قرار دادن یک سرویس جدید در کنار ماژول قدیمی است. درخواست‌های جدید می‌توانند به سرویس جدید منتقل شوند در حالی که مسیر قدیمی برای مواردی که جابجا نشده‌اند در دسترس است. تیم می تواند نتایج را مقایسه کند، خطاها را بررسی کند، و مسیر جدید را پس از ثابت شدن پایداری آن گسترش دهد. به عنوان مثال، یک شرکت ممکن است به‌روزرسانی‌های نمایه مشتری را قبل از انتقال سابقه حساب منتقل کند. هر قسمت چک و طرح انتشار خود را دارد. در حالی که انتقال پیشرفت می کند، کاربران همچنان به محصول دسترسی دارند. ### ایمن نگه داشتن تغییرات پایگاه داده کار پایگاه داده مستحق برنامه ریزی دقیق است زیرا کد برنامه و داده های ذخیره شده به یکدیگر بستگی دارند. من از تغییراتی اجتناب می‌کنم که نسخه‌های قدیمی و جدید برنامه را به استفاده از فرمت‌های داده مختلف در یک لحظه نیاز دارد. انتقال ایمن‌تر اغلب از این الگو پیروی می‌کند: - فیلد یا جدول جدید را اضافه کنید - اجازه دهید هر دو نسخه برنامه ساختار قدیمی را درک کنند - داده‌های موجود را در دسته‌های کوچک کپی کنید - شروع به نوشتن در ساختار جدید کنید - خواندن از ساختار جدید پس از تایید - حذف ساختار قدیمی پس از اینکه دیگر مورد نیاز نیست تیم باید سرعت مهاجرت، سوابق ناموفق، بارگذاری پایگاه داده و عدم تطابق داده‌ها را کنترل کند. یک طرح پشتیبان باید قبل از شروع مهاجرت آزمایش شود، نه در طول یک حادثه. ### کنترل انتشارها را آسان‌تر کنید، اگر استقرار هر نسخه دشوار باشد، یک پایگاه کد مدرن همچنان خطر ایجاد می‌کند. من به دنبال راه‌هایی برای تکرارپذیر کردن تحویل می‌گردم: - پیکربندی ذخیره خارج از کد - استفاده از بررسی‌های ساخت خودکار - اجرای آزمایش‌ها در طول هر درخواست کشش - ایجاد بسته یکسان برای هر محیط - مستند نگه داشتن مراحل استقرار - استفاده از پرچم‌های ویژگی برای تغییراتی که نیاز به انتشار تدریجی دارند - حفظ فرآیند بازگشت آزمایش شده - پرچم‌های ویژگی می‌توانند استقرار را از انتشار عمومی جدا کنند. کد می تواند در تولید وجود داشته باشد در حالی که دسترسی به کاربران داخلی یا گروه کوچکی از مشتریان محدود می شود. این به تیم زمان می‌دهد تا تغییرات را قبل از باز کردن آن برای همه تماشا کند. ### اضافه کردن گزارش های نظارت مفید و معیارها باید به پاسخ به سوالات خاص کمک کند. حجم بالای داده با قابلیت مشاهده مفید یکسان نیست. برای هر منطقه مدرن، می خواهم بدانم: - آیا خدمات موجود است؟ - درخواست ها چقدر طول می کشد؟ - هر چند وقت یک بار درخواست ها با شکست مواجه می شوند؟ - کدام خطاها بر کاربران تأثیر می گذارد؟ - آیا فراخوانی پایگاه داده روند کار را کند می کند؟ - آیا نسخه جدید نتایج کسب و کار را تغییر داد؟ یک سرویس پرداخت ممکن است برای تراکنش‌های ناموفق و پاسخ‌های تاخیری به هشدار نیاز داشته باشد. یک ویژگی جستجو ممکن است به داده هایی در مورد نتایج خالی و زمان پاسخگویی نیاز داشته باشد. بهترین نظارت نشان دهنده نحوه استفاده مردم از محصول است. ### مردم را درگیر نگه دارید نوسازی کد فقط یک کار فنی نیست. مدیران محصول، تیم‌های پشتیبانی، کارکنان عملیات و توسعه‌دهندگان ممکن است هر یک بخش متفاوتی از سیستم را بشناسند. سوابق پشتیبانی می‌توانند مشکلاتی را که معیارهای کد از دست می‌دهند، آشکار کنند. یک توسعه‌دهنده ممکن است روش کندی را ببیند، در حالی که یک نماینده پشتیبانی می‌داند که مشتریان یک فرم را زمانی که زمان زیادی طول می‌کشد، رها می‌کنند. از تیم‌ها می‌خواهم که به اشتراک بگذارند: - کدام جریان‌های کاری باعث شکایات مکرر می‌شوند - کدام کارهای دستی وقت کارکنان را می‌گیرد - کدام نسخه‌ها درخواست‌های پشتیبانی ایجاد می‌کنند - کدام یکپارچه‌سازی‌ها نگهداری آنها دشوار است - کدام قوانین تجاری نوشته نمی‌شوند این جزئیات به تیم کمک می‌کند کاری را انتخاب کند که هم کد و هم محصول را بهبود می‌بخشد. ### از معیار موفقیت عملی استفاده کنید. اقدامات مفید عبارتند از: - زمان لازم برای انتشار یک تغییر کوچک - تعداد نقص‌ها پس از استقرار - زمان صرف شده برای تشخیص حوادث - پوشش آزمایشی برای گردش‌های کاری حیاتی - فرکانس بازگشت استقرار - زمان صرف شده توسط برنامه‌نویس برای رفع مشکلات تکراری - زمان پاسخگویی برای اقدامات کلیدی مشتری هدف این نیست که هر فایلی جدید به نظر برسد. هدف ایجاد سیستمی است که تیم بتواند با ریسک کمتر و تلاش کمتر آن را تغییر دهد. ### یک مسیر ثابت بهتر از یک بازنویسی چشمگیر کار می کند. این تیم سیستم فعلی را مطالعه می‌کند، از رفتارهای کلیدی با آزمایش‌ها محافظت می‌کند، یک منطقه را در یک زمان بهبود می‌بخشد و از نظارت برای هدایت تصمیم بعدی استفاده می‌کند. یک محصول پایدار نیازی به توقف ندارد در حالی که کد آن بهبود می یابد. با نسخه های کوچک، تغییرات ایمن پایگاه داده، و برنامه بازگشت، تیم می تواند پایگاه کد را مدرن کند و در عین حال به خدمات رسانی به مشتریان ادامه دهد. ما تجربه گسترده ای در زمینه صنعت داریم. برای مشاوره حرفه ای با ما تماس بگیرید: امی وو: amy.wu@ihuagroup.com/WhatsApp +8613612662976.

منابع مارتین فاولر، 2004، StranglerFigApplication مایکل سی پر، 2004، کار موثر با کد میراث نیکول فورسگرن جز فروتن و ژن کیم، 2018، شتاب دادن به ژن کیم کوین بهر و جورج اسپافورد، 2013، فینیکوس، دیوید، فینیکوس و دیوید تحویل رابرت سی مارتین، 2017، معماری پاک