سلام رفقا امیدوارم که حالتون خوب باشه. در این پست از ویرگول خلاصه‌ای از کتاب معماری تمیز اثر uncle bob رو براتون آماده کردم که امیدوارم به دردتون بخوره. در نوشته زیر سعی کردم به صورت فصل به فصل خلاصه‌ها رو بیارم تا راحت‌تر بتونید اون رو با متن اصلی تطابق بدید.
و اما بریم سراغ اصل مطلب :)
فصل 15 - معماری چیست؟
معماری نرم‌افزار به‌عنوان یک چارچوب کلی برای ساخت و توسعه نرم‌افزارها عمل می‌کند. معماری نرم‌افزار شامل اجزاء مختلف مانند ماژول‌ها، کلاس‌ها و روابط بین آن‌ها است. این مفهوم معماری برای تعیین چگونگی تقسیم کار و ترتیب منطقی نرم‌افزار بسیار مهم است. معماری نرم‌افزار باید از دیدهای توسعه، استقرار، عملیات و نگهداری نرم‌افزار را بهینه کند. یکی از اهداف اصلی معماری نرم‌افزار کاهش هزینه نگهداری در طول عمر نرم‌افزار و افزایش بهره‌وری توسعه‌دهندگان است. معماران نرم‌افزار سعی می‌کنند تا حد امکان گزینه‌های مختلفی را باز بگذارند و تصمیم‌گیری‌های خاصی را به تأخیر بی‌اندازند.
فصل 16 - تفکیک‌لایه‌ای و استقلال
در فصل 16، مفهوم تفکیک‌لایه‌ای و استقلال در معماری نرم‌افزار موردبررسی قرار می‌گیرد. تفکیک‌لایه‌ای به ایجاد مرزها و مرزهای مشخص بین اجزاء مختلف نرم‌افزار اشاره دارد. این تفکیک به تقسیم نرم‌افزار به لایه‌های مختلف کمک می‌کند که هرکدام وظایف مشخص خود را انجام می‌دهند.
لایه‌های مختلف می‌توانند شامل لایه واسط کاربری (UI)، لایه منطق کسب‌وکار (Business Logic) و لایه داده (Data Layer) باشند. این تفکیک‌لایه‌ای به توسعه‌دهندگان امکان می‌دهد تا به‌صورت مستقل بر روی هر لایه کار کنند و تغییرات در یک‌لایه تأثیر چندانی بر لایه‌های دیگر نگذارند. این تفکیک از دیدهای توسعه، تست و نگهداری نرم‌افزار بسیار مفید است و به بهره‌وری و کیفیت کد کمک می‌کند.
فصل 17 - تست و اعتبارسنجی
در فصل 17، موضوع تست و اعتبارسنجی نرم‌افزار به‌تفصیل بررسی می‌شود. تست نرم‌افزار فرآیندی است که در آن نرم‌افزار مورد آزمون قرار می‌گیرد تا اطمینان حاصل شود که به‌درستی کار می‌کند و نقص‌های موجود در آن شناسایی و برطرف شوند. تست‌ها می‌توانند به‌صورت دستی یا به‌صورت خودکار با استفاده از ابزارهای تست نرم‌افزار انجام شوند.
تست‌ها به انواع مختلفی تقسیم می‌شوند، ازجمله:
- تست واحد (Unit Testing): در این نوع تست، قسمت‌های کوچکی از کد (معمولاً توابع و متدها) به‌صورت جداگانه تست می‌شوند.
- تست یکپارچگی(Integration Testing): در این نوع تست، تعامل بین اجزای مختلف نرم‌افزار تست می‌شود تا مشکلات در تعامل آن‌ها شناسایی شود.
- تست سیستمی (System Testing): نرم‌افزار به‌عنوان یک سیستم به‌طورکلی تست می‌شود.
- تست عملکردی (Performance Testing): در این نوع تست، عملکرد نرم‌افزار در شرایط مختلف تحت‌فشار موردبررسی قرار می‌گیرد.
- تست امنیتی (Security Testing): در این نوع تست، موارد مربوط به امنیت نرم‌افزار بررسی می‌شوند.
اعتبارسنجی نیز مرتبط با تست است و به معنای اطمینان حاصل کردن از اینکه نرم‌افزار به‌درستی کار می‌کند و نیاز‌ها و انتظارات کاربران را برآورده می‌کند. این فصل بر تکنیک‌ها و فرآیندهای اعتبارسنجی و ارزیابی نرم‌افزار تأکید دارد.
فصل 18 - مدیریت پروژه نرم‌افزار
فصل 18 به موضوع مدیریت پروژه‌های نرم‌افزاری اختصاص دارد. مدیریت پروژه نرم‌افزاری به مدیریت تمامی فعالیت‌های مرتبط با توسعه و عرضه نرم‌افزار می‌پردازد. این فعالیت‌ها شامل برنامه‌ریزی، کنترل هزینه و زمان، تخصیص منابع، مدیریت ریسک‌ها و ارتباط با سایر ارکان پروژه مانند توسعه‌دهندگان و مشتریان می‌شود.
مهم‌ترین چیزی که یک مدیر پروژه نرم‌افزار باید در نظر داشته باشد، برنامه‌ریزی و کنترل پروژه است. این شامل تعیین وظایف و اهمیت آن‌ها، تخصیص منابع به تسک‌ها و مدیریت تغییرات و ریسک‌ها می‌شود. همچنین، مدیریت پروژه باید با تیم توسعه‌دهنده و مشتریان در ارتباط باشد و به تعامل مؤثر بین آن‌ها کمک کند.
در مدیریت پروژه نرم‌افزاری، از ادوات و روش‌های مختلفی نیز استفاده می‌شود. این شامل استفاده از نرم‌افزارهای مدیریت پروژه، مدل‌های مختلف توسعه نرم‌افزار و تکنیک‌های افزایش بهره‌وری و کاهش مخاطرات پروژه می‌شود.
فصل 19 - تضمین کیفیت
فصل 19 به موضوع تضمین کیفیت در توسعه نرم‌افزار پرداخته است. تضمین کیفیت به اطمینان از اینکه نرم‌افزار تولیدی مطابق با استانداردها و نیازهای مشتریان است، می‌پردازد. تضمین کیفیت فرآیندی سیستماتیک است که در طی آن تمام مراحل توسعه نرم‌افزار به‌دقت موردبررسی قرار می‌گیرد.
تضمین کیفیت شامل انواع تکنیک‌ها و ابزارهایی می‌شود که برای ارزیابی کیفیت نرم‌افزار به کار می‌روند. این تکنیک‌ها شامل تست کیفیت، بازبینی کد، تجزیه‌وتحلیل کد، استفاده از متریک‌های کیفیت و موارد مشابه می‌شوند. تضمین کیفیت به مدیران پروژه و تیم‌های توسعه کمک می‌کند تا مشکلات کیفیتی را به‌زودی تشخیص دهند و برطرف کنند.
فصل 20 - معماری نرم‌افزار
فصل 20 به موضوع معماری نرم‌افزار اختصاص دارد. معماری نرم‌افزار مشخص می‌کند چگونه مؤلفه‌ها و اجزای مختلف نرم‌افزار به یکدیگر متصل شده و عمل می‌کنند. معماری نرم‌افزار تصمیم‌گیری‌های مهمی مانند ساختار کلی نرم‌افزار، اجزای مورداستفاده و تعامل بین اجزا را تعیین می‌کند.
معماری نرم‌افزار باید منعکس‌کننده نیاز‌ها و اهداف نهایی نرم‌افزار باشد. همچنین، باید به توسعه و نگهداری آسان نرم‌افزار کمک کند. معماری نرم‌افزار به توسعه‌دهندگان کمک می‌کند تا بخش‌های مختلف کد را به‌صورت مستقل از یکدیگر توسعه دهند و تغییرات را اعمال کنند.
مفاهیمی همچون الگوهای طراحی (Design Patterns)، معماری‌های لایه‌ای (Layered Architectures)، معماری‌های مبتنی بر خدمات (Service-Oriented Architectures) و معماری‌های مبتنی بر مایکروسرویس‌ها (Microservices Architectures) در این فصل موردبررسی قرار می‌گیرند. این مفاهیم مهم در طراحی معماری مناسب برای نرم‌افزارها هستند.
فصل 21 - معماری شگفت‌انگیز
در این فصل، به مهم‌ترین نکات معماری نرم‌افزار بحث می‌شود:
- معماری نرم‌افزاریک ساختار است که پشتیبانی از مورد استفاده‌های سیستم را انجام می‌دهد؛ بنابراین، هنگامی‌که کسی به دایرکتوری اصلی یک پروژه نگاه می‌کند، باید واضح باشد که مورد استفاده‌های سیستم چیست.
- چیزهایی که اغلب به‌عنوان معماری اشتباه گرفته می‌شوند: معمولاً وب (وب‌سایت و وب‌اپلیکیشن) به‌عنوان معماری در نظر گرفته نمی‌شود، بلکه به‌عنوان یک وسیله برای ارتباط (یک دستگاه ورودی/خروجی) مورداستفاده قرار می‌گیرد. همچنین، چارچوب‌ها (Frameworks) و ساختارهایی که آن‌ها به پروژه‌ها اعمال می‌کنند، به‌عنوان معماری در نظر گرفته نمی‌شوند. باید دقت شود که از معماری مورداستفاده و از چارچوب‌ها به‌عنوان ابزارهای کمکی بهره گرفته شود و اجازه داده شود که معماری مورداستفاده اولویت داشته باشد.
- معماری‌های قابل تست: معماری مرتبط با موردهای استفاده، باید از چارچوب‌ها و جزئیات دیگر دوری داشته باشد و این امکان را فراهم کند که به‌راحتی بتوان از تست‌های واحد (Unit Test) بدون نیاز به اجرای چارچوب‌ها، وب‌سرورها یا پایگاه داده‌ها استفاده کرد.
فصل 22 - معماری تمیز
معماری تمیز (Clean Architecture) یک مدل طراحی نرم‌افزاری است که به شکل چهار لایه اصلی مختلف سازمان‌دهی می‌شود تا برنامه‌ها بهتر قابل نگهداری، تست و توسعه باشند. این چهار لایه شامل موارد زیر هستند:
1. موجودیت‌ها(Entities): این لایه بیشترین استقلال از جزئیات اجرایی دارد و قوانین تجاری مستقل از برنامه را در خود نگه می‌دارد. این موجودیت‌ها می‌توانند اشیاء با متدها یا مجموعه‌ای از ساختارها و توابع باشند.
2. موارد استفاده (Use Cases): این لایه شامل قوانین تجاری خاص برنامه است که ممکن است با تغییرات در نحوه استفاده برنامه تغییر کنند. موارد استفاده کنترل تعامل بین موجودیت‌ها را انجام می‌دهند و از رابط‌های دسترسی به داده برای گرفتن داده‌های موردنیاز از پایگاه داده استفاده می‌کنند.
3. آداپترهای رابط (Interface Adapters): این لایه‌ها وظیفه تبدیل داده‌ها از فرمت مناسب برای موارد استفاده و موجودیت‌ها به فرمت مناسب برای عوامل خارجی نظیر پایگاه داده یا رابط کاربری را دارند.
4. چارچوب‌ها و درایورها (Frameworks and Drivers): این لایه‌ها شامل چارچوب‌ها و وسایل نرم‌افزاری اصلی مانند پایگاه داده و چارچوب وب هستند. اغلب کدهای موجود در این لایه‌ها نیاز به تغییر ندارند و تنها کدهای کمی برای ارتباط با لایه‌های دیگر می‌نویسیم.
فصل 23 - ارائه‌دهندگان و اشیاء ساده
فصل 24 - مرزهای جزئی
مرزهای معماری کامل و دقیق می‌تواند پیچیده و گران باشد، به‌خصوص برای پروژه‌های کوچک. در این موارد، می‌توانیم مرزهای جزئی را معرفی کنیم که پیچیدگی و هزینه را کاهش می‌دهد، درحالی‌که هنوز امکان ارتقا به مرزهای دقیق را در صورت نیاز فراهم می‌کند.
فصل 25 - هزینه پیاده‌سازی در مقابل نادیده گرفتن مرزها
این فصل به بحث در مورد تعادل بین هزینه پیاده‌سازی مرزهای معماری و هزینه نادیده گرفتن آن‌ها می‌پردازد. پیاده‌سازی یک مرز زمانی که نرم‌افزار ساده است می‌تواند پرهزینه و منجر به مهندسی بیش‌ازحد شود. پیاده‌سازی یک مرز پس از نادیده گرفتن آن نیز پرهزینه و پرخطر است. همچنین، نادیده گرفتن دائمی یک مرز درجایی که موردنیاز است، پروژه را برای نگهداری و تغییر پرهزینه می‌کند.
بهترین رویکرد این است که هزینه‌ها و ریسک‌های پیاده‌سازی در مقابل نادیده گرفتن را بسنجیم تا تعیین کنیم مرزهای معماری کجا قرار دارند، کدام‌ها باید دقیق باشند، کدام‌ها می‌توانند جزئی باشند و کدام‌ها می‌توانند نادیده گرفته شوند. توجه داشته باشید که این تصمیم یک‌بار نیست، زیرا پروژه تکامل می‌یابد، باید به آنچه باعث ایجاد اصطکاک در توسعه و نگهداری می‌شود و می‌تواند از یک مرز استفاده کند توجه کنیم. هدف ما این است که مرز را در نقطه‌ای پیاده‌سازی کنیم که هزینه پیاده‌سازی کمتر از هزینه نادیده گرفتن باشد.
فصل 26 - مؤلفه اصلی، جزئیات نهایی
مؤلفه اصلی مسئول ایجاد تمام factory ها، استراتژی‌ها و سایر امکانات گلوبال است و سپس کنترل را به قسمت‌های بالایی سیستم تحویل می‌دهد. مرزهای جزئی می‌تواند روشی مفید برای کاهش پیچیدگی و هزینه ایجاد مرزهای معماری باشد، به‌خصوص برای پروژه‌های کوچک. بااین‌حال، مهم است که از تعادل‌های involved آگاه باشیم و تکنیک مرز جزئی مناسب برای نیازهای خاص خود را انتخاب کنیم.
خلاصه فصل 27 - خدمات: بزرگ و کوچک
این فصل مزایا و معایب خدمات را بررسی می‌کند و توضیح می‌دهد که چگونه می‌توان آن‌ها را به‌طور مؤثر طراحی و پیاده‌سازی کرد.
مزایای خدمات:
معایب خدمات:
فصل 28 - مرز تست
این فصل اهمیت آزمایش در معماری تمیز را بررسی می‌کند و نحوه طراحی آزمایش‌هایی که مؤثر و قابل نگهداری هستند را توضیح می‌دهد.
اهمیت آزمایش در معماری تمیز:
آزمایش‌ها برای اطمینان از کیفیت و قابلیت اطمینان یک سیستم نرم‌افزاری ضروری هستند. در معماری تمیز، آزمایش‌ها دایره بیرونی هستند و باید از بیرون به داخل برای آزمایش سیستم استفاده شوند.
نحوه طراحی آزمایش‌های مؤثر و قابل نگهداری:
فصل 29 - معماری توکار تمیز
این فصل نحوه اعمال اصول معماری تمیز به توسعه نرم‌افزار توکار را بررسی می‌کند.
چالش‌های توسعه نرم‌افزار توکار:
نرم‌افزار توکار به سخت‌افزاری که روی آن اجرا می‌شود به‌شدت پیوند دارد که می‌تواند توسعه و نگهداری آن را دشوار کند. نرم‌افزار توکارهمچنین باید با محدودیت‌های خاصی مانند حافظه محدود، محدودیت‌های زمانی واقعی و رابط‌های کاربری غیرمعمول کنار بیاید. خدمات می‌توانند راهی عالی برای جداسازی و توزیع یک سیستم نرم‌افزاری باشند. بااین‌حال، مهم است که آن‌ها را به‌دقت طراحی کنید تا از پیوند و پیچیدگی جلوگیری کنید. آزمایش برای اطمینان از کیفیت و قابلیت اطمینان یک سیستم نرم‌افزاری ضروری است و معماری تمیز چارچوبی برای طراحی آزمایش‌های مؤثر و قابل نگهداری ارائه می‌دهد. معماری تمیز همچنین می‌تواند به توسعه نرم‌افزار توکاراعمال شود، اما مهم است که چالش‌های خاص توسعه نرم‌افزار توکاررا در نظر بگیرید.
