Software Craftsmanship: The New Imperative (Paperback)
暫譯: 軟體工藝：新的必然性 (平裝本)

Pete McBreen

Software Craftsmanship: The New Imperative (Paperback)
  • 出版商: Addison Wesley
  • 出版日期: 2001-08-23
  • 售價: $1,100
  • 貴賓價: 9.5 折 $1,045
  • 語言: 英文
  • 頁數: 208
  • 裝訂: Paperback
  • ISBN: 0201733862
  • ISBN-13: 9780201733860
  • 相關分類: 軟體工程

    • 立即出貨 (庫存=1)

買這商品的人也買了...

商品描述

Table of Contents

Preface.

 

I. QUESTIONING SOFTWARE ENGINEERING.

 

 

1. Understanding Software Engineering.

The Paradox of Software Engineering.
The Modern Definition of Software Engineering.
Is Software Engineering a Good Choice for Your Project?


2. The Problems with Software Engineering.

Can Software Development Be Made Systematic and Quantified?
The Hazards of the Good Enough Software Approach.
What Is the Alternative to Software Engineering?


3. Understanding Software Development.

Software as Capital.
Does the Division of Labor Work for Software Development?
One Size Does Not Fit All.


4. Finding a Better Metaphor Than Software Engineering.

Finding a Better Metaphor Than Software Engineering.
The Craft of Software Development.
Parallels with Traditional Craftsmanship.
The Resurgence of the Craft of Software Development.
 

II. SOFTWARE CRAFTSMANSHIP.

 

 


5. Putting People Back into Software Development.

Craftsmanship Is About Getting Better at Software Development.
Craftsmanship Encourages Developers to Write Great Software.
A Call to Arms.


6. Craftsmanship Is the Opposite of Licensing.

Craftsmanship Is Personal.
Licensing Is an Illusion.
Craftsmanship Focuses on the Individual.
 

III. IMPLICATIONS OF SOFTWARE CRAFTSMANSHIP.

 

 


7. How Craftsmanship Affects the Users of Systems.

Software Craftsmanship Works Because Software Is Easy to Copy.
Craftsmen Have a Different Relationship with Their Users.
Great Software Deserves to Be Signed.
Craftsmen Need Demanding Users.
Software Craftsmanship Leads to Collaborative Development.


8. Customers Have a Different Relationship with Craftsmen.

Setting Realistic Delivery Dates.
Exposing the Fallacy of Good Enough Software.
Allowing Software Craftsmen to Take Credit for Their Work.
Start Exploiting the Difference in Productivity Between Developers.
But How Do We Know How Good a Developer Really Is?
Customers Make a Cost/Quality Trade-off When Choosing Craftsmen.
Customers Have Long Term Relationships with Software Craftsmen.
Customer Interests Are Aligned with the Interests of Software Craftsmen.


9. Managing Craftsmen.

Software Craftsmen Are Not Hired Hands.
Good Developers Are More Valuable Than Their Managers.
Software Craftsmen Have a Different Relationship with Their Managers,
Managing Great Developers Is a Pleasure and a Privilege.
Software Craftsmen Like Creating Applications.
Managing Software Craftsmen Is Different.
Software Craftsmen Push for What They Need.


10. Becoming a Software Craftsman.

Software Craftsmanship Is a Rejection of Narrow Specialization.
Craftsmanship Requires Dedication.
How Does a Person Become a Software Craftsman?
The Craft Tradition Has Endured for Centuries.


11. Mastering the Craft.

What Does a Master Software Craftsman Look Like?
Use Your Old-timers.
Mastery Implies the Use of Stable Technologies.
Developing Mastery Takes Time.
Mastery Implies Taking Responsibility for Passing on the Craft.


12. Apprentice Developers.

We Must Reverse the Decline in the Quality of Developer Training.
Becoming an Apprentice Is a Significant Step.
Apprenticeship Instills Lifelong Learning.
The Role of Apprentices.
An Apprenticeship Is a Significant Investment of Time and Energy.


13. Journeymen Developers.

Where Journeymen Fit in the Craft Tradition.
Journeymen Developers.
Journeymen Are Focused on Delivering Applications.
Journeymen Play a Key Role in Software Craftsmanship.
 

IV. REPOSITIONING SOFTWARE ENGINEERING.

 

 


14. Software Engineering Projects.

Software Engineering Is Designed for Large Systems Projects.
Software Engineering Projects Are Diverse and Varied.


15. Hazards of the Software Engineering Metaphor.

You Cannot Do Software Engineering on a Low Budget.
Software Engineering Encourages Scientific Management.
Software Factories: The Production Line for Software.
Reuse over Time Is Hazardous.
The Myth of the Standardized Software Development Process.
Software Engineering Forces Us to Forget the Individual.
We Need More Variety in Our Development Processes, Not Less.


16. Learning from Software Engineering.

Size and Complexity Matter.
Applications Need to Be Well Structured.
Change Can Be Expensive Unless You Allow for It.
Communication Inside the Team and with Users Is Crucial.
Producing Accurate Estimates Is Very Expensive.
 

V. WHAT TO DO ON MONDAY MORNING.

 

 


17. Experience— The Best Indicator of Project Success.

Choose Software Craftsmen Based on Their Reputations.
Evaluate Craftsmen Based on Their Reputations and Portfolio.
Auditioning a Software Craftsman.
Let Your Software Craftsman Pick the Rest of the Development Team.
Collaborative Development.
Avoid Bleeding-Edge Technology If At All Possible.
Paying for Experience.
Be Prepared to Be Amazed.
Design for Testing and Maintenance.
Think Applications, Not Projects.
Maintenance Teams Should Refuse to Accept Bad Applications.


18. Design for Maintenance.

Software Craftsmen Prefer Nonproprietary, Open Source Tools.
Great Software Is Global.
Software Craftsmen Need to Fight Back Against Planned Obsolescence.
Great Software Needs to Be Given a Great User Interface.
Maintainable Software Is Easy to Diagnose.
The Hazards of Outsourcing.
You Can Still Use Outside Craftsmen to Create Your Application.
Maintenance Is the Most Important Part of the Life of Any Application.
Not All Software Has to Be Maintainable.
Design for Testing and Maintenance Is Not Rocket Science.


19. Perpetual Learning.

Creating a Learning Environment.
Mastering the Craft of Software Development.
Choose Training Courses Very Carefully.
Encourage Your People to Be Visible in the Software Development Community.
Becoming a Reflective Practitioner.


Epilogue.
Acknowledgements.

商品描述(中文翻譯)

目錄

前言

I. 質疑軟體工程

1. 理解軟體工程
軟體工程的悖論
軟體工程的現代定義
軟體工程是否是您專案的好選擇？

2. 軟體工程的問題
軟體開發能否變得系統化和量化？
足夠好的軟體方法的危險
軟體工程的替代方案是什麼？

3. 理解軟體開發
軟體作為資本
勞動分工對軟體開發是否有效？
一刀切並不適用於所有情況。

4. 尋找比軟體工程更好的隱喻
尋找比軟體工程更好的隱喻
軟體開發的工藝
與傳統工藝的平行
軟體開發工藝的復興

II. 軟體工藝

5. 將人重新帶入軟體開發
工藝是關於在軟體開發中變得更好
工藝鼓勵開發者編寫優秀的軟體
召喚行動。

6. 工藝與授權的對立
工藝是個人的
授權是一種幻覺
工藝專注於個體。

III. 軟體工藝的含義

7. 工藝如何影響系統的使用者
軟體工藝之所以有效，是因為軟體易於複製
工匠與其使用者之間的關係不同
優秀的軟體值得簽名
工匠需要挑剔的使用者
軟體工藝促進協作開發。

8. 客戶與工匠之間的不同關係
設定現實的交付日期
揭示足夠好的軟體的謬誤
允許軟體工匠為他們的工作獲得榮譽
開始利用開發者之間的生產力差異
但我們如何知道一位開發者的真正能力？
客戶在選擇工匠時會進行成本/質量的權衡
客戶與軟體工匠之間有長期的關係
客戶的利益與軟體工匠的利益是一致的。

9. 管理工匠
軟體工匠不是僱用的手
優秀的開發者比他們的經理更有價值
軟體工匠與他們的經理之間的關係不同
管理優秀的開發者是一種樂趣和特權
軟體工匠喜歡創建應用程式
管理軟體工匠是不同的
軟體工匠會推動他們所需的東西。

10. 成為一名軟體工匠
軟體工藝是對狹隘專業化的拒絕
工藝需要奉獻
一個人如何成為軟體工匠？
工藝傳統已經延續了幾個世紀。

11. 精通工藝
一位大師級軟體工匠的樣子是什麼？
利用您的老前輩
精通意味著使用穩定的技術
發展精通需要時間
精通意味著對傳承工藝負責。

12. 學徒開發者
我們必須扭轉開發者培訓質量的下降
成為學徒是一個重要的步驟
學徒制培養終身學習
學徒的角色
學徒制是時間和精力的重要投資。

13. 熟練工開發者
熟練工在工藝傳統中的位置
熟練工開發者
熟練工專注於交付應用程式
熟練工在軟體工藝中扮演關鍵角色。

IV. 重新定位軟體工程

14. 軟體工程專案
軟體工程是為大型系統專案而設計的
軟體工程專案多樣且各不相同。

15. 軟體工程隱喻的危險
您無法在低預算下進行軟體工程
軟體工程鼓勵科學管理
軟體工廠：軟體的生產線
隨著時間的推移，重用是危險的
標準化軟體開發過程的神話
軟體工程迫使我們忘記個體
我們需要在開發過程中更多的多樣性，而不是更少。

16. 從軟體工程中學習
尺寸和複雜性很重要
應用程式需要良好結構
變更可能很昂貴，除非您考慮到它
團隊內部和與使用者的溝通至關重要
產生準確的估算非常昂貴。

V. 週一早上的行動

17. 經驗——專案成功的最佳指標
根據軟體工匠的聲譽選擇他們
根據工匠的聲譽和作品集評估他們
試鏡一位軟體工匠
讓您的軟體工匠選擇其餘的開發團隊
協作開發
如果可能，避免使用尖端技術
為經驗付費
準備好驚訝
設計以便於測試和維護
思考應用程式，而不是專案
維護團隊應拒絕接受劣質應用程式。

18. 設計以便於維護
軟體工匠偏好非專有的開源工具
優秀的軟體是全球性的
軟體工匠需要對抗計劃性過時
優秀的軟體需要一個優秀的使用者介面
可維護的軟體易於診斷
外包的危險
您仍然可以使用外部工匠來創建您的應用程式
維護是任何應用程式生命中最重要的部分
並非所有軟體都必須可維護
設計以便於測試和維護並不是火箭科學。

19. 持續學習
創造學習環境
精通軟體開發的工藝
非常謹慎地選擇培訓課程
鼓勵您的團隊在軟體開發社群中保持可見
成為一名反思型實踐者。

後記
致謝

類似商品