دسترسی نامحدود
برای کاربرانی که ثبت نام کرده اند
برای ارتباط با ما می توانید از طریق شماره موبایل زیر از طریق تماس و پیامک با ما در ارتباط باشید
در صورت عدم پاسخ گویی از طریق پیامک با پشتیبان در ارتباط باشید
برای کاربرانی که ثبت نام کرده اند
درصورت عدم همخوانی توضیحات با کتاب
از ساعت 7 صبح تا 10 شب
ویرایش: Repr. with corr نویسندگان: Coplien. James O., Bjørnvig. Gertrud سری: ISBN (شابک) : 9780470684207, 0470684208 ناشر: Wiley سال نشر: 2011;2014 تعداد صفحات: 0 زبان: English فرمت فایل : EPUB (درصورت درخواست کاربر به PDF، EPUB یا AZW3 تبدیل می شود) حجم فایل: 6 مگابایت
کلمات کلیدی مربوط به کتاب معماری ناب: برای توسعه نرم افزار چابک: معماری کامپیوتر، نرم افزار کامپیوتر - توسعه، توسعه نرم افزار چابک، نرم افزار کامپیوتر - توسعه
در صورت تبدیل فایل کتاب Lean architecture: for agile software development به فرمت های PDF، EPUB، AZW3، MOBI و یا DJVU می توانید به پشتیبان اطلاع دهید تا فایل مورد نظر را تبدیل نمایند.
توجه داشته باشید کتاب معماری ناب: برای توسعه نرم افزار چابک نسخه زبان اصلی می باشد و کتاب ترجمه شده به فارسی نمی باشد. وبسایت اینترنشنال لایبرری ارائه دهنده کتاب های زبان اصلی می باشد و هیچ گونه کتاب ترجمه شده یا نوشته شده به فارسی را ارائه نمی دهد.
پروژههای Agile بیشتر و بیشتر به دنبال ریشههای معماری هستند زیرا با پیچیدگی و مقیاس مبارزه میکنند - و آنها به دنبال راههای سبک وزن برای انجام آن هستند هنوز به دنبال آن هستید؟ در این کتاب، نویسندگان به شما کمک میکنند تا مسیر خود را پیدا کنید. مطمئن. شما می توانید یک معماری را به عنوان کد ارائه دهید که کامپایل می کند و به طور مشخص توسعه را هدایت می کند بدون اینکه آن را در انبوهی از اسناد و حدس هایی در مورد مستندات پیاده سازی درگیر کنید؟ حتی یک نمودار تخته سفید، یا یک کارت CRC، مستندسازی است: هدف اجتناب از مستندسازی نیست، بلکه مستند کردن چیزهای مناسب با مقدار مناسب فرآیند است؟ همه اینها در چارچوب های Scrum، XP و سایر رویکردهای Agile کار می کنند
More and more Agile projects are seeking architectural roots as they struggle with complexity and scale - and they're seeking lightweight ways to do it Still seeking? In this book the authors help you to find your own path Taking cues from Lean development, they can help steer your project toward practices with longstanding track records Up-front architecture? Sure. You can deliver an architecture as code that compiles and that concretely guides development without bogging it down in a mass of documents and guesses about the implementation Documentation? Even a whiteboard diagram, or a CRC card, is documentation: the goal isn't to avoid documentation, but to document just the right things in just the right amount Process? This all works within the frameworks of Scrum, XP, and other Agile approaches
Content: About the Authors. Preface. 1 Introduction. 1.1 The Touchstones: Lean and Agile. 1.2 Lean Architecture and Agile Feature Development. 1.3 Agile Production. 1.4 The Book in a Very Small Nutshell. 1.5 Lean and Agile: Contrasting and Complementary. 1.6 Lost Practices. 1.7 What this Book is Not About. 1.8 Agile, Lean ? Oh, Yeah, and Scrum and Methodologies and Such. 1.9 History and Such. 2 Agile Production in a Nutshell. 2.1 Engage the Stakeholders. 2.2 Define the Problem. 2.3 Focusing on What the System Is: The Foundations of Form. 2.4 Focusing on What the System Does: The System Lifeblood. 2.5 Design and Code. 2.6 Countdown: 3, 2, 1... 3 Stakeholder Engagement. 3.1 The Value Stream. 3.2 The Key Stakeholders. 3.3 Process Elements of Stakeholder Engagement. 3.4 The Network of Stakeholders: Trimming Wasted Time. 3.5 No Quick Fixes, but Some Hope. 4 Problem Definition. 4.1 What's Agile about Problem Definitions? 4.2 What's Lean about Problem Definitions? 4.3 Good and Bad Problem Definitions. 4.4 Problems and Solutions. 4.5 The Process Around Problem Definitions. 4.6 Problem Definitions, Goals, Charters, Visions, and Objectives. 4.7 Documentation? 5 What the System Is, Part 1: Lean Architecture. 5.1 Some Surprises about Architecture. 5.2 The First Design Step: Partitioning. 5.3 The Second Design Step: Selecting a Design Style. 5.4 Documentation? 5.5 History and Such. 6 What the System Is, Part 2: Coding It Up. 6.1 The Third Step: The Rough Framing of the Code. 6.2 Relationships in Architecture. 6.3 Not Your Old Professor's OO. 6.4 How much Architecture? 6.5 Documentation? 6.6 History and Such. 7 What the System Does: System Functionality. 7.1 What the System Does. 7.2 Who is Going to Use Our Software? 7.3 What do the Users Want to Use Our Software for? 7.4 Why Does the User Want to Use Our Software? 7.5 Consolidation of What the System Does. 7.6 Recap. 7.7 "It Depends": When Use Cases are a Bad Fit. 7.8 Usability Testing. 7.9 Documentation? 7.10 History and Such. 8 Coding It Up: Basic Assembly. 8.1 The Big Picture: Model-View-Controller-User. 8.2 The Form and Architecture of Atomic Event Systems. 8.3 Updating the Domain Logic: Method Elaboration, Factoring, and Re-factoring. 8.4 Documentation? 8.5 Why All These Artifacts? 8.6 History and Such. 9 Coding it Up: The DCI Architecture. 9.1 Sometimes, Smart Objects Just Aren?t Enough. 9.2 DCI in a Nutshell. 9.3 Overview of DCI. 9.4 DCI by Example. 9.5 Updating the Domain Logic. 9.6 Context Objects in the User Mental Model: Solution to an Age-Old Problem. 9.7 Why All These Artifacts? 9.8 Beyond C++: DCI in Other Languages. 9.9 Documentation? 9.10 History and Such. 10 Epilog. Appendix A Scala Implementation of the DCI Account Example. Appendix B Account Example in Python. Appendix C Account Example in C#. Appendix D Account Example in Ruby. Appendix E Qi4j. Appendix F Account Example in Squeak. F.1 Testing Perspective. F.2 Data Perspective. F.3 Context Perspective. F.4 Interaction (RoleTrait) Perspective. F.5 Support Perspective (Infrastructure Classes). Bibliography. Index.