Software craftsmanship:the new imperative

目　录

第一部分 置疑软件工程

第1章 理解软件工程　3
　软件工程的悖论　4
　　等待硬件开发时，软件开发者在干什么？　5
　　得到可用的硬件之后，软件开发者如何加快交付的速度？　5
　　传统开发过程的内蕴　6
　软件工程的当代解读　7
　　“足够好”的软件—庶民的软件工程　9
　软件工程适合你的项目吗？　10

第2章 软件工程的困境　11
　“有组织的、可计量的”软件开发过程现实吗？　14
　　我们当然可以将软件开发中的某些部分自动化，不是吗？　16
　“足够好”的软件开发方法的危害　17
　谁能取代软件工程？　19

第3章 理解软件开发　21
　软件资产　23
　　软件开发需要团队协作　25
　软件开发的分工有用吗？　26
　没有一劳永逸　27
　寻找比“软件工程”更合用的隐喻　30

第4章 寻找一个比软件工程更好的隐喻　33
　软件开发的工艺　35
　与传统工艺学的比较　37
　软件开发工艺的复兴　38

第二部分 软件工艺

第5章 重拾软件开发　45
　工艺学致力于改善软件开发的现状　46
　工艺学鼓励开发者编写优秀的软件　47
　吹响号角　48

第6章 无须执照的工艺学　51
　工艺是私人性的　51
　　同行认可和推荐是获得更好软件的办法　52
　执照只是假象　53
　　执照是在向风车开战　55
　工艺学关注个人　57
　　软件开发者不是太少，而是太多　57

第三部分 软件工艺隐含的意味

第7章 工艺学对系统的用户有何影响　65
　软件容易拷贝，所以软件工艺能够有效　66
　　批量市场的难题　67
　工匠与用户有一种不同的关系　69
　　但是，请记住：购买者很可能不是使用者　70
　优秀的软件应该签上开发者的名字　71
　　为作品签名会使情况发生变化　72
　　工匠应当对作品负责　72
　工匠需要挑剔的用户　73
　　更小、更坚固的软件更有利于用户　73
　软件工艺带来协作式开发　74

第8章 顾客与工匠的关系　75
　给我一个真实的交付日期　75
　揭穿“足够好的软件”的谬论　76
　　另一种选择　78
　　不要只考虑出价最低的开发者　79
　　差劲的客户将很难吸引优秀的开发者　80
　让软件工匠因为自己的作品而获得荣誉　80
　　要求开发者对作品负责　81
　利用开发者之间的差异　81
　　雇佣优秀开发者组成的小团队　82
　　优秀的开发者究竟值多少？　83
　但我们如何知道开发者有多优秀呢？　84
　　根据交付的成果来衡量开发者的水平　85
　在选择工匠时，客户在成本和质量之间作出权衡　87
　　软件工匠的专业分工　88
　客户与软件工匠有长期的联系　90
　　维护者是一个荣耀的身份　90
　　软件工艺有益于长期使用的软件　92
　客户与软件工匠志趣相投　92

第9章 工匠的管理　95
　软件工匠不是雇工　96
　好的开发者比管理者更有价值　96
　　软件开发的实际过程无法详细定义　97
　软件工匠与管理者的关系　98
　以管理优秀的开发者为乐为荣　98
　　优秀的管理者理解项目的节奏　99
　软件工匠喜欢创造软件　100
　　软件开发的根本从来没有改变过　100
　　家有一老，如有一宝　101
　软件工艺要求全新的管理方式　103
　　软件工艺不是“有计划报废”　103
　软件工匠坚持自己的要求　104

第10章 成为软件工匠　107
　软件工艺拒绝精细的分工　107
　　过度的专业化会延误开发、导致错误　108
　　软件工匠建造能够理解的系统　109
　工艺学需要献身精神　109
　如何成为软件工匠？　110
　　学徒是比学校教育更有效的学习方式　111
　　技师是工艺学传统的关键　111
　工艺学传统已经延续多年　112

第11章 工艺的掌握　115
　软件工艺大师是什么样子？　116
　善用你的老员工　116
　“掌握技艺”意味着使用稳定的技术　117
　　软件工匠不会仅仅因为工具“最新最好”而使用它　118
　　软件工程对COBOL的谋杀　119
　技艺需要花时间去掌握　120
　“掌握”意味着承担起传递工艺的责任　121
　　工匠挑选学徒和技师　122

第12章 学徒开发者　123
　我们必须扭转开发者培训质量下滑的局面　123
　　大学文凭与项目开发无关　125
　　会编程不等于会开发软件　125
　　如果必须送初学者去培训，选择好的培训课程　127
　　工艺的掌握，学徒比培训更有效　127
　成为学徒是重要的一步　128
　　为了降低对工作的影响，工匠慎选学徒　128
　　重要的是学，不是教　129
　　学徒不是学校　129
　活到老学到老　130
　　学徒审查师傅的作品，并从中学习　131
　学徒的角色　132
　　从低风险的任务开始　133
　　晋升到产品开发　133
　　因为能力而晋升　134
　　学徒不是廉价劳动力　134
　学徒期是时间和精力的投资　136
　　学徒如何成为技师　137

第13章 技师开发者　139
　技师在工艺学传统中的位置　140
　技师开发者　140
　　技师很少单独工作　141
　技师关注应用程序的交付　141
　技师在软件工艺中扮演关键角色　143

第四部分 重新定位软件工程

第14章 软件工程项目　149
　软件工程的目标是大型系统项目　150
　　软件工程需要专业分工　151
　　软件工程项目依旧使用瀑布过程　151
　　编程是一项刻板的工作　152
　　软件开发不是软件工程项目的瓶颈　152
　形形色色的软件工程项目　153
　　敏捷方法代替缜密的软件工程　154

第15章 “软件工程”隐喻的危害　155
　无法以低成本实施软件工程　155
　　鱼与熊掌可以兼得？　156
　　相信估算软件工程项目的确需要很长的时间　156
　软件工程鼓励“科学管理”　157
　　软件工程轻视不精确的讨论　159
　软件工厂：软件的生产线　160
　　跨项目复用极难实现　161
　冒险的“长时间复用”　162
　“标准软件开发过程”的迷思　164
　　传统的分工无助于软件开发　165
　　“最佳实践”是“科学管理”的遗毒　166
　　最佳实践使人墨守成规　166
　　最佳实践阻碍了过程革新　167
　软件工程强迫我们忽视个人　168
　　软件开发者不是可替换的资源　169
　　伪造一个“理想的开发过程”　169
　开发过程，不嫌其多　170
　　抛弃软件工程的瀑布式过程　171
　　瀑布方法需要大型团队来实施　172
　　小型团队绝不要尝试软件工程　173

第16章 学习软件工程的经验　175
　尺度和复杂度　175
　　做软件，不容易　176
　应用程序需要良好的结构　177
　变化的代价很高——如果你不允许变化的话　178
　交流至关重要　179
　　文档总是错的　180
　　用增量式开发来控制风险　180
　精确的估算很难得到　181
　　借用这些经验　183

第五部分 星期一的早上

第17章 经验——项目成功的指示灯　189
　根据声望选择软件工匠　189
　　信任工匠的推荐　190
　　最后，开始大范围搜索　191
　根据声望和作品来评价工匠　191
　　考察工匠的作品　192
　工匠的试演　193
　由软件工匠来组建开发团队　194
　　根据个人了解和推荐挑选团队成员　194
　　年富力强的开发团队　195
　　为低预算团队担心　196
　通力协作　196
　　使用增量式开发　197
　　尽早解决问题　198
　　任何人都能学会协作式开发　198
　回避极端技术　199
　经验的价值　200
　　他们去年在哪里？　201
　　奖励优秀开发者　201
　　想要人才，就得付高薪　202
　　我们付得起那么多钱吗？　203
　做好吃惊的准备　204

第18章 为测试和维护而设计　207
　是软件应用，不是软件项目　208
　　应用程序只会退休，不会结束　208
　维护团队理应拒绝丑陋的软件　209
　　可维护软件需要有自动测试　209
　　使应用程序能够被测试　210
　为维护而设计　211
　　创建可维护软件需要经验丰富的开发者　212
　　可维护软件能够生存多年　213
　　长寿的应用程序需要长寿的开发工具　213
　开放源码，软件工艺的最爱　214
　　Java对项目的健康有害　214
　　可维护软件需要稳定的基础设施　215
　优秀的软件是全球性的　216
　　保证软件的全球性　217
　拒绝“有计划报废”　218
　优秀的软件需要优秀的用户界面　218
　　能够安全使用的软件　219
　可维护软件易于诊断　220
　外包的危害　221
　　外包忽视了软件开发的本质　222
　　在外包中坚持软件工艺　223
　借助外来的工匠　224
　维护是软件生命中最重要的部分　224
　　提高维护者的地位　225
　　维护者当受赏　226
　并非所有软件都必须可维护　226
　“为测试和维护设计”不能一蹴而就　227

第19章 活到老，学到老　229
　创造学习的环境　229
　　用内部研讨创造学习环境　230
　　邀请所有人参加讲座　231
　　学习时间是一种投资　231
　掌握软件开发的技艺　231
　　鼓励参加用户组和技术会议　233
　慎选培训课程　234
　　课前联系　234
　　课后跟踪　235
　　亡羊补牢　235
　鼓励员工活跃于开发者社群中　236
　　鼓励出席技术会议　236
　　鼓励开发者担任讲师　237
　　鼓励开发者写书　237
　沉思的实践者　238