حالت تاریک
راهنمای مرجع سریع
نکات ۱ تا ۲۲
| # | عنوان | توضیح | صفحه |
|---|---|---|---|
| 1 | به craft خود اهمیت دهید | چرا باید عمرتان را صرف توسعهٔ نرمافزار کنید مگر اینکه به انجام خوب آن اهمیت دهید؟ | xix |
| 2 | فکر کنید! دربارهٔ کارتان | حالت خودکار را خاموش کنید و کنترل را به دست بگیرید. پیوسته کار خود را نقد و ارزیابی کنید. | xix |
| 3 | گزینه ارائه دهید، بهانهسازی نکنید | بهجای بهانه، گزینه ارائه دهید. نگویید نمیشود انجام داد؛ توضیح دهید چه کاری میتوان انجام داد. | 3 |
| 4 | با پنجرههای شکسته زندگی نکنید | وقتی طراحی بد، تصمیم اشتباه و کد ضعیف میبینید، آن را اصلاح کنید. | 5 |
| 5 | کاتالیزور تغییر باشید | نمیتوانید تغییر را به زور بر مردم تحمیل کنید. در عوض، آیندهٔ ممکن را به آنها نشان دهید و در ساختنش مشارکتشان دهید. | 8 |
| 6 | تصویر بزرگ را به یاد داشته باشید | آنقدر در جزئیات غرق نشوید که فراموش کنید اطرافتان چه میگذرد. | 8 |
| 7 | کیفیت را یک مسئلهٔ نیازمندی کنید | کاربران را در تعیین نیازمندیهای واقعی کیفیت پروژه دخیل کنید. | 11 |
| 8 | بهطور منظم در سبد دانش خود سرمایهگذاری کنید | یادگیری را به عادت تبدیل کنید. | 14 |
| 9 | آنچه میخوانید و میشنوید را با نقد تحلیل کنید | تحت تأثیر فروشندگان، هیاهوی رسانهای یا عقاید مسلم قرار نگیرید. اطلاعات را در بستر خودتان و پروژهتان تحلیل کنید. | 16 |
| 10 | هم آنچه میگویید مهم است و هم نحوهٔ گفتنش | اگر نتوانید ایدههای عالیتان را مؤثر منتقل کنید، فایدهای ندارند. | 21 |
| 11 | DRY — تکرار نکنید (Don't Repeat Yourself) | هر قطعه دانش باید یک بازنمایی واحد، بدون ابهام و معتبر در یک سیستم داشته باشد. | 27 |
| 12 | استفاده مجدد را آسان کنید | اگر استفاده مجدد آسان باشد، مردم انجام میدهند. محیطی بسازید که از استفاده مجدد پشتیبانی کند. | 33 |
| 13 | اثرات بین چیزهای نامرتبط را حذف کنید | اجزایی طراحی کنید که خودکفا، مستقل و با یک هدف واحد و بهخوبی تعریفشده باشند. | 35 |
| 14 | تصمیم نهایی وجود ندارد | هیچ تصمیمی در سنگ حک نشده. هر تصمیم را مثل نوشتهای روی شن ساحل ببینید و برای تغییر برنامهریزی کنید. | 46 |
| 15 | از گلولههای ردیاب برای یافتن هدف استفاده کنید | گلولههای ردیاب با امتحان کردن و دیدن اینکه چقدر به هدف نزدیک میافتند، کمک میکنند روی هدف قفل کنید. | 49 |
| 16 | برای یادگیری نمونه اولیه بسازید | نمونهسازی اولیه تجربهٔ یادگیری است. ارزش آن در کدی که تولید میکنید نیست، بلکه در درسهایی است که میگیرید. | 54 |
| 17 | نزدیک حوزهٔ مسئله برنامهنویسی کنید | به زبان کاربر طراحی و کد بنویسید. | 58 |
| 18 | برای جلوگیری از غافلگیری تخمین بزنید | قبل از شروع تخمین بزنید. مشکلات بالقوه را از همان ابتدا میبینید. | 64 |
| 19 | زمانبندی را با کد تکرار کنید | از تجربهای که در حین پیادهسازی به دست میآورید برای پالایش مقیاسهای زمانی پروژه استفاده کنید. | 69 |
| 20 | دانش را در متن ساده نگه دارید | متن ساده منسوخ نمیشود. به بهرهبرداری از کار شما کمک میکند و اشکالزدایی و آزمایش را ساده میکند. | 74 |
| 21 | از قدرت پوستههای فرمان استفاده کنید | وقتی رابطهای گرافیکی کارساز نیستند، از پوسته استفاده کنید. | 80 |
| 22 | یک ویرایشگر را خوب بشناسید | ویرایشگر باید تمدید دست شما باشد؛ مطمئن شوید قابل پیکربندی، قابل گسترش و قابل برنامهنویسی است. | 82 |
نکات ۲۳ تا ۴۶
| # | عنوان | توضیح | صفحه |
|---|---|---|---|
| 23 | همیشه از کنترل کد منبع استفاده کنید | کنترل کد منبع ماشین زمان برای کار شماست — میتوانید به عقب برگردید. | 88 |
| 24 | مشکل را رفع کنید، نه سرزنش را | مهم نیست باگ تقصیر شماست یا کس دیگر — همچنان مشکل شماست و باید رفع شود. | 91 |
| 25 | هنگام اشکالزدایی وحشت نکنید | نفس عمیق بکشید و فکر کنید! دربارهٔ آنچه ممکن است باعث باگ شده باشد. | 91 |
| 26 | «select» خراب نیست | یافتن باگ در سیستمعامل یا کامپایلر، یا حتی محصول یا کتابخانهٔ شخص ثالث، نادر است. باگ به احتمال زیاد در برنامه است. | 96 |
| 27 | فرض نکنید — ثابت کنید | فرضیات خود را در محیط واقعی — با داده و شرایط مرزی واقعی — ثابت کنید. | 97 |
| 28 | یک زبان دستکاری متن یاد بگیرید | بخش بزرگی از هر روز را با متن کار میکنید. چرا بخشی از آن را به رایانه نسپارید؟ | 100 |
| 29 | کدی بنویسید که کد بنویسد | مولدهای کد بهرهوری شما را بالا میبرند و از تکرار جلوگیری میکنند. | 103 |
| 30 | نمیتوانید نرمافزار کامل بنویسید | نرمافزار نمیتواند کامل باشد. کد و کاربران را از خطاهای اجتنابناپذیر محافظت کنید. | 107 |
| 31 | با قرارداد طراحی کنید | از قراردادها برای مستندسازی و تأیید اینکه کد نه بیشتر و نه کمتر از آنچه ادعا میکند انجام میدهد، استفاده کنید. | 111 |
| 32 | زود خراب شو | برنامهٔ مرده معمولاً خیلی کمتر از برنامهٔ ناقص آسیب میزند. | 120 |
| 33 | با assertionها از غیرممکن جلوگیری کنید | assertionها فرضیات شما را اعتبارسنجی میکنند. از آنها برای محافظت کد در برابر دنیای نامطمئن استفاده کنید. | 122 |
| 34 | از استثنا برای مشکلات استثنایی استفاده کنید | استثناها میتوانند از همهٔ مشکلات خوانایی و نگهداری کد اسپاگتی کلاسیک رنج ببرند. استثنا را برای موارد استثنایی نگه دارید. | 127 |
| 35 | کاری را که شروع میکنی تمام کن | تا جایی که ممکن است، روتین یا شیئی که منبعی را تخصیص میدهد باید مسئول آزادسازی آن باشد. | 129 |
| 36 | جفتشدگی بین ماژولها را کمینه کنید | با نوشتن کد «خجالتی» و اعمال قانون Demeter از جفتشدگی اجتناب کنید. | 140 |
| 37 | پیکربندی کنید، یکپارچه نکنید | انتخابهای فناوری برای یک برنامه را بهصورت گزینههای پیکربندی پیاده کنید، نه از طریق یکپارچهسازی یا مهندسی. | 144 |
| 38 | انتزاعها را در کد بگذارید، جزئیات را در متادیتا | برای حالت کلی برنامهنویسی کنید و جزئیات را خارج از پایگاه کد کامپایلشده بگذارید. | 145 |
| 39 | گردشکار را برای بهبود همزمانی تحلیل کنید | همزمانی را در گردشکار کاربر بهره ببرید. | 151 |
| 40 | با سرویسها طراحی کنید | بر اساس سرویسها — اشیای مستقل و همزمان پشت رابطهای بهخوبی تعریفشده و سازگار — طراحی کنید. | 154 |
| 41 | همیشه برای همزمانی طراحی کنید | برای همزمانی برنامهریزی کنید و رابطهای تمیزتری با فرضیات کمتر طراحی خواهید کرد. | 156 |
| 42 | نماها را از مدلها جدا کنید | با طراحی برنامه بر اساس مدلها و نماها، با هزینهٔ کم انعطاف بگیرید. | 161 |
| 43 | از تختهسیاه برای هماهنگی گردشکار استفاده کنید | از تختهسیاه برای هماهنگی حقایق و عاملهای گوناگون استفاده کنید، در حالی که استقلال و جداسازی شرکتکنندگان حفظ میشود. | 169 |
| 44 | تصادفی برنامهنویسی نکنید | فقط به چیزهای قابل اعتماد تکیه کنید. از پیچیدگی تصادفی بترسید و تصادف خوشیمن را با برنامهٔ هدفمند اشتباه نگیرید. | 175 |
| 45 | درجه الگوریتمهایتان را تخمین بزنید | قبل از نوشتن کد، حس کنید کارها احتمالاً چقدر طول میکشند. | 181 |
| 46 | تخمینهایتان را آزمایش کنید | تحلیل ریاضی الگوریتمها همه چیز را نمیگوید. کد را در محیط هدف زمانسنجی کنید. | 182 |
نکات ۴۷ تا ۷۰
| # | عنوان | توضیح | صفحه |
|---|---|---|---|
| 47 | زود بازسازی کنید، مکرر بازسازی کنید | همانطور که باغ را علفهرز میکنید و مرتب میکنید، وقتی لازم است کد را بازنویسی، بازکار و بازمعماری کنید. ریشهٔ مشکل را رفع کنید. | 186 |
| 48 | برای آزمایش طراحی کنید | قبل از نوشتن یک خط کد، به آزمایش فکر کنید. | 192 |
| 49 | نرمافزارتان را آزمایش کنید، وگرنه کاربران شما خواهند کرد | بیرحمانه آزمایش کنید. باگها را به کاربران واگذار نکنید. | 197 |
| 50 | از کد جادوگری که نمیفهمید استفاده نکنید | جادوگرها میتوانند انبوهی کد تولید کنند. قبل از گنجاندن در پروژه، مطمئن شوید همهٔ آن را میفهمید. | 199 |
| 51 | نیازمندی جمع نکنید — برایشان بکنید | نیازمندیها بهندرت روی سطحند. زیر لایههایی از فرضیات، سوءبرداشت و سیاست مدفوناند. | 202 |
| 52 | با یک کاربر کار کنید تا مثل کاربر فکر کنید | بهترین راه برای فهمیدن اینکه سیستم واقعاً چگونه استفاده میشود. | 204 |
| 53 | انتزاعها از جزئیات بیشتر عمر میکنند | در انتزاع سرمایهگذاری کنید، نه پیادهسازی. انتزاعها میتوانند از موج تغییرات پیادهسازیها و فناوریهای جدید جان سالم به در ببرند. | 209 |
| 54 | از واژهنامه پروژه استفاده کنید | یک منبع واحد از همهٔ اصطلاحات و واژگان خاص پروژه بسازید و نگه دارید. | 210 |
| 55 | خارج از جعبه فکر نکنید — جعبه را پیدا کنید | وقتی با مسئلهای غیرممکن روبهرو شدید، محدودیتهای واقعی را شناسایی کنید. از خود بپرسید: «آیا باید اینطور انجام شود؟ آیا اصلاً باید انجام شود؟» | 213 |
| 56 | وقتی آمادهاید شروع کنید | تمام عمرتان تجربه ساختهاید. شکهای مزاحم را نادیده نگیرید. | 215 |
| 57 | بعضی چیزها بهتر است انجام شوند تا توصیف | در مارپیچ مشخصات نیفتید — در یک نقطه باید شروع به کدنویسی کنید. | 218 |
| 58 | برده روشهای رسمی نباشید | هیچ تکنیکی را بدون قرار دادن در بستر شیوهها و تواناییهای توسعهٔ خودتان کورکورانه نپذیرید. | 220 |
| 59 | ابزار گران طراحی بهتر تولید نمیکند | از هیاهوی فروشندگان، عقاید مسلم صنعت و هالهٔ برچسب قیمت بترسید. ابزارها را بر اساس شایستگیشان قضاوت کنید. | 222 |
| 60 | بر اساس عملکرد سازماندهی کنید، نه نقش شغلی | طراحان را از کدنویسان، آزمایشگران را از مدلسازان داده جدا نکنید. تیمها را همانطور که کد میسازید بسازید. | 227 |
| 61 | از رویههای دستی استفاده نکنید | یک اسکریپت پوسته یا فایل batch همان دستورالعملها را به همان ترتیب، بار پس از بار اجرا میکند. | 231 |
| 62 | زود آزمایش کنید. زیاد آزمایش کنید. خودکار آزمایش کنید. | آزمونهایی که با هر ساخت اجرا میشوند خیلی مؤثرتر از برنامههای آزمایشیاند که روی قفسه میمانند. | 237 |
| 63 | کدنویسی تمام نشده تا همهٔ آزمونها اجرا نشوند | بس است. | 238 |
| 64 | از خرابکار برای آزمون آزمونهایتان استفاده کنید | عمداً در یک کپی جدا از کد منبع باگ وارد کنید تا تأیید کنید آزمایش آنها را میگیرد. | 244 |
| 65 | پوشش حالت را آزمایش کنید، نه پوشش کد | حالتهای مهم برنامه را شناسایی و آزمایش کنید. فقط آزمایش خطوط کد کافی نیست. | 245 |
| 66 | باگ را یکبار پیدا کنید | وقتی یک آزمایشگر انسانی باگی پیدا کرد، باید آخرین باری باشد که انسان آن باگ را پیدا میکند. از آن پس آزمونهای خودکار باید آن را بررسی کنند. | 247 |
| 67 | انگلیسی را فقط یک زبان برنامهنویسی دیگر بدانید | اسناد را مثل کد بنویسید: اصل DRY را رعایت کنید، از متادیتا، MVC، تولید خودکار و غیره استفاده کنید. | 248 |
| 68 | مستندات را بسازید، نه بعداً الحاق کنید | مستنداتی که جدا از کد ساخته میشود کمتر احتمال دارد درست و بهروز باشد. | 248 |
| 69 | بهآرامی انتظارات کاربران را فراتر ببرید | انتظارات کاربران را بفهمید، سپس کمی بیشتر تحویل دهید. | 255 |
| 70 | کار خود را امضا کنید | صنعتگران دوران گذشته به امضای کارشان افتخار میکردند. شما هم باید بکنید. | 258 |
فهرستهای بررسی
✔ زبانهایی برای یادگیری — صفحه ۱۷
از C، C++ و Java خسته شدهاید؟ CLOS، Dylan، Eiffel، Objective C، Prolog، Smalltalk یا TOM را امتحان کنید. هر کدام قابلیتها و «طعم» متفاوتی دارند. با یک یا چند تا از آنها یک پروژهٔ کوچک در خانه انجام دهید.
✔ آکروستیک WISDOM — صفحه ۲۰
| حرف | سؤال |
|---|---|
| W | میخواهید چه چیزی یاد بگیرند؟ |
| I | علاقهٔ آنها به آنچه میگویید چیست؟ |
| S | آنها چقدر پیچیده / حرفهای هستند؟ |
| D | چقدر جزئیات میخواهند؟ |
| O | میخواهید مالکیت اطلاعات در دست چه کسی باشد؟ |
| M | چگونه میتوانید آنها را به گوش دادن به شما تشویق کنید؟ |
✔ چگونه متعامدی را حفظ کنیم — صفحه ۳۴
- اجزای مستقل و بهخوبی تعریفشده طراحی کنید.
- کد را از هم جدا نگه دارید.
- از دادهٔ سراسری اجتناب کنید.
- توابع مشابه را بازسازی کنید.
✔ چیزهایی برای نمونهسازی — صفحه ۵۳
- معماری
- قابلیت جدید در یک سیستم موجود
- ساختار یا محتوای دادهٔ خارجی
- ابزارها یا اجزای شخص ثالث
- مسائل کارایی
- طراحی رابط کاربری
✔ سؤالات معماری — صفحه ۵۵
- آیا مسئولیتها بهخوبی تعریف شدهاند؟
- آیا همکاریها بهخوبی تعریف شدهاند؟
- آیا جفتشدگی کمینه شده است؟
- آیا میتوانید تکرار بالقوه را شناسایی کنید؟
- آیا تعاریف رابط و محدودیتها قابل قبولاند؟
- آیا ماژولها به دادهٔ مورد نیاز — وقتی لازم است — دسترسی دارند؟
✔ قانون Demeter برای توابع — صفحه ۱۴۱
متد یک شی فقط باید متدهای زیر را فراخوانی کند:
- خودش
- هر پارامتری که به آن داده شده
- اشیایی که خودش میسازد
- اجزای مؤلفه
✔ فهرست بررسی اشکالزدایی — صفحه ۹۸
- آیا مشکلی که گزارش شده نتیجهٔ مستقیم باگ زیرین است یا فقط علامت آن؟
- آیا باگ واقعاً در کامپایلر است؟ در سیستمعامل؟ یا در کد شما؟
- اگر این مشکل را با جزئیات به همکارتان توضیح دهید، چه میگویید؟
- اگر کد مشکوک آزمونهای واحدش را پاس کند، آیا آزمونها بهاندازهٔ کافی کاملاند؟ اگر آزمون واحد را با این داده اجرا کنید چه میشود؟
- آیا شرایطی که این باگ را ایجاد کرد در جای دیگری از سیستم هم وجود دارد؟
✔ چگونه آگاهانه برنامهنویسی کنیم — صفحه ۱۷۲
- از آنچه انجام میدهید آگاه باشید.
- با چشمبند کد ننویسید.
- از یک برنامه پیش بروید.
- فقط به چیزهای قابل اعتماد تکیه کنید.
- فرضیات خود را مستند کنید.
- فرضیات را همارز کد آزمایش کنید.
- تلاشتان را اولویتبندی کنید.
- بردهٔ تاریخ نباشید.
✔ چه وقت بازسازی کنیم — صفحه ۱۸۵
- وقتی نقض اصل DRY را کشف میکنید.
- وقتی چیزهایی پیدا میکنید که میتوانند متعامدتر باشند.
- وقتی دانش شما بهتر میشود.
- وقتی نیازمندیها تکامل مییابند.
- وقتی باید کارایی را بهبود دهید.
✔ بریدن گرهٔ گordion — صفحه ۲۱۲
وقتی مسائل غیرممکن را حل میکنید، از خود بپرسید:
- آیا راه آسانتری هست؟
- آیا مسئلهٔ درست را حل میکنم؟
- چرا این یک مشکل است؟
- چه چیزی آن را سخت میکند؟
- آیا باید اینطور انجامش دهم؟
- آیا اصلاً باید انجام شود؟
✔ جنبههای آزمایش — صفحه ۲۳۷
- آزمایش واحد
- آزمایش یکپارچگی
- اعتبارسنجی و تأیید
- اتمام منابع، خطاها و بازیابی
- آزمایش کارایی
- آزمایش قابلیت استفاده
- آزمایش خود آزمونها
فهرستهای بررسی از The Pragmatic Programmer، اثر Andrew Hunt و David Thomas.
مراجعه به www.pragmaticprogrammer.com.
حق نشر © ۲۰۰۰ Addison Wesley Longman, Inc.