توی سال های اخیر چیزی که توی کار توجهم رو جلب کرده میزان پذیرش خطا و اشکال در نرم افزار های تولید شده‌ست که از تیم به تیم و شرکت به شرکت متفاوت بوده.
«آستانه تحمل مشکل» در نرم افزار یکی از فاکتور های مهمیه که می‌تونه روی کیفیت خروجی های یک تیم تاثیر زیادی داشته باشه. من توی سال های ابتدایی کاریم مثل خیلی از همکار های دیگه‌م وقتی مشکلی برای نرم افزار پیش می‌اومد حالت حق به جانبی داشتم و میگفتم «خب نرم افزاره دیگه مشکل پیدا می‌کنه! صبر کنید درستش می‌کنیم.» و به مرور این تبدیل به فرهنگ خیلی از سازمان ها می‌شد و هنوز هم اتفاق می‌افته.
خب این جمله که «نرم افزاره دیگه مشکل پیدا می‌کنه» به طور کلی اشتباه نیست و ماهیت سیستم های پیچیده نرم افزاری طوریه که احتمال اتفاق های غیرقابل پیش بینی توش وجود داره و حتما حد مناسبی از «آستانه تحمل مشکل» برای جلو رفتن کارها در سازمان های بر پایه تکنولوژي لازمه اما ما برنامه نویس ها و مهندس های نرم افزار هم باید در این مورد آستانه پذیرش خاصی که مناسب باشه پیدا کنیم این فرض که هر مشکلی روی محیط پروداکشن نرم افزار ما باید قابل پذیرش و تحمل از طرف بیزنس و مصرف کننده های اون باشه می‌تونه کیفیت کار ما رو به طور جدی تحت تاثیر قرار بده.
برای درکش حس خودتون رو وقتی برای ۱۰ امین بار به سازمان دولتی مراجعه می‌کنید و می‌گن «سیستم قطعه» تصور کنید! پس هر حدی از مشکل نمی‌تونه قابل پذیرش باشه.
به نظر من، حتما حد یا بازه بهینه ای از پذیرش خطا و اشکال باید وجود داشته باشه که این باید از طرف تیم مهندسی نرم افزار و همینطور کسایی که کسب و کار یا عملکرد روزمره شون وابسته به اون نرم افزار هست پذیرفته بشه.
این آستانه هم تعریف یکسان و مشخصی نداره و قطعا بسته به کاربرد و اهمیت نرم افزار ها، میزان گستردگی استفاده از اون ها و … باید متفاوت تعریف بشه. مثلا توقع نداریم که آستانه پذیرش اشکال برای سیستم هدایت فضاپیما و فروشگاه آنلاین با ۱۰ سفارش روزانه یکسان باشه و این اساسا یکی از فاکتور هایی هست که باعث می‌شه سازمان های بزرگ با آستانه پذیرش خطای خیلی پایین با هزینه های زیاد تلاش کنن که بهترین مهندس های نرم‌افزار رو جذب خودشون کنن.
چه به عنوان مسئول، مدیر یا مالک کسب و کار و چه به عنوان مهندس نرم افزار حد بهینه پذیرش خودتون رو پیدا و برای رسیدن بهش تلاش کنین .
به عنوان مهندس یا معمار نرم افزار ها، ریسک های بیزنس رو شناسایی کنین و برای بالا بردن کیفیت نرم‌افزار تا رسیدن به آستانه تحمل مورد نظر تلاش کنین.
فرض کنیم که ما به عنوان مهندس یا معمار نرم افزار پذیرفتیم که این ادعا که نرم افزار جایز الخطاست به طور کامل قابل پذیرش نیست و ضمن درک ماهیت پیچیده ساختاری نرم افزار ها که می‌تونه باعث بشه که مشکلات مختلف براشون ایجاد شه میخوایم سطح مشکلات رو پایین تر بیاریم تا هم کیفیت کار خودمون رو بالا ببریم و هم ریسک های بیزنس رو کمتر کنیم.
در مورد بدهی های فنی با تیم های محصول و کسب و کار صادق باشید، هر چیزی که بین نرم افزار تولید شده و نرم افزار عالی و بی عیب و نقص فاصله بندازه می‌تونه به عنوان بدهی فنی شناسایی بشه. وظیفه آدم های باتجربه دنیای نرم افزار اینه که این بدهی ها رو شناسایی کنن و البته بتونن تشخیص بدن که کدوم اون ها اهمیت بالایی داره و ریسک واقعی ایجاد می‌کنه و برای حل اون ها اقدام بکنند.
همیشه بخشی از بودجه زمانی تیم توسعه نرم افزار باید صرف بدهی های فنی بشه اما نباید به سمت نرم افزار بی عیب و نقص هم حرکت کرد.
تلاش کنید بین بدهی های فنی تفاوت قائل بشید و از دید بیزنس و ریسک مشکلات جدی به اون ها نگاه کنید و وسواس معنایی به خرج ندید.
من کلمه طراحی رو توی دنیای نرم افزار بهتر از معماری می‌دونم، کلمه معماری از صنعت ساختمان گرفته شده و تصور کنید اگه معمار های بزرگ مثل ما نرم افزاری ها فکر میکردند تا حالا چن تا برج و پل ممکن ریخته بود روی سر مون!
اما جدا از شوخی همیشه برای طراحی ساختار نرم افزار ها وقت بزارین و قبل از دست به کد شدن یه کمی بررسی کنید که ارتباط بخش های مختلف با هم دیگه می‌تونه بهتر طراحی بشه یا نه و یادتون باشه که ما نرم افزار بدون طراحی نداریم! یا طراحی درست و خوب انجام می‌شه و یا طراحی بد و تصادفی.
فرایند تبدیل شدن یه ایده یا نیازمندی به نرم افزار رو می‌شه چرخه تولید دونست. اگه فقط بخش فنی کار رو در نظر بگیریم لازمه که حداقل چند اتفاق تا تولید نسخه پروداکشن بیافته که خلاصه ترینش از دید من این هاست:
توی هرکدوم از این مراحل ، باید زمان کافی گذاشته بشه تا به نتیجه قابل قبول برسیم. اولویت خیلی خیلی خیلی بالایی برای اتوماتیک بودن تست ها در نظر بگیرید و حتی برای بازبینی هم تا جای ممکن از سرویس های اتوماتیک استفاده کنین.
این چرخه خیلی ساده سازی شده است اما مهم اینه که برای خودتون و سازمان تون چرخه تولید تعریف کنید و با گذر زمان اون رو بهینه تر و بهتر کنید.
وقتی مشکل بزرگی برای نرم افزار ایجاد می‌شه یا از دسترس خارج می‌شه فقط و فقط برای اعضا یک چیز اهمیت داره و اون هم برگردوندن سیستم به حالت فعال و رفع مشکله. اما نباید تو این مرحله متوقف شیم و باید با پیگیری بیشتر و عمیق تر مشکل رو درک کنیم و برای دنبال راه حل بگردیم. به این کار به اصطلاح کالبد شکافی یا آزمایش پس از مرگ (Post Mortem) گفته می‌شه. در مورد کالبد شکافی می‌شه جداگانه مقاله بلندی نوشت و راجع بهش خیلی حرف زد اما این‌جا فقط نکته های مهمی که لازمه بهش توجه بشه تا این کار تو مسیر درست انجام بشه رو می‌نویسم:
این ها بخشی از کارهایی بود که می‌تونیم برای پیشرفت خودمون به عنوان مهندس نرم‌افزار و همینطور بالاتر بردن کیفیت کار تولید شده مون انجام بدیم.
اما مهم ترین نکته اینه که یادمون باشه نرم افزار جایز الخطاست، اما نه هر خطایی!
اگر توی تیم یا سازمانی کار می‌کنید که هرروز نرم افزار تون به اصطلاح down می‌شه و مشکلات عجیب و غریب و گاهی تکراری براش پیش میاد و کلی از وقت و تمرکزتون صرف رفع کردن شون می‌شه خودتون رو گول نزنید و سعی کنین با انتخاب روش های بهتر و به کار بردن نکته هایی از جنس نکته های بالا، کنترل اوضاع رو دوباره به دست بگیرید.
