ثبات، یک ابزار قدرتمند در کاهش پیچیدگی سیستم و افزایش شفافیت در رفتار آن است. منظور از ثبات، این است که چیزهای مشابه، با روش های مشابه انجام می شوند و چیزهای متفاوت، با روش های متفاوت.
اگر نرم افزار ثبات داشته باشد، زمانی که برنامه نویس، یاد گرفت در نرم افزار، چه چیزی چگونه انجام می شود، می تواند در موقعیت های مشابه، به سرعت، رویکرد مشابه را تشخیص دهد.
ولی اگر در توسعه ی نرم افزار، ثبات وجود نداشته باشد، برنامه نویس ها باید در هر موقعیت، چیزهای جدید یاد بگیرند و زمان توسعه ی نرم افزار، بیشتر خواهد شد.
ثبات همچنین باعث کاهش خطا می شود. اگر ثبات وجود نداشته باشد، دو موقعیتِ متفاوت، به اشتباه، یکسان قلمداد خواهد شد. در نتیجه یک برنامه نویس، ممکن است الگویی را ببیند که آشنا به نظر می رسد و بر اساس برخوردهای قبلی با آن الگو، فرض های نادرستی داشته باشد.
از سوی دیگر، اگر سیستم ثبات داشته باشد، مفروضاتی که بر اساس موقعیتهای آشنا به نظر میرسند، به احتمال زیاد، درست خواهند بود. ثبات به توسعه دهندگان اجازه می دهد تا با اشتباهات کمتری و با سرعت بیشتری کار کنند.
اگر برای شما سخت است که معنی "ثبات" در نرم افزار را متوجه شوید، این مثال ها به شما کمک خواهند کرد:
همانطور که در نوشته ی نام گذاری گفته شد، ثبات در نام گذاری سه شرط اصلی دارد:
همیشه برای یک هدف خاص، از یک نام مشترک استفاده شود.
هیچ وقت آن نام مشترک، برای هدف دیگری به کار برده نشود.
آن نام مشترک باید آن قدر مرتبط باشد، که همه ی متغیرهای با این نام، رفتار یکسانی داشته باشند.
درست است که کامپایلرها، قوانینی دارند که برنامه نویس ها را تا حد زیادی محدود می کنند. با این حال، امروزه اکثر شرکت ها، فراتر از این محدودیت ها، قوانینی وضع می کنند که سبک کدنویسی برنامه نویس ها را به هم نزدیک کنند و برای آن محدودیت هایی بگذارند. این محدودیت ها شامل نام گذاری، ترتیب تعریف متغیرها، فاصله گذاری در کد و همچنین نحوه و میزان استفاده از ویژگی های زبان برنامه نویسی خاص آن شرکت است. مثلا ممکن است اگر در نرم افزارهای شرکت از زبان C# استفاده می شود، بعضی ویژگی های خاص این زبان، ممنوع باشد.
یک interface که پیاده سازی های مختلف دارد، مثال دیگری از ثبات است. وقتی برنامه نویس، یک پیاده سازی از یک interface را می بیند و می شناسد، فهمیدنِ سایر پیاده سازی های آن interface برایش ساده تر خواهد بود. بنابراین، interface ها به افزایش ثبات نرم افزار کمک خواهند کرد.
الگوهای طراحی (Design Patterns)، راه حل های عمومی، برای مسائلِ عمومی هستند. اگر الگوهای طراحی در بخشی از کد استفاده شوند، پیاده سازی آن بخش، سریع تر پیش خواهد رفت، همچنین آن بخش، مشابهِ سایر بخش ها با مساله ی یکسان خواهد بود و کسی که می خواهد بعدا کد را بخواند، با سرعت بیشتری آن را خواهد فهمید.
از آن جا که معمولا تعداد افراد زیادی روی یک پروژه ی نرم افزاری کار می کنند، تضمین کردن ثبات، کار سختی است. کسانی که در یک تیم کار می کنند، ممکن است از قراردادها و قوانینِ تیم های دیگر اطلاع نداشته باشند. افرادِ جدیدی که به تیم اضافه می شوند، قوانین را نمی دانند، بنابراین ممکن است آن ها را بشکنند و سبک های جدیدی به کد اضافه کنند.
روش هایی هست که می توان با استفاده از آن ها، ثبات را در نرم افزار ایجاد و حفظ کرد:
بهتر است لیست تمام قوانین، شامل سبک کدنویسی، نام گذاری و ... مستند شود. این مستندات باید در جایی قرار بگیرند که به سادگی قابل دسترس و حتما در معرض دید برنامه نویس ها باشد. افرادِ جدیدی که به تیم ملحق می شوند، باید تشویق به خواندن این مستندات شوند و افرادِ قدیمی تیم، تشویق به بازخوانی و در صورت نیاز، اصلاح این مستندات. برای شروعِ تهیه ی این سندها، می توان از نمونه های بسیاری که شرکت های معتبر روی اینترنت قرار داده اند استفاده کرد.
حتی اگر مستندات کامل باشند، برای برنامه نویس ها، به خاطر داشتن تمام قوانین سخت است. بهترین راه برای اطمینان از اجرا شدن قراردادها، استفاده از ابزاری است که تخلف ها را شناسایی کرده و به کدی که قوانین در آن رعایت نشده، اجازه ی commit شدن نمی دهد.
علاوه بر ابزارها، یکی دیگر از روش های متعهد کردن برنامه نویس ها به قوانین و همچنین آموزش افرادِ تازه کار، code review است. در این مورد، کسانی که مسئول code review هستند، باید از بین افراد بادقت و تیزبین انتخاب شوند.
این ضرب المثل، بهترین نصیحت برای برنامه نویس ها است. وقتی روی یک بخش جدید از نرم افزار کار می کنید ببینید کدی که قبلا نوشته شده چه ساختاری دارد. برای مثال، آیا همه متدهای public قبل از private ها تعریف شده اند؟ آیا متدها در یک کلاس، به ترتیب حروف الفبا چیده شده اند؟ نام گذاری ها به چه صورت است؟
اگر به نظرتان رسید که یک قرارداد و الگوی مشابه پیدا کرده اید، آن را دنبال کنید. زمانی که یک تصمیمِ طراحی می گیرید، از خودتان بپرسید آیا بخش های مشابه، به همین ترتیب طراحی شده است یا نه؟ اگر جایی، کاری شبیه به کار شما انجام شده بود، آن را پیدا کنید و رویکرد مشابه ای را در کد خودتان برگزینید.
نکته ی مهم این است:
قرارداد ها را تغییر ندهید.
در برابرِ میل به بهبود قرارداد های موجود، مقاومت کنید. داشتن "ایده ی بهتر" بهانه ی کافی برای ایجاد ناسازگاری نیست. ایده ی جدیدِ شما ممکن است واقعاً بهتر باشد، اما ارزشِ ثبات در برابر ناسازگاری، تقریباً همیشه بیشتر از ارزش یک رویکرد نسبت به رویکرد دیگر است.
قبل از این که به سیستم بی ثباتی تحمیل کنید، این دو سوال را از خودتان بپرسید:
اگر سازمانِ شما موافق است که پاسخ به هر دو سوال "بله" است، پس تغییرات را اعمال کنید. وقتی کارتان تمام شد، نباید اثری از قراردادهای قدیمی وجود داشته باشد. با این حال، همچنان این خطر وجود دارد، که افرادِ دیگر، از قراردادِ جدید اطلاعی نداشته باشند، بنابراین ممکن است در آینده رویکرد قدیمی را مجدداً استفاده کنند. به طور کلی، بهتر است وقتِ برنامه نویس ها، در موارد مهم تری صرف شود، تا بازنگری در قرادادهای موجود.
ثبات نه تنها به این معنی است که، کارهای مشابه باید به روش های مشابه انجام شود، بلکه به این معناست که کارهای غیر مشابه، باید به روش های مختلف انجام شود. اگر در مورد ثبات بیش از حد حساسیت نشان دهید و سعی کنید چیزهای غیر مشابه را با یک رویکرد انجام دهید، مثلاً استفاده از نام متغیرِ یکسان برای چیزهایی که واقعاً متفاوت هستند یا استفاده از یک الگوی طراحیِ موجود برای کاری که با آن الگو متناسب نیست، پیچیدگی و سردرگمی ایجاد خواهد شد.
ثبات، نمونه ی دیگری از طرز فکر سرمایه گذاری است.
برای اطمینان از ثبات، باید کمی وقت برای این موارد سرمایه گذاری کنیم:
سودِ این سرمایه گذاری این است که، کد شفاف تر خواهد بود. برنامه نویس ها میتوانند رفتار کد را سریع تر و دقیق تر درک کنند، و این به آنها اجازه میدهد کار خود را با خطای کمتری به انجام برسانند.
