جگوار وب.

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

1. نقشه های گوگل بارگیری نمی شود

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

عالی نیست، اما نگران نباشید، تعمیر آن آسان است.

این به دلیل تغییر در مدل قیمت گذاری گوگل در سال 2018 اتفاق می افتد. به طور خلاصه، هر نقشه وب سایت باید به یک "پروژه" تعلق داشته باشد. هر پروژه به یک کلید API و همچنین یک حساب صورتحساب مرتبط با آن نیاز دارد.

چطوری میشه اینو تعمیر کرد؟

در حالی که وب‌سایت‌های زیادی وجود دارند که راهنمای نحوه دریافت کلید API خود را ارائه می‌دهند، مطمئن‌ترین شرط این است که راهنمای خود Google را بررسی کنید تا مطمئن شوید اطلاعات قدیمی را دریافت نمی‌کنید. شما می توانید آن را اینجا پیدا کنید.

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

2. PHP نسخه 7 (فقدان آن) و وردپرس را نمی توان به روز کرد

نسخه 7 پی اچ پی چندین سال است که عرضه شده است، اما جایگزین های هاست اشتراکی معمولاً برای ارائه گزینه های به روز رسانی برای آن کمی کند هستند. علاوه بر ارائه دهندگان هاست، بسیاری از صاحبان وب سایت در مورد امکان به روز رسانی و معنای آن اطلاعی ندارند.

PHP یک زبان برنامه نویسی است که برای توسعه وب استفاده می شود. به دلیل منبع باز بودن و شروع سریع پروژه های کوچک تا متوسط ​​به طور گسترده استفاده می شود. همچنین گاهی اوقات تنها گزینه در محیط میزبانی مشترک است. در نهایت این زبانی است که برای محبوب ترین CMS وردپرس در جهان استفاده می شود.

اگر نسخه قدیمی PHP را اجرا می کنید، علاوه بر اینکه توسعه دهندگان ناراضی را دریافت می کنید، عملکرد و امنیت را از دست می دهید. فقط ارتقاء از PHP 5 به PHP 7 می تواند سرعت وب سایت مبتنی بر PHP شما را تا حد زیادی افزایش دهد.

اگر از یک سایت وردپرسی استفاده می کنید و نسخه بسیار قدیمی PHP (مانند PHP 5.3) را اجرا می کنید، دیگر حتی نمی توانید وردپرس را به عنوان PHP 5.6 ارتقا دهید. حتی برای ارتقاء مورد نیاز است (7.2 توصیه می شود). اگر نمی توانید وردپرس را به روز نگه دارید، سایت خود را در معرض خطر هک شدن قرار می دهید.

در حالی که اکثر سایت‌ها به PHP 7 به‌روزرسانی شده‌اند، طبق آمار در wordpress.org ، تقریباً 25٪ از تمام سایت‌های وردپرس هنوز PHP 5 را اجرا می‌کنند.

چطوری میشه اینو تعمیر کرد؟

اگر به cPanel کنترل پنل پرکاربرد دسترسی دارید، "PHP" را جستجو کنید تا "Select PHP Version" را پیدا کنید.

روی آن کلیک کنید و در آنجا نسخه PHP مورد نظر خود را انتخاب کنید.

اگر نوع دیگری از کنترل پنل دارید، همچنان سعی کنید به دنبال تنظیمات "نسخه PHP" باشید. اگر آن را پیدا نکردید - با ارائه دهنده میزبانی خود تماس بگیرید که باید به شما کمک کند.

توجه: قبل از اینکه چیزی را تغییر دهید، به مشکل 3 در زیر نگاه کنید!

3. به روز رسانی PHP 7 سایت من را خراب کرد

pgrading به PHP 7 عالی است و اگر قبلاً انجام نشده است باید این کار را انجام دهید.

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

مشکل

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

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

چطوری میشه اینو تعمیر کرد؟

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

اگر افزونه نیست، ممکن است موضوعی باشد که باعث این مشکل شده است، بنابراین در صورت امکان، تم دیگری را امتحان کنید.

اگر کدنویسی سفارشی زیادی در سایت خود دارید یا یک برنامه وب سفارشی دارید، باید با توسعه دهندگان تماس بگیرید تا از آنها بخواهید کد را برای سازگاری آن به روز کنند.

خبر خوب این است که چنین به‌روزرسانی‌هایی معمولاً سریع و آسان هستند.

4. ایمیل از فرم های وب سایت من ارسال نمی شود

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

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

چطوری میشه اینو تعمیر کرد؟

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

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

5. لینک های خروجی خراب هستند

این مورد کوتاه و آسان است. هنگامی که می خواهید به وب سایت دیگری پیوند دهید، لطفاً به یاد داشته باشید که از "https://" (یا "http://") در پیوند برای کامل کردن آن استفاده کنید - در غیر این صورت به عنوان پیوندی نسبی به یک صفحه در داخل تفسیر می شود. 

به عنوان مثال، فرض کنید می خواهیم به صفحه توییتر خود لینک دهیم. URL کامل https://twitter.com/jaguarweb_ir است.

اگر فقط twitter.com/jaguarweb_ir یا www.twitter.com/jaguarweb_ir را در پیوند قرار دهیم، به این صورت عمل می کند . نه چندان خوب می باشد. بلکه شما باید پروتکل https یا http را حتماً در URL وارد کنید.

چطوری میشه اینو تعمیر کرد؟

با URL کامل، همانطور که در نظر گرفته شده است کار خواهد کرد .

گفته می شود، برخی از مدیران محتوا این کار را برای شما انجام می دهند - فقط مراقب باشید که این کار را نکنید!

6. پاورقی پرواز

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

ممکن است عملکرد مهمی نباشد، اما جزئیات واضحی است که وقتی پاورقی در پایین می‌ماند، جلوه کلی بهتری به سایت شما می‌دهد.

چطوری میشه اینو تعمیر کرد؟

مبارزه با پاورقی پرواز

"Flying Footer" پاورقی است که همیشه در پایین صفحه قرار نمی گیرد. این مقاله راه حل های مختلفی در مورد نحوه قرار دادن پاورقی در پایین یک طرح ارائه می دهد.
پاورقی هایی که در پایین صفحه قرار نمی گیرند، یکی از نگرانی های من در مورد طراحی و چیدمان وب است.

"Flying Footers" در طرح‌بندی‌هایی اتفاق می‌افتد که قوانین CSS کافی برای قرار دادن پاورقی در پایین همیشه وجود ندارد. به عنوان مثال، وقتی محتوای کافی در صفحه وجود ندارد که بتواند 100٪ ارتفاع صفحه را اشغال کند، ممکن است پاورقی قبل از پایان صفحه به پایان برسد. این معمولاً در صفحه‌های بزرگتر هنگام نمایش صفحاتی که حاوی محتوای کمتری هستند رخ می‌دهد.

مثال ها
نمونه ای از یک صفحه کوتاه که با استفاده از پرفروش ترین پوسته وردپرس آوادا در یک صفحه نمایش بزرگ نمایش داده می شود.

صفحه کوتاهی که با استفاده از پرفروش ترین پوسته وردپرس آوادا بر روی صفحه نمایش بزرگ نمایش داده می شود.

مثال دیگر این دیدگاه از بزرگترین شرکت خبری و رسانه ای خدمات عمومی سوئد SVT است.

و نمونه دیگری از بزرگترین سایت خبری تجاری سوئد، di.se.

آیا این واقعاً مهم است؟
به نظر من اصلاح جزئیاتی از این دست با پوشیدن یک پیراهن اتو شده در یک جلسه مهم قابل مقایسه است، زمانی که می خواهید بهترین ظاهر خود را داشته باشید. اگر با یک پیراهن چروک ظاهر شوید، دنیا به پایان نمی رسد، اما احتمالاً با پوشیدن یک پیراهن اتو شده تاثیر بهتری خواهید گذاشت.

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

محتوای پویا
اکثر وب سایت ها دارای محتوای پویا هستند. ترجیحاً ظاهر مورد انتظار طراحی یک وب سایت به طولانی یا کوتاه بودن محتوا متکی نباشد.

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

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

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

پشتیبانی از مرورگر: در همه مرورگرها پشتیبانی می شود.

اگرچه ترکیب CSS Computed Properties با یک عبارت calc() برای استفاده از آن در سناریوهایی با ارتفاع پاورقی در حال تغییر امکان پذیر است، این تکنیک ها فقط در مرورگرهای مدرن پشتیبانی می شوند. و اگر فقط برای مرورگرهای مدرن می‌سازید، این فرصت را دارید که از Flexbox یا CSS Grid نیز استفاده کنید.

به طور خلاصه
محدودیت‌های اصلی که تصمیم می‌گیرند کدام تکنیک برای هر مورد استفاده بهتر است عبارتند از:

• کدام مرورگرها باید پشتیبانی شوند؟
• آیا ارتفاع فوتر مشخص است؟
• آیا ارتفاع پاورقی تغییر می کند (مثلاً در نتیجه محتوای پاورقی پویا)؟

اگر می دانید که نیازی به پشتیبانی از اینترنت اکسپلورر ندارید، تکنیکی که بهترین پشتیبانی را دارد flexbox است که امکان تغییر ارتفاع فوتر را نیز فراهم می کند.

 

نحوه شناسایی اشکالاتی که نیاز به رفع دارند

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

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

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

کم:  

• حداقل تاثیر در استفاده از محصول.  
• محصول رفتار ناخواسته ای از خود نشان می دهد، اما استفاده عمومی تحت تأثیر قرار نمی گیرد.  
• تعداد کمی از کاربران، محصولات یا موارد نگران هستند.  
• یک ویژگی/قطعه عملکرد خراب است یا در دسترس نیست، اما یک راه حل آسان مشکل را حل می کند.  

بالا:  

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

بحرانی:  

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

برای زمینه‌های بیشتر، ارائه نمونه‌های خاص از اشکالات و شدت‌هایی که می‌خواهید آنها را در یک " برگ ارزیابی اشکال" به آزمایش‌کنندگان خود اختصاص دهید، ممکن است مفید باشد. اما لطفاً به خاطر داشته باشید که اینها دستورالعمل‌های کلی هستند. چیزی مانند اشکال محتوا/بصری که در آن تصویر بارگیری نمی‌شود، ممکن است برای یک فروشگاه تجارت الکترونیک حیاتی باشد (خریداران چیزی را که نمی‌توانند ببینند) در حالی که در یک سایت فین‌تک پایین هستند، حیاتی است.  

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

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

چند نکته و یادآوری برای اولویت بندی رفع اشکال

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

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

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

9 تکنیک برای رفع اشکالات در تولید

علیرغم بهترین شیوه ها و تلاش توسعه دهندگان، اشکالات بخشی اجتناب ناپذیر از توسعه نرم افزار هستند. بر این اساس، نقص در نرم افزار زنده نیز وجود دارد. یک اشکال - به ویژه نقص در تولید - یک مشکل است زیرا خطر از دست دادن مشتریان را به همراه دارد.

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

تیم های نرم افزاری می توانند این 9 راه را برای رفع اشکالات در تولید دنبال کنند:

1. یک فرآیند استاندارد ایجاد کنید.
2. برای رفع سریع عیوب برنامه ریزی کنید.
3. مدیریت زمان را تمرین کنید.
4. پیاده سازی معیارها
5. اولویت بندی کد آزمون
6. مهندسی آشوب را انجام دهید.
7. سریع حرکت کنید و چیزها را بشکنید.
8. ذهنیت ماموریت انتقادی را اتخاذ کنید.
9. محصول را بالغ کنید.
    

یک فرآیند استاندارد ایجاد کنید
ایجاد یک فرآیند استاندارد برای رفع اشکالات مهم است.

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

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

گوردون گفت: «ما آموخته‌ایم که بیش از حد محتاط بودن و استفاده از روش‌های قدیمی برای انتشار مدیریت تنها به اندازه دسته‌های بزرگ‌تر، میانگین زمان طولانی‌تر برای بازیابی و افزایش خطر منجر می‌شود. از طریق شیوه‌های DevOps، توسعه‌دهندگان Liberty Mutual نسخه‌های کوچک‌تر و هدفمندتری را وارد تولید می‌کنند. این مهندسان همچنین اجزای نرم افزار را به میکروسرویس هایی با جفت آزاد جدا کرده اند . میکروسرویس ها آنها را قادر می سازد تا مشکلات مربوط به تغییرات جزئی کد و فرآیند کمتری را نسبت به معماری یکپارچه برطرف کنند.

برای رفع سریع عیوب برنامه ریزی کنید
رویکرد دیگر برای رفع اشکالات در تولید این است که از شناسایی باگ به عقب برگردیم تا اینکه چگونه تیم می تواند به سرعت چنین نقص هایی را برطرف کند.

یوسف رادینگ، مهندس توسعه نرم‌افزار در آمازون که DevOps را نیز ارائه می‌کند، می‌گوید: «در حالی که ما فکر می‌کنیم باید هر کاری که در توان داریم انجام دهیم تا از اشکالات تولید جلوگیری کنیم، اما هنوز باید برای زمانی برنامه‌ریزی کنید، نه اگر، یک اشکال [آنجا] ظاهر شود». مشاوره از طریق Shuttl.io توسعه‌دهندگان می‌توانند با کار فعالانه روی تنگناهایی که می‌توانند رفع‌ها را کندتر کنند، وضوح سریع‌تر را تضمین کنند.

رادینگ توصیه می‌کند ابتدا روی ساده‌سازی کد و وابستگی‌های آن به صورت محلی با استفاده از روش‌شناسی برنامه ۱۲ عاملی تمرکز کنید. 12 عامل مربوط به موارد زیر است:

• پایه کد
• وابستگی ها
• پیکربندی
• خدمات پشتیبان
• ساختن، رها کردن، اجرا کردن
• فرآیندها
• اتصال بندر
• همزمانی
• یکبار مصرف
• برابری
• سیاهههای مربوط
• فرآیندهای مدیریت
   

سپس، فرآیند استقرار را خودکار و آسان کنید و استقرارها را کوچک نگه دارید.

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

او همچنین توصیه می‌کند که تغییرات را به جای بازگرداندن آنها برگردانید. Radding از دستور git revert برای لغو commit های خاص استفاده می کند و یک commit جدید اضافه می کند که تغییرات در commit قدیمی را حذف می کند. این تکنیک تضمین می کند که وقتی یک توسعه دهنده کد مشکل را حذف می کند، تغییرات دیگر باقی می مانند.

مدیریت زمان را تمرین کنید
هنگامی که تیم رویکردی برنامه ریزی شده داشته باشد، رفع اشکال سریع تر و کمتر مخرب تولید می شود. فیل کریپن، مدیر عامل John Adams IT، یک مشاور خدمات فناوری اطلاعات، گفت: چند مسیر وجود دارد که هر کدام دارای مزایا و معایب هستند.

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

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

پیاده سازی معیارها
تیم‌های نرم‌افزاری باید از معیارهایی برای تخمین تعداد باگ‌هایی که تیم می‌توانند در یک ماه برطرف کنند، استفاده کنند. کریپن گفت، برای مثال، در ایالات متحده، یک برنامه نویس متوسط ​​می تواند بین 9 تا 10 باگ را در ماه برطرف کند. یک برنامه نویس با تجربه می تواند تا 20 باگ را در این مدت برطرف کند. با در نظر گرفتن این میانگین ها، رهبران فناوری اطلاعات می توانند تخمین بزنند که تیم می تواند با چه تعداد از باگ ها مقابله کند.

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

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

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

Shayne Sherman، مدیر عامل TechLoris، یک سرویس مشاوره فناوری اطلاعات، گفت: «با شروع نوشتن تست‌ها برای عملکرد موجود، توسعه ممکن است در ابتدا کند شود، اما کیفیت بسیار بالا خواهد رفت.

کد تست را به دقت کد پروژه حفظ کنید و همیشه برای هر تغییری که توسعه دهندگان ایجاد می کنند، تست های واحد بنویسید. به گفته لوریس غیرممکن است که سیستمی با دقت کمتر داشته باشید و نتایج بهتری بگیرید. او استدلال می‌کند که تنها جایگزین این است که توسعه را متوقف کنیم تا باگ‌ها را برطرف کنیم – که گاهی اوقات به آن رویکرد اول رفع اشکال می‌گویند – که متأسفانه دیده شده است.

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

Manish Mistry، CTO در Infostretch، یک مشاور مهندسی دیجیتال، گفت: «مهندسی آشوب راهی برای آزمایش این است که کل سیستم همان کاری را که شما می‌خواهید انجام می‌دهد، و کد تنها بخشی از ترکیب است. برای آزمایش مؤثر، سیستم باید در حال تولید باشد. به هر حال، تنها در تولید است که یک تیم می تواند با عواملی مانند وضعیت، ورودی ها و نحوه رفتار سیستم های خارجی کار کند.

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

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

سریع حرکت کنید و چیزها را بشکنید
اگر رشد و محبوبیت کسب و کار به ارائه سریع عملکردهای جدید بستگی داشته باشد، ممکن است یک شرکت نگرش آرامی در مورد انتشار کد تولید با اشکال داشته باشد.

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

اما شرکت‌ها باید عرضه‌های سریع و بدون درز را با بازگرداندن سریع و بدون درز جفت کنند.

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

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

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

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

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

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

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

او گفت: «پس از رسیدن به بازار مناسب، باید روی تثبیت محصول خود تمرکز کنید.