ساخت برای نگهداری و تغییر
مهندسی نرمافزار
نرمافزاری بسازید که مرزهایش روشن، تغییرش قابلآزمایش و رفتارش در محیط اصلی قابلمشاهده باشد.
مسئله قبل از چارچوب
انتخاب فناوری باید از نیاز، محدودیت و عمر مورد انتظار سامانه بیاید.
قراردادهای روشن
مرز سرویس، API و داده باید برای تیم قابل فهم و قابل آزمون باشد.
کیفیت در مسیر انتشار
آزمون، بررسی و مشاهدهپذیری بخشی از تحویل هستند؛ نه مرحلهای جدا در پایان.
جزئیات اجرایی
کد خوب باید تغییر بعدی را هم ارزانتر کند.
هدف فقط رساندن قابلیت امروز به محیط اصلی نیست. ساختار نرمافزار باید خطا را قابل ردیابی، تغییر را قابل بررسی و وابستگیها را قابل مدیریت نگه دارد. برای همین مرزهای دامنه، قرارداد داده، رفتار خطا و مسیر انتشار را به اندازه خود قابلیت جدی میگیریم.
- مدل دامنه و مرز مسئولیت
- API و قرارداد داده
- آزمون خودکار در سطح مناسب
- مدیریت خطا و قابلیت مشاهده
- مهاجرت داده و سازگاری نسخه
دامنه کار
کار مهندسی میتواند این حوزهها را پوشش دهد
سرویسهای وب
معماری سمت سرور، API و منطق کسبوکار.
رابط کاربری
تجربه سریع، دسترسپذیر و قابل نگهداری.
یکپارچهسازی
اتصال سیستمها با قرارداد و مدیریت خطای روشن.
داده
مدل داده، مهاجرت، سازگاری و کارایی.
آزمون
ترکیب آزمون واحد، یکپارچه و سناریوهای حیاتی.
تحویل
ساخت و انتشار قابل تکرار با امکان بازگشت.
معماری باید به اندازه پیچیدگی مسئله باشد؛ نه بیشتر.
ریزسرویس، صف، کش یا هر الگوی دیگر فقط وقتی ارزش دارد که مسئله واقعی را حل کند. پیچیدگی بدون دلیل، هزینه عملیات و خطا را بالا میبرد.
FAQ
پرسشهای مهم قبل از شروع
روی سامانه موجود هم کار میکنید؟+
بله. میتوانیم از تحلیل معماری، بدهی فنی، کارایی یا یک قابلیت مشخص شروع کنیم.
حتماً باید فناوری فعلی عوض شود؟+
خیر. تغییر فناوری زمانی منطقی است که دلیل روشن و سود قابلاندازهگیری داشته باشد.
آزمون و مسیر انتشار هم در دامنه است؟+
بله. کیفیت نرمافزار بدون مسیر انتشار قابل اعتماد ناقص است.
قدم بعدی
قابلیت بعدی را طوری بسازیم که نگهداری قابلیت قبلی سختتر نشود.
مسئله، محدودیت فنی و سطح اطمینانی که برای انتشار لازم دارید را مشخص کنیم.