برای ارتباط با ما می توانید از طریق شماره موبایل زیر از طریق تماس و پیامک با ما در ارتباط باشید

09117307688
09117179751

در صورت عدم پاسخ گویی از طریق پیامک با پشتیبان در ارتباط باشید

دسترسی نامحدود

برای کاربرانی که ثبت نام کرده اند

ضمانت بازگشت وجه

درصورت عدم همخوانی توضیحات با کتاب

پشتیبانی

از ساعت 7 صبح تا 10 شب

دانلود کتاب Extreme Programming Refactored: The Case Against XP

دانلود کتاب برنامه نویسی افراطی Refactished: پرونده علیه XP

مشخصات کتاب

Extreme Programming Refactored: The Case Against XP

دسته بندی: برنامه نويسي
ویرایش: 1 
نویسندگان: Matt Stephens. Doug Rosenberg  
سری:  
ISBN (شابک) : 9781590590966, 1590590961 
ناشر: Apress 
سال نشر: 2003 
تعداد صفحات: 0 
زبان: English 
فرمت فایل : CHM (درصورت درخواست کاربر به PDF، EPUB یا AZW3 تبدیل می شود) 
حجم فایل: 4 مگابایت

قیمت کتاب (تومان) : 31,000

میانگین امتیاز به این کتاب :
تعداد امتیاز دهندگان : 11

در صورت تبدیل فایل کتاب Extreme Programming Refactored: The Case Against XP به فرمت های PDF، EPUB، AZW3، MOBI و یا DJVU می توانید به پشتیبان اطلاع دهید تا فایل مورد نظر را تبدیل نمایند.

توجه داشته باشید کتاب برنامه نویسی افراطی Refactished: پرونده علیه XP نسخه زبان اصلی می باشد و کتاب ترجمه شده به فارسی نمی باشد. وبسایت اینترنشنال لایبرری ارائه دهنده کتاب های زبان اصلی می باشد و هیچ گونه کتاب ترجمه شده یا نوشته شده به فارسی را ارائه نمی دهد.

توضیحاتی در مورد کتاب برنامه نویسی افراطی Refactished: پرونده علیه 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