نکات کلیدی
1. پیچیدگی ریشه چالش‌های طراحی نرم‌افزار است
پیچیدگی از انباشت وابستگی‌ها و ابهامات ناشی می‌شود.
پیچیدگی به‌صورت تدریجی انباشته می‌شود. با رشد سیستم‌های نرم‌افزاری، به دلیل انباشت تدریجی وابستگی‌ها بین اجزا و بخش‌های کد مبهم، پیچیدگی افزایش می‌یابد. این پیچیدگی به سه شکل اصلی ظاهر می‌شود:
- تقویت تغییر: تغییرات کوچک نیاز به اصلاحات در مکان‌های زیادی دارند
- بار شناختی: توسعه‌دهندگان باید حجم زیادی از اطلاعات را برای ایجاد تغییرات درک کنند
- ناشناخته‌های ناشناخته: مشخص نیست که کدام کد باید اصلاح شود یا چه اطلاعاتی مرتبط است
سادگی پادزهر است. برای مقابله با پیچیدگی، طراحان نرم‌افزار باید بر ایجاد طراحی‌های ساده و واضح که وابستگی‌ها و ابهامات را به حداقل می‌رسانند، تمرکز کنند. این شامل موارد زیر است:
- طراحی ماژولار: تقسیم سیستم‌ها به ماژول‌های مستقل
- پنهان‌سازی اطلاعات: محصور کردن جزئیات پیاده‌سازی درون ماژول‌ها
- انتزاعات واضح: ارائه رابط‌های ساده که پیچیدگی‌های زیرین را پنهان می‌کنند
2. برنامه‌نویسی استراتژیک بر رویکردهای تاکتیکی برتری دارد
بهترین رویکرد این است که به‌طور مداوم سرمایه‌گذاری‌های کوچک زیادی انجام دهید.
تفکر بلندمدت نتایج بهتری به همراه دارد. برنامه‌نویسی استراتژیک بر ایجاد طراحی عالی که به‌طور تصادفی کار می‌کند، تمرکز دارد، نه فقط کارکردن کد. این رویکرد شامل موارد زیر است:
- سرمایه‌گذاری زمان در طراحی از ابتدا
- بهبودهای کوچک مداوم
- بازسازی کد برای حفظ طراحی تمیز
برنامه‌نویسی تاکتیکی به بدهی فنی منجر می‌شود. در حالی که رویکردهای تاکتیکی ممکن است در کوتاه‌مدت سریع‌تر به نظر برسند، اغلب منجر به موارد زیر می‌شوند:
- انباشت اصلاحات سریع و هک‌ها
- افزایش دشواری در ایجاد تغییرات در طول زمان
- هزینه‌های توسعه بلندمدت بالاتر
با اتخاذ ذهنیت استراتژیک، توسعه‌دهندگان می‌توانند سیستم‌هایی ایجاد کنند که نگهداری و توسعه آن‌ها آسان‌تر باشد و در نهایت زمان و تلاش را در بلندمدت صرفه‌جویی کنند.
3. ماژول‌ها باید عمیق باشند، نه سطحی
بهترین ماژول‌ها آن‌هایی هستند که عملکرد قدرتمندی ارائه می‌دهند اما رابط‌های ساده‌ای دارند.
عمق انتزاع ایجاد می‌کند. ماژول‌های عمیق پیچیدگی پیاده‌سازی قابل توجهی را پشت رابط‌های ساده پنهان می‌کنند. این رویکرد:
- بار شناختی کاربران ماژول را کاهش می‌دهد
- امکان اصلاح آسان‌تر پیاده‌سازی را فراهم می‌کند
- پنهان‌سازی اطلاعات و محصورسازی را ترویج می‌دهد
ماژول‌های سطحی پیچیدگی را افزایش می‌دهند. ماژول‌هایی با رابط‌های پیچیده نسبت به عملکردشان سطحی در نظر گرفته می‌شوند. این ماژول‌ها:
- پیچیدگی کلی سیستم را افزایش می‌دهند
- جزئیات پیاده‌سازی غیرضروری را آشکار می‌کنند
- سیستم را سخت‌تر برای درک و اصلاح می‌کنند
برای ایجاد ماژول‌های عمیق، بر طراحی رابط‌های ساده و شهودی که پیچیدگی زیرین را انتزاع می‌کنند، تمرکز کنید. سعی کنید نسبت عملکرد به پیچیدگی رابط را به حداکثر برسانید.
4. رابط‌های خوب کلید مدیریت پیچیدگی هستند
رابط یک ماژول شامل دو نوع اطلاعات است: رسمی و غیررسمی.
رابط‌های خوب طراحی‌شده سیستم‌ها را ساده می‌کنند. رابط‌های خوب انتزاع واضحی از عملکرد یک ماژول ارائه می‌دهند بدون اینکه جزئیات غیرضروری را آشکار کنند. آن‌ها باید:
- ساده و شهودی برای استفاده باشند
- پیچیدگی‌های پیاده‌سازی را پنهان کنند
- اطلاعات رسمی (مانند امضای متدها) و غیررسمی (مانند توصیف رفتار سطح بالا) را ارائه دهند
رابط‌ها باید با دقت تکامل یابند. هنگام اصلاح کد موجود:
- تأثیر بر رابط ماژول را در نظر بگیرید
- از آشکار کردن جزئیات پیاده‌سازی خودداری کنید
- سعی کنید انتزاع ارائه‌شده توسط رابط را حفظ یا بهبود بخشید
با تمرکز بر ایجاد و حفظ رابط‌های خوب، توسعه‌دهندگان می‌توانند پیچیدگی را مدیریت کرده و سیستم‌های خود را ماژولارتر و آسان‌تر برای درک کنند.
5. نظرات برای ایجاد انتزاعات حیاتی هستند
نظرات تنها راه برای به‌طور کامل ثبت انتزاعات هستند و انتزاعات خوب برای طراحی سیستم خوب اساسی هستند.
نظرات انتزاعات را کامل می‌کنند. در حالی که کد می‌تواند جزئیات پیاده‌سازی را بیان کند، نظرات برای ثبت موارد زیر ضروری هستند:
- تصمیمات طراحی سطح بالا
- دلایل پشت انتخاب‌ها
- انتظارات و محدودیت‌ها
- انتزاعاتی که از کد به‌تنهایی واضح نیستند
نظرات را ابتدا بنویسید. با نوشتن نظرات قبل از پیاده‌سازی کد:
- تفکر خود را درباره طراحی روشن می‌کنید
- می‌توانید انتزاعات را زودتر ارزیابی و اصلاح کنید
- اطمینان حاصل می‌کنید که مستندات همیشه به‌روز است
بر روی چی و چرا تمرکز کنید، نه چگونه. نظرات خوب باید:
- چیزهایی را توصیف کنند که از کد واضح نیستند
- هدف و رفتار سطح بالای کد را توضیح دهند
- از تکرار صرف آنچه کد انجام می‌دهد خودداری کنند
با اولویت دادن به نظرات واضح و آموزنده، توسعه‌دهندگان می‌توانند انتزاعات بهتری ایجاد کرده و طراحی کلی سیستم‌های خود را بهبود بخشند.
6. نام‌گذاری و قالب‌بندی منسجم خوانایی را افزایش می‌دهد
نام‌های خوب نوعی مستندات هستند: آن‌ها کد را آسان‌تر برای درک می‌کنند.
انسجام بار شناختی را کاهش می‌دهد. با ایجاد و پیروی از کنوانسیون‌ها برای نام‌گذاری و قالب‌بندی، توسعه‌دهندگان می‌توانند:
- کد را قابل پیش‌بینی‌تر و آسان‌تر برای خواندن کنند
- تلاش ذهنی مورد نیاز برای درک کد را کاهش دهند
- ناسازگاری‌هایی را که ممکن است نشان‌دهنده اشکالات یا مسائل طراحی باشند، برجسته کنند
نام‌ها را با دقت انتخاب کنید. نام‌های خوب باید:
- دقیق و بدون ابهام باشند
- تصویر واضحی از موجودیت نام‌گذاری شده ایجاد کنند
- به‌طور منسجم در سراسر کد استفاده شوند
قالب‌بندی مهم است. قالب‌بندی منسجم کمک می‌کند با:
- آشکارتر کردن ساختار کد
- گروه‌بندی عناصر مرتبط به‌صورت بصری
- تأکید بر اطلاعات مهم
با توجه به نام‌گذاری و قالب‌بندی، توسعه‌دهندگان می‌توانند به‌طور قابل توجهی خوانایی و نگهداری کد خود را بهبود بخشند.
7. پالایش مداوم برای حفظ طراحی تمیز ضروری است
اگر می‌خواهید ساختار نرم‌افزاری تمیزی داشته باشید که به شما اجازه دهد در بلندمدت به‌طور کارآمد کار کنید، باید از ابتدا زمان اضافی برای ایجاد آن ساختار صرف کنید.
طراحی یک فرآیند مداوم است. طراحی نرم‌افزار تمیز نیاز دارد:
- بازسازی منظم برای بهبود کد موجود
- ارزیابی مداوم تصمیمات طراحی
- تمایل به ایجاد تغییرات با تکامل سیستم
در بهبود سرمایه‌گذاری کنید. برای حفظ طراحی تمیز:
- زمان برای پاکسازی و بازسازی اختصاص دهید
- مسائل طراحی را به‌موقع برطرف کنید، قبل از اینکه انباشته شوند
- هر تغییر کد را به‌عنوان فرصتی برای بهبود طراحی کلی ببینید
تعادل بین کمال و پیشرفت. در حالی که به دنبال طراحی تمیز هستید:
- بپذیرید که برخی مصالحه‌ها ممکن است ضروری باشند
- بر ایجاد بهبودهای تدریجی تمرکز کنید
- تغییراتی را که بیشترین مزایا را ارائه می‌دهند، اولویت‌بندی کنید
با در نظر گرفتن طراحی به‌عنوان یک فرآیند مداوم پالایش، توسعه‌دهندگان می‌توانند سیستم‌های خود را تمیز و قابل مدیریت نگه دارند زیرا رشد و تکامل می‌یابند.
8. مدیریت خطا باید ساده شود، نه گسترش یابد
بهترین راه برای حذف پیچیدگی مدیریت استثناها این است که APIهای خود را به‌گونه‌ای تعریف کنید که هیچ استثنایی برای مدیریت وجود نداشته باشد: خطاها را از وجود تعریف کنید.
موارد استثنا را کاهش دهید. برای ساده‌سازی مدیریت خطا:
- APIها را به‌گونه‌ای طراحی کنید که شرایط استثنایی را به حداقل برسانند
- از رفتارهای پیش‌فرض برای مدیریت موارد حاشیه‌ای رایج استفاده کنید
- در نظر بگیرید که آیا استثناها واقعاً ضروری هستند
مدیریت خطا را تجمیع کنید. هنگامی که استثناها اجتناب‌ناپذیر هستند:
- در صورت امکان، چندین استثنا را در یک مکان مدیریت کنید
- از سلسله‌مراتب استثناها برای ساده‌سازی مدیریت خطاهای مرتبط استفاده کنید
- از گرفتن استثناهایی که نمی‌توانید به‌طور معناداری مدیریت کنید، خودداری کنید
موارد عادی را آسان کنید. بر ساده و واضح کردن مسیر عادی و بدون خطا در کد خود تمرکز کنید. این رویکرد:
- بار شناختی توسعه‌دهندگان را کاهش می‌دهد
- احتمال بروز اشکالات را به حداقل می‌رساند
- کد را آسان‌تر برای درک و نگهداری می‌کند
با ساده‌سازی مدیریت خطا، توسعه‌دهندگان می‌توانند سیستم‌های قوی‌تر و آسان‌تر برای درک ایجاد کنند.
9. کد عمومی معمولاً بهتر از راه‌حل‌های خاص است
حتی اگر از یک کلاس به‌صورت خاص استفاده کنید، کار کمتری برای ساخت آن به‌صورت عمومی وجود دارد.
عمومیت قابلیت استفاده مجدد را ترویج می‌دهد. کد عمومی:
- می‌تواند به طیف وسیع‌تری از مشکلات اعمال شود
- اغلب ساده‌تر و انتزاعی‌تر است
- تمایل به داشتن رابط‌های تمیزتر دارد
از تخصص زودرس خودداری کنید. هنگام طراحی عملکرد جدید:
- با رویکردی نسبتاً عمومی شروع کنید
- از وسوسه بهینه‌سازی برای موارد خاص خیلی زود خودداری کنید
- اجازه دهید طراحی بر اساس الگوهای استفاده واقعی تکامل یابد
تعادل بین عمومیت و سادگی. در حالی که به دنبال راه‌حل‌های عمومی هستید:
- از مهندسی بیش از حد یا افزودن پیچیدگی غیرضروری خودداری کنید
- اطمینان حاصل کنید که طراحی عمومی هنوز برای موارد رایج آسان برای استفاده است
- آماده باشید تا در صورت لزوم راه‌حل‌های خاص ایجاد کنید
با ترجیح دادن طراحی‌های عمومی، توسعه‌دهندگان می‌توانند سیستم‌های انعطاف‌پذیرتر و قابل نگهداری‌تری ایجاد کنند که بهتر برای مدیریت نیازهای آینده مجهز هستند.
10. کد را برای خوانایی بنویسید، نه برای سهولت نوشتن
نرم‌افزار باید برای سهولت خواندن طراحی شود، نه سهولت نوشتن.
اولویت‌بندی نگهداری بلندمدت. هنگام نوشتن کد:
- بر آسان کردن درک آن برای خوانندگان آینده تمرکز کنید
- از میانبرها یا ترفندهای هوشمندانه که هدف کد را مبهم می‌کنند، خودداری کنید
- زمان برای ایجاد انتزاعات واضح و مستندات سرمایه‌گذاری کنید
کد را واضح کنید. سعی کنید کدی بنویسید که:
- بتوان آن را به‌سرعت با حداقل تلاش ذهنی درک کرد
- از کنوانسیون‌های نام‌گذاری واضح و منسجم استفاده کند
- ساختار منطقی و آسان برای دنبال کردن داشته باشد
برای وضوح بازسازی کنید. به‌طور منظم کد موجود را مرور و بهبود دهید:
- به دنبال فرصت‌هایی برای ساده‌سازی بخش‌های پیچیده باشید
- روش‌های طولانی را به قطعات کوچک‌تر و متمرکزتر تقسیم کنید
- تکرار و ناسازگاری‌ها را حذف کنید
با اولویت دادن به خوانایی بر سهولت نوشتن، توسعه‌دهندگان می‌توانند سیستم‌هایی ایجاد کنند که نگهداری، اشکال‌زدایی و گسترش آن‌ها در طول زمان آسان‌تر باشد. این رویکرد ممکن است در ابتدا به تلاش بیشتری نیاز داشته باشد اما در کاهش پیچیدگی بلندمدت و بهبود بهره‌وری تیمی نتیجه می‌دهد.
آخرین به‌روزرسانی::
نقد و بررسی
کتاب فلسفه طراحی نرم‌افزار، ویرایش دوم نقدهای متفاوتی دریافت کرده است. بسیاری از خوانندگان از دیدگاه‌های آن در مدیریت پیچیدگی و طراحی ماژول‌های عمیق تمجید می‌کنند، در حالی که برخی دیگر به تأکید آن بر نظرات و کمبود عمق در برخی زمینه‌ها انتقاد دارند. خوانندگان از نگارش واضح و توصیه‌های عملی آن، به‌ویژه برای توسعه‌دهندگان تازه‌کار، قدردانی می‌کنند. با این حال، برخی برنامه‌نویسان با تجربه آن را بیش از حد ابتدایی می‌دانند یا با برخی توصیه‌ها موافق نیستند. تمرکز کتاب بر برنامه‌نویسی شیءگرا و دیدگاه آکادمیک آن مورد توجه قرار گرفته است، و برخی خواهان مثال‌های زبانی متنوع‌تر و کاربردهای واقعی بیشتری هستند.
Similar Books
