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