دانلود کتاب Extreme Programming Refactored: The Case Against XP
49,000 تومان
Extreme Programming Refactored: The Case Against XP
| موضوع اصلی | برنامه نویسی |
|---|---|
| نوع کالا | کتاب الکترونیکی |
| ناشر | Apress |
| تعداد صفحه | 432 |
| حجم فایل | 4 مگابایت |
| کد کتاب | 9781590590966,1590590961 |
| نوبت چاپ | 1 |
| نویسنده | Doug Rosenberg, Matt Stephens |
|---|---|
| زبان | انگلیسی |
| فرمت | CHM |
| سال انتشار | 2003 |
جدول کد تخفیف
| تعداد کتاب | درصد تخفیف | قیمت کتاب |
| 1 | بدون تخفیف | 25,000 تومان |
| 2 | 20 درصد | 20,000 تومان |
| 3 الی 5 | 25 درصد | 18,750 تومان |
| 6 الی 10 | 30 درصد | 17,500 تومان |
| 11 الی 20 | 35 درصد | 16,250 تومان |
| 21 الی 30 | 40 درصد | 15,000 تومان |
| 31 الی 40 | 45 درصد | 13,750 تومان |
| 41 الی 50 | 50 درصد | 12,500 تومان |
| 51 الی 70 | 55 درصد | 11,250 تومان |
| 71 الی 100 | 60 درصد | 10,000 تومان |
| 101 الی 150 | 65 درصد | 8,750 تومان |
| 151 الی 200 | 70 درصد | 7,500 تومان |
| 201 الی 300 | 75 درصد | 6,250 تومان |
| 301 الی 500 | 80 درصد | 5,000 تومان |
| 501 الی 1000 | 85 درصد | 3,750 تومان |
| 1001 الی 10000 | 90 درصد | 2,500 تومان |
ترجمه فارسی توضیحات (ترجمه ماشینی)
Extreme Programming Refactored: The Case Against XP
[بازبینی شده توسط عضو XPSD Sunitha Dangeti]
پس از تمرین XP، من به خصوص دو فصل در این کتاب را دوست دارم، یکی در مورد XP در یک nuthouse که خواندن خوبی برای افرادی است که در XP تازه کار هستند تا درک سریعی از مفهوم XP داشته باشند و فصل بعدی فصل در مورد XP Refactored است. که در آن نویسندگان به ویژگیهای خوب XP به همراه بهترین روشهای اضافه شده و ایدههایی که ممکن است XP را بهتر کنند اشاره میکنند.
این کتاب یک دیدگاه افراطی از برنامه نویسی افراطی است. نویسندگان تقریباً از هر جنبه ای از برنامه نویسی Extreme انتقاد کرده اند. هر توسعهدهندهای که به دنبال پیروی از روششناسی باشد، اگر ابتدا به این کتاب برخورد کند، از انجام این کار منصرف میشود.
آنها موضع بسیار سفت و سختی در مورد refactoring اتخاذ میکنند، و به گونهای تصور میکنند که برنامهنویسان XP بدون هیچ دلیل موجهی در یک دیوانگی دائمی برای بازسازی مجدد هستند. عدم طراحی اولیه به عنوان مسئول بسیاری از دوباره کاری ها اشاره شده است. انتشار زودهنگام، انتشار اغلب مفهومی نشان داده است که نگرانی توسعهدهنده را افزایش میدهد که آیا در سیستم ادغام میشود و همه آزمایشها را برآورده میکند یا خیر.
آنها اشاره می کنند که XP مقیاس پذیر نیست و فقط برای پروژه های کوچک مناسب است. اگرچه بیشتر پروژههای XP کوچک هستند، اما میدانم که عبارت فوق کاملاً درست نیست، زیرا داستان موفقیت یک پروژه بزرگ را شنیدم که در حال مهاجرت بود و ضربالاجل تولید سختگیری برای انجام آن داشت.
نویسندگان نمونههایی را از نمونههایی انتخاب کردند که کدنویسها به موقعیتها رسیدگی نمیکردند. به عنوان مثال، آنها در مورد تست های واحد اظهار نظر می کنند و می گویند که تست های واحد در XP به تنهایی هستند و اغلب پایگاه داده ها را کثیف می کنند. توسعهدهنده در آن نمونه ممکن است عبارات بازگشتی را در آزمایش نداشته باشد، به همین دلیل است که پایگاه داده کثیف مانده است و از این رو این یک نقص در متدولوژی XP نیست، بلکه یک نقص در نحوه پیادهسازی آن است.
در پایان کتاب، نویسندگان XP را بازسازی کرده و مزایا و معایب هر یک از مؤلفههای XP را مشخص میکنند که در آن به نکات زیر اشاره میکنند:
* برنامه نویسی زوجی نباید ثابت یا اجباری باشد
* برنامه نویسان باید طراحی کنند
* برنامه نویسان باید تست های خود را بنویسند
* به جای طراحی مستمر، باید از طراحی مکرر پیروی کنیم
* هفته های 40 ساعته امکان پذیر نیست زیرا گاهی اوقات توسعه دهندگان مجبورند برای رعایت ضرب الاجل ها اضافه کاری کنند
* کدنویسی، آزمایش، گوش دادن و طراحی XP ارزش نجات دادن دارد
* تکرارها باید یک ماه باشد
* طرح اول تست باید طرح را تکمیل کند اما نباید آن را هدایت کند
* از ترکیبی از الزامات و موارد استفاده به جای داستان های کاربری استفاده کنید
* سرعت پروژه باید بر اساس الزامات رسمی تکمیل شده در هر تکرار اندازه گیری شود تا داستان های کاربر در هر تکرار
به طور کلی، فکر میکردم که خواندن آن نسبتاً خوب اما سریع برای من بود
[Reviewed by XPSD member Sunitha Dangeti]
Having practiced XP, I particularly like two chapters in this book, one on XP in a nuthouse which is a good read for someone who is new to XP to get a quick understanding of the XP concept and the next one is the chapter on XP refactored in which the authors point out good features of XP along with their own best practices added and ideas that may make XP better.
This book is an extreme view of Extreme programming. The authors have criticized almost every aspect of Extreme programming. Any developer thinking of following the methodology would be discouraged to do so if they came across this book first.
They take a very rigid stand on refactoring, picturing as if XP programmers are in a constant refactoring frenzy for no good reason. Lack of initial design has been pointed out as being responsible for lot of rework. Release early, release often concept has been shown to increase the developer’s concern of whether it will integrate into the system and satisfy all the tests or not.
They point out that XP is not scalable and is only suitable for small projects. Though most of the XP projects are small, I know the above statement is not entirely true as I heard a success story of a big project which was migrating and had a strict production deadline to meet which it did.
The authors picked examples from instances where the coders did not take care of situations. For example, they comment on unit tests saying that unit tests are stand alone in XP and often left databases dirty. The developer in that instance may not have had roll back statements in the test which is why the database was left dirty and hence it is not a flaw with XP methodology but a flaw with the way it was implemented.
By the end of the book, the authors refactor XP and delineate the pros and cons of each XP component in which they mention the following points:
* Pair programming should not be constant or mandatory
* Programmers should design
* Programmers should write their own tests
* Instead of continuous design, we should follow frequent design
* 40 hr weeks are not feasible as sometimes developers have to work overtime to meet deadlines
* Coding, testing, listening and designing of XP are worth salvaging
* Iterations should be one month long
* Test first design should complement the design but should not drive it
* Use a combination of requirements and use cases instead of user stories
* Project velocity should be measured in terms of formal requirements completed per iteration rather than user stories per iteration
Overall, I thought it was a fairly good though quick read for me
برای فرستادن دیدگاه، باید وارد شده باشید.
نقد و بررسیها
هنوز بررسیای ثبت نشده است.