معرفی و دانلود کتاب معماری تمیز: راهنمای استادی در طراحی و ساختار نرم افزار

معرفی کتاب معماری تمیز: راهنمای استادی در طراحی و ساختار نرم افزار

کتاب معماری تمیز تألیف رابرت سی. مارتین، به موضوع طراحی و معماری برنامه‌های نرم‌افزار می‌پردازد و به مهندسین می‌آموزد چگونه کدهایی واضح، درست و دقیق بنویسند تا هزینه‌ها کاهش و عمر نرم‌افزار افزایش یابد. مارتین با کمک گرفتن از تجربیات پنجاه‌ساله‌اش در بالاترین سطوح برنامه‌نویسی، راهنمایی‌ها و دستورالعمل‌هایی ارائه می‌دهد که باعث می‌شوند با چالش‌ها به‌خوبی مواجه شوید و در معماری درست نرم‌افزار به موفقیت برسید.

درباره‌ی کتاب معماری تمیز

در دنیای نرم‌افزار به‌کرات پیش می‌آید که کدهای نرم‌افزارها با شلختگی نوشته می‌شوند. آن نرم‌افزار در ظاهر کار می‌کند ولی در پس پرده چنان به‌هم‌ریخته و درهم است که کسی جرئت دست زدن به آن را ندارد. یعنی اگر خطایی رخ دهد، شایدها هفته طول بکشد تا بتوان به علت آن پی برد. ضمن اینکه نیروی انسانی زیادی باید از آن پشتیبانی کنند. این خیلی ساده بدان معناست که شرکت باید هزینه‌ی خیلی زیادی برای افزایش دوام و طول عمر نرم‌افزار صرف کند. اگر فشردگی بازار و رقابت را هم در نظر بگیریم، این مدل سویه‌های بدتری هم خواهد داشت. از کار افتادن نرم‌افزار برای مدتی طولانی می‌تواند ضررهایی جبران‌ناپذیر به شرکت وارد کند و فاجعه به بار بیاورد. نکته اینجاست که همه‌ی این‌ها به خاطر تمیز نبودن کدها رخ داده. بسیاری از برنامه‌نویس‌ها معتقدند در وهله‌ی اول سرعت مهم است و باید نرم‌افزار را سریع کامل کرد و به بازار فرستاد. بعد می‌توان برگشت و کدها را تمیز و واضح کرد. اما تجربه نشان داده این اتفاق هرگز نخواهد افتاد و آن‌ها به همین شکل ادامه می‌دهند تا در نهایت به مانع‌های بزرگ برخورد می‌کنند. رابرت سی. مارتین (Robert C. Martin)، برنامه‌نویس قدیمی و بزرگ آمریکا، ازجمله منتقدین این شیوه است و آن را ناکارآمد و نادرست می‌داند. او در کتاب معماری تمیز (Clean Architecture) تلاش کرده به برنامه‌نویس‌ها اصول معماری درست نرم‌افزار را بیاموزد و به آن‌ها کمک از ابتدا کدهای واضح و خوب بنویسند تا در ادامه به مشکل برنخورند.

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

کتاب معماری تمیز در رتبه‌ی نخست پرفروش‌ترین آثار بخش معماری کامپیوتر وب‌سایت آمازون بوده. این راهنما را ارجاسب محمدی و علیرضا کشاورز باحقیقت ترجمه و انتشارات نبض دانش آن را منتشر کرده است.

درباره‌ی مجموعه‌ی رابرت سی. مارتین

مجموعه‌ی رابرت سی. مارتین (Robert C. Martin Series)، کتاب‌هایی هستند که به اصول اخلاقی و حرفه‌ای در مهندسی نرم افزار می‌پردازند و مبانی این رشته را می‌آموزند. مارتین، برنامه‌نویس افسانه‌ای آمریکایی، در این کتاب‌ها با زبانی ساده و راحت به برنامه‌نویس‌ها نکات و دستورالعمل‌هایی را یادآور می‌شود تا بازدهی خود و مجموعه‌شان را افزایش دهند. «کد تمیز»، «کدنویس تمیز»، «معماری تمیز»، «چابک تمیز» و «مهارت تمیز» ازجمله آثاری هستند که از این سری به چاپ رسیده‌اند.

کتاب معماری تمیز برای چه کسانی مناسب است؟

مطالعه‌ی این کتاب به برنامه‌نویسان، مدیران و معماران نرم‌افزار و دیزاینرهای سیستم پیشنهاد می‌شود.

در بخشی از کتاب معماری تمیز: راهنمای استادی در طراحی و ساختار نرم افزار می‌خوانیم

ادسگر وایب دیجکسترا، در سال 1930 در رتردام متولد شد. وی در جنگ جهانی دوم، از بمباران شهر رتردام، جان سالم به در برد، زمانی که آلمان، هلند را اشغال کرده بود. او در سال 1948 دوران دبیرستان خود را با بالاترین نمره در درس‌های ریاضی، فیزیک، شیمی و زیست‌شناسی به اتمام رساند. در مارس 1952، در سن 21 سالگی (و 9 ماه قبل از تولد من)، شغلی در مرکز ریاضیات آمستردام بعنوان اولین برنامه‌نویس هلندی بدست آورد. دیجکسترا در سال 1955، به عنوان کسی که به مدت سه سال به شغل برنامه‌نویسی مشغول بوده و البته در آن زمان هنوز هم دانشجو بوده، به این نتیجه می‌رسد که چالش ذهنی برنامه‌نویسی، بزرگتر از چالش ذهنی فیزیک نظری است. در نتیجه، برنامه‌نویسی را بعنوان کسب و کار بلندمدت خود انتخاب می‌نماید.

او در سال 1957، با ماریا دبتز، ازدواج می‌کند. در آن زمان، طبق آداب و رسوم کشور هلند، در مراسم خواستگاری، می‌بایستی حرفه خود را بیان می‌کردید. بزرگترها، میلی به پذیرش برنامه‌نویس (شغلی مانند شغل دیجکسترا) نداشتند، آن‌ها هنوز نام این شغل را نشنیده بودند. دیجکسترا برای قانع کردن آنها، فیزیک‌دان نظری را بعنوان شغل خود اعلام کرد. او، در فرایند تصمیم گیری برای انتخاب برنامه‌نویسی بعنوان شغل، با رئیس خود (ادریان ون یجنگاردن) مشورت کرد. دیجکسترا از این نگران بود که هیچ کسی، علم یا حوزه‌ای به نام برنامه‌نویسی را نمی‌شناسد و به این دلیل کسی او را جدی نخواهد گرفت. رئیس در پاسخ به او گفت: دیجکسترا می‌تواند کسی باشد که این حوزه را کشف کند و نرم‌افزار را به علم تبدیل کند. دیجکسترا، شغلش را در عصر لوله‌های خلاء آغاز نمود، زمانی که کامپیوترها، بزرگ، شکننده، کند، فاقد اطمینان و (طبق استانداردهای امروزی) بشدت محدود بودند. در آن سال‌های اولیه، برنامه‌ها بصورت دودویی یا به زبان مطلقا اسمبلی نوشته می‌شدند. ورودی، بصورت فیزیکی یعنی نوار کاغذی یا کارت پانچ به کامپیوتر داده می‌شد. حلقه ویرایش/کامپایل/تست، اگر چندین روز طول نمی‌کشید، حتما ساعت‌ها زمان لازم داشت.

فهرست مطالب کتاب

بخش 1: مقدمه
فصل 1: طراحی و معماری چیست؟
هدف چیست؟
مطالعه موردی
امضای آشفتگی
دید اجرایی
چه اشتباهی رخ داد؟
نتیجه‌گیری
فصل 2: روایتی از دو ارزش
رفتار
معماری
ارزش بزرگتر
ماتریس آیزنهاور
نبرد برای معماری
بخش 2: شروع کار با خشت‌های سازنده: مدل‌های برنامه‌نویسی
فصل 3: مروری بر مدل‌ها (یا پارادایم‌ها)
برنامه‌نویسی ساختاریافته
برنامه‌نویسی شیءگرا
برنامه‌نویسی تابعی
غذای فکر
نتیجه‌گیری
فصل 4: برنامه‌نویسی ساختاریافته
اثبات
اعلام یک آیتم مضر
تجزیه تابعی (یا کارکردی، وظیفه‌ای)
علم برای نجات وارد صحنه شد
آزمون‌ها (تست)
نتیجه‌گیری
فصل 5: برنامه‌نویسی شیءگرا
کپسوله‌سازی؟
وراثت؟
چندریختی؟
قدرت چندریختی
وارون‌سازی وابستگی
نتیجه‌گیری
فصل 6: برنامه‌نویسی تابعی
مربعات اعدد صحیح
تغییرناپذیری و معماری
جداسازی تغییرپذیری
منبع‌یابی رویداد
نتیجه‌گیری
بخش 3: اصول طراحی
فصل 7: SRP: اصل تک‌مسئولیتی
نشانه 1: تکرار تصادفی
نشانه 2: ادغام
راه‌کارها
نتیجه‌گیری
فصل 8: OCP: اصل باز/بسته
یک آزمایش فکری
کنترل جهتی
مخفی‌سازی اطلاعات
نتیجه‌گیری
فصل 9: LSP: اصل جایگزینی لیسکوف
هدایت کاربرد وراثت
مسئله مربع/مستطیل
LSP و معماری
مثالی از نقض LSP
نتیجه‌گیری
فصل 10: ISP: اصل جداسازی واسط
ISP و زبان برنامه‌نویسی
ISP و معماری
نتیجه‌گیری
فصل 11: DIP: اصل وارون‌سازی وابستگی
تجریدهای پایدار
فاکتوری‌ها
مولفه‌های عینی
نتیجه‌گیری
بخش 4: اصول مولفه‌ها
فصل 12: مولفه‌ها
تاریخچه مختصری از مولفه‌ها
قابلیت جابجایی
لینک‌دهنده‌ها
نتیجه‌گیری
فصل 13: چسبندگی (یا انسجام) مولفه‌ها
REP (اصل معادل بودن استفاده مجدد/انتشار)
اصل بستار مشترک
مشابهت CCP با SRP
اصل استفاده مجدد مشترک (CRP)
روابط CRP با ISP (اصل جداسازی واسط)
نمودار تضاد برای چسبندگی مولفه
نتیجه‌گیری
فصل 14: پیوند مولفه‌ها
اصل وابستگی‌های غیرمدور
Build هفتگی
حذف دورهای وابستگی
اثر دور در گراف وابستگی مولفه
قطع کردن دور
Jitters
طراحی بالا به پائین
اصل وابستگی‌های پایدار
پایداری
معیارهای پایداری
نباید همه مولفه‌ها، پایدار باشند
مولفه‌های تجریدی
اصل تجرید پایدار
سیاست‌های سطح بالا را کجا قرار دهیم؟
استفاده از اصل تجرید پایدار
اندازه‌گیری میزان تجرید
ترتیب اصلی
منطقه زحمت
منطقه بی‌استفادگی
جلوگیری از مناطق استثناء
فاصله گیری از ترتیب اصلی
نتیجه‌گیری
بخش 5: معماری
فصل 15: معماری چیست؟
توسعه
گسترش
عملیات
نگهداری
بازنگهداشتن گزینه‌ها
استقلال دستگاه
ایمیل انبوه (junk mail)
آدرس‌دهی فیزیکی
نتیجه‌گیری
فصل 16: استقلال
موارد استفاده
عملیات
توسعه
گسترش
بازگذاشتن گزینه‌ها
تجزیه لایه‌ها
تجزیه (جداسازی) موارد استفاده
تجزیه مد (حالت)
توسعه‌پذیری مستقل
گسترش‌پذیری مستقل
تکثیر
تجزیه (دوباره) مد
بهترین مد استفاده کدام است؟
نتیجه‌گیری
فصل 17: مرزها: ترسیم خطوط
چندین خاطره غم‌انگیز
FitNesse
کدام خطوط را و در چه زمانی باید ترسیم کنیم؟
ورودی و خروجی
معماری افزونه (پلاگین)
بحث افزونه‌ها
نتیجه‌گیری
فصل 18: آناتومی مرزها
تقاطع مرزها
یکپارچگی وحشتناک
مولفه‌های گسترش
نخ
فرایندهای محلی
سرویس‌ها
نتیجه‌گیری
فصل 19: سیاست و سطح
سطح
نتیجه‌گیری
فصل 20: قوانین تجاری
موجودیتها
موارد استفاده
مدل‌های درخواست و پاسخ
نتیجه‌گیری
فصل 21: معماری اسکریم (screaming)
تم معماری
هدف معماری
وب
فریمورک‌ها ابزار هستند نه راه و رسم زندگی
معماری‌های تست‌پذیر
نتیجه‌گیری
فصل 22: معماری تمیز
قانون وابستگی
موجودیت‌ها
موارد استفاده
آداپتورهای واسط
فریمورک و درایورها
عبور از مرزها
کدام داده‌ها از مرزها عبور می‌کنند
یک سناریوی نمونه
نتیجه‌گیری
فصل 23: ارائه‌دهنده‌ها و اشیای humble
الگوی شیء humble (سطح پائین، پست)
Presenters (ارائه‌دهنده‌ها) و Views (نماها)
تست و معماری
دروازه‌های پایگاه‌داده
نگاشت‌گرهای داده
شنودگرهای سرویس
نتیجه‌گیری
فصل 24: مرزهای جزئی (ناقص)
فرار از گام آخر
مرزهای یک‌بعدی
نمای ظاهری (façade)
نتیجه‌گیری
فصل 25: لایه‌ها و مرزها
شکار ومپس
معماری تمیز؟
عبور از جریان‌ها
تقسیم جریان‌ها
نتیجه‌گیری
فصل 26: مولفه اصلی
جزئیات نهایی
نتیجه‌گیری
فصل 27: سرویس: بزرگ و کوچک
سرویس، معماری است؟
سرویس‌ها، مفید هستند؟
اشتباه تجزیه‌گری
اشتباه توسعه و گسترش مستقل
مسئله کیتی
اشیایی برای حل مسئله
سرویس‌های مبتنی بر مولفه
پیوند متقاطع موضوعات
نتیجه‌گیری
فصل 28: مرز تست
تست‌ها بعنوان مولفه‌های سیستم
طراحی به منظور تست‌پذیری
تست API
پیوند ساختاری
امنیت
نتیجه‌گیری
فصل 29: معماری تعبیه‌شده تمیز
تست App-titude
گلوگاه سخت‌افزار هدف
لایه‌ها
جزئیات سخت‌افزار را به کاربر HAL نمایش ندهید
پردازنده، جزئیات است
IE: بیت‌های فعال سازی وقفه
سیستم عامل، جزئیات است
برنامه‌نویسی برای واسط و جایگزین‌پذیری
دستورات کامپایل شرطی DRY
نتیجه‌گیری
بخش 6: جزئیات
فصل 30: پایگاه‌داده جزئیات است
پایگاه‌داده رابطه‌ای
چرا سیستم‌های پایگاه‌داده اینقدر رایج شده‌اند؟
اگر دیسکی در کار نباشد چه می‌شود؟
جزئیات
موضوع کارایی
خاطره
نتیجه‌گیری
فصل 31: وب جزئیات است
نوسان بی‌پایان
پیام اخلاقی
نتیجه‌گیری
فصل 32: فرمورکها جزئیات هستند
نویسندگان فریمورک
پیوند نامتقارن
ریسک‌ها
راه‌حل
نتیجه‌گیری
فصل 33: مطالعه موردی: فروش فیلم
محصول
تحلیل مورد استفاده
معماری مولفه
مدیریت وابستگی
فصل 34: فصل فراموش‌شده
بسته‌بندی بر اساس لایه
بسته‌بندی بر اساس ویژگی
بسته‌بندی بر اساس مولفه
شیطان در جزئیات پیاده‌سازی نهفته است
سازماندهی در مقایسه با کپسوله سازی
دیگر مدهای (حالات) تجزیه
نتیجه‌گیری: توصیه فراموش‌شده
بخش 7: پیوست
پیوست A: باستان‌شناسی معماری
سیستم حسابداری اتحادیه
برش لیزری
نظارت بر قالب‌بندی آلومینیم
4-TEL
کامپیوتر منطقه سرویس
تعیین اعزام تعمیرکار (dispatch)
معماری
تغییر طراحی بزرگ در آسمان
اروپا
جمع بندی SAC
زبان سی
زبان سی
BOSS
pCCU
تله زمانبندی
DLU/DRU
معماری
VRS
انتخاب نام
معماری
جمع‌بندی VRS
پذیرش الکترونیکی
مرگ ER
سیستم اعزام تعمیرکار
ارتباطات تمیز
Setup
آنکل باب
ROSE
بحث‌ها ادامه داشت
آزمون ثبت نام معماران
نتیجه‌گیری