طراحی نرمافزار رو چطور یاد بگیریم؟
خلاصهٔ کاملتر
نویسنده این مطلب — که سابقه کار روی پروژههایی مثل IntelliJ Rust و rust-analyzer داره — در جواب به یه فیزیکدان پژوهشگر، سه دیدگاه جالب درباره یادگیری طراحی نرمافزار مطرح میکنه.
اول: تجربه از کتاب مهمتره. کلاسهای دانشگاهی «طراحی نرمافزار» عمدتاً نمایشی هستن، نه واقعی. چیزی که واقعاً یاد میدی اینه که مستقیم با مشکلات طراحی دستوپنجه نرم کنی. خبر خوب اینه که مهندسی نرمافزار بهقدری قابلفهمه که یه ذهن کنجکاو میتونه خیلی از اصولش رو خودش کشف کنه.
دوم: قانون Conway. این قانون میگه که معماری نرمافزار آینه ساختار اجتماعی تیمیه که اون رو میسازه. «کد علمی» که کیفیتش پایینه، اغلب نه بهخاطر بیسوادی نویسندهاش، بلکه بهخاطر ساختار انگیزشیایه که بهش فشار میآره. مثلاً «باید تا سه ماه دیگه مقاله چاپ بشه» یه انگیزه قوی برای نوشتن کد سریعالانتقاد اما ناپایداره.
نویسنده از تجربهاش با rust-analyzer مثال میزنه: برای جذب مشارکتکنندگان هفتهآخری که وقت محدود دارن، فیچرها رو از هم ایزوله کرد و هر کدوم رو با catch_unwind محافظت کرد تا کرش یه فیچر کل برنامه رو خراب نکنه. در عوض، روی هسته اصلی پروژه خیلی دقیقتر بود. این یعنی معماری نرمافزار عمداً با واقعیت اجتماعی تیم هماهنگ شده بود.
سوم: منابع پیشنهادی. نویسنده صادقانه میگه هیچ کتاب جامعی که «همه حقیقت» رو داشته باشه وجود نداره، ولی این منابع رو پیشنهاد میکنه:
- سخنرانی Boundaries از Gary Bernhardt
- مقاله How to Test از خود نویسنده
- راهنمای ∅MQ و نوشتههای Pieter Hintjens درباره قانون Conway
- Reflections on a decade of coding از Jamii
- وبلاگ Ted Kaminski بهعنوان نزدیکترین چیز به یه نظریه منسجم از توسعه نرمافزار
- کتابهای Software Engineering at Google و The Philosophy of Software Design اوسترهاوت هم خوبن، اما برای نویسنده انقلابی نبودن.
نکات کلیدی:
- طراحی نرمافزار رو باید با انجام دادن یاد گرفت، نه فقط خواندن
- قانون Conway: ساختار تیم، معماری کد رو شکل میده
- «کد علمی» بد اغلب محصول فشار زمانی و انگیزههای اشتباهه، نه جهل فنی
- اگه نمیتونی ساختار انگیزشی رو عوض کنی، بهش adapt کن — مثل ایزولهسازی فیچرها در rust-analyzer
- هیچ کتاب واحدی همه پاسخها رو نداره؛ تمرین جزء جداییناپذیر یادگیریه
