很早之前,我看了一本名为<<软件工艺>>的书,感觉收获很大,所以在此我进行分享,不过会大量透露书的内容,所以有同学想直接看这本书,那最好不过
一.介绍
1.首先此书荣获了2002年的Jolt图书大奖,获得了Jolt图书大奖的书,看过的都挺多的,这本书很是特别,它不是那种理论的书,也只有200多页,我一个晚上就可以看完的篇幅,此书可以说对于学过软件工程的人冲击很是大,不过请放心地阅读此本书,此书并未推翻软件工程的理论
2.对于此书的诞生,我的印象是,此书是2000年由Pete McBreen 先生创作,但是争议非常地大,经过了几年的变化,许多年轻人最后接受了这套新的软件开发方式,而有幸在熊节主笔的翻译下,2003年,在中国可以看到此书
3.此书和软件工程的关系:许多人以为软件工艺和软件工程互不两立,我想这些都是炒作,看过书的人都知道软件工艺只是软件工程的补充,它们的理论并没有什么冲突,只是我们的思想过于僵化,把自己限制在软件工程的思想天空,就如这本书告诉了我们学会质疑
二.感想
1.在此之前,我曾学习过软件工程,想要实践此套理论,便尝试做了几个小项目,发现并没有想象中的这么简单,需要大量文档和度量,并且需要大把的时间,导致我作一个小项目非常吃力,我也是很惆,所以感觉这套理论可能有不足,刚好有幸看到了这部书, 我便饶有兴趣地看了一会,看了一个晚上,后来我又重新看了几遍.
2.作者开始便对软件工程的理论体系进行了质疑,做了大量的研究,提出了软件工程的缺点,而对于软件工程的背景,提出理论的条件和为何会提出此理论做出充分的解说,最后他说,软件开发是一种艺术,一种文化,就如软件工程的理论最初只是照搬工程学的许多的资料而已,而作者认为将软件工程和软件工艺的结合,就成为软件领域的独特的开发,成为带有软件文化的思想了
3.以下是我在读此书时的一些笔记,可能还不太全面:
软件工艺的总结:
１.我们需要给软件开发一个更好的隐喻：软件工艺
2.传统的开发过程范畴:
a.分析师，负责编写需求文档
ｂ．设计师，负责创建设计规格
ｃ．程序员，负责编写代码
3．进行项目人员体系的改革
4.对于庶民的软件，使用软件工程简直就是奢侈
5.软件工程适合你的项目吗？
6.软件工程实际上是把工程学的隐喻强加于软件开发之上
7.教条主义的软件工程使我们忘记了软件的本质：真正决定项目成败的，是作为个体的程序员的技能和知识和经验
8.软件工程:人海战术,软件工艺:某个人对项目起到了决定性作用
9.系统应该由尽可能少的人员来开发
10.软件工程的关键问题，就在于：它使我们忘记了＂是人来开发软件＂
11.软件开发不是一个确定过程
12.我们可以将软件开发中的某些部分自动化,只有确定的过程才能被自动化
13.软件工业?=软件工程
14.脱离机械刻板的"软件工程"
15.传统工业(尤其是制作业)来类比软件产业实际上是不恰当的
16.软件是被具现化的智力资产
17.软件的生产比设计简单的多,软件工程失败的地方也是如此
18.软件开发的整体过程可以总结为:获取明确的和隐含的知识,并将这些知识具体化.
19.彼此学习是软件开发重要的部分
20.软件开发需要团队合作,需要大量的人际交往,开发者和使用者
21.软件工程:从实现阶段到设计阶段的混乱
22.劳动的分工是工业革命的基础,将同一件任务被切分为多个小步骤越多
23.同一个开发者对需求,设计和源代码都有着深入的理解,软件开发就能够获得最好的效果
24.软件没有一劳永逸,集中关注特定的一组项目特征
25.软件工程不适合现代的软件开发,软件开发已经是一个社会性的学习过程
26.一切都在变化,客户对软件的期望同样发生这改变,开发人员结构的变化
27.关注自动化完成软件开发中"编码"的部分工作,管理上的解决方案,最近(2000)关注人,人与人之间交流的解决方案也在提出:极限编程
28.极限编程关注软件开发的工艺学,关注开发者和客户每分钟的工作
29.过去软件开发是一种智力的挑战,现在一个交流的过程
30.软件开发究竟是科学,工程学还是艺术?
31.软件开发是一种全新的东西,它融合了艺术,科学和工程学,其最终目的是要为用户提供实用的系统
32.软件工艺学和传统工艺学是有许多相识之处的
33.刚开始程序员也深入硬件的开发过程,但是硬件工程和系统编程领域很快就与应用程序开发领域分道扬镳
34.软件开发工艺的复兴就像文艺复兴的思想文化运动
35.人是软件开发过程中的核心
36.职业和业余的本质区别,就像业余棋手和职业棋手,对于下棋的观念不一样了
37.曾经硬件是软件开发所需的开销中最贵,现在是软件
38.短期培训的想法是失败的,编写代码不是软件开发中最重要的,短期培训不到6个月,只是学会的如何敲代码
39.软件开发的核心是思想,而快餐式的短期培训根本不了解软件开发的本质
40.飞机制造者和驾驶员,汽车制造者和司机,飞机设计师和造飞机的人
41.软件工程一直试图将软件开发纳入工业化的轨道,消除其中对熟練工人的需求
42.学徒是一种定位学习,技艺是需要靠实践来巩固的
43.编程是一门手艺,就像制作手表
44.首先我们必须明白开发者确实理解自己所从事的工艺,并且软件开发者充分掌握自己的工艺,在工作中不断磨练,提高自己的技能
45.工匠的声望取决于他们从前为客户所提供的产品的质量,而非他们使用过程或者他们对自己的宣传,不需要执照
46.工艺是私人的,同行认同和推荐是获取最好的软件的办法,好莱坞模式
47.软件工程还非常年轻,没有一套非常完整的体系
48.在工程学领域中,执照是有效的,但是软件领域中,是不可以的,并不是靠了设计师证书的汽车设计师,就一定比没有靠的人设计的好
49.证书只是说明你有能力敲代码了,但是不是设计
50.如何让软件开发者成为优秀的开发者,软件开发者不是太少,而是太多,比如创作,写诗,需要积累,需要十几年的时间
51.软件行业,不是本科的人一定就厉害,这也是书中提到的
52.说到底软件工艺只是一个隐喻,原则,需要实践,学习软件工程和软件工艺,到社会上都是一样的,最终的软件产品效果一样
53.火药和炸弹的区别,同样是一件物品,但是本质上已经不一样了
54.工艺学并不排斥科学和工程学,工艺学力图在人,知识,机器之间找到微妙的平衡
55.工艺学,产品是个性化的,工匠的声望,信息需要了解,就是一个团队
56.软件的经济学和传统的经济学不一样,比如说理发师
57.软件是容易拷贝的
58.工艺学中,新手只是菜鸟,新手,而不是傻瓜,笨蛋
59.什么叫一个产品获得50%的满意度
60.优秀的软件应该签上开发者的名字,以表示对产品的负责
61.工匠应该对作品负责
62.工匠也是挑剔的选择用户,比如软件的价格,好的律师和坏的律师,还有不要选择差劲的客户
63.给我一个真实的交付日期
64.已经纠正已有的错误,想到枪,战争,人
65.价格不是重点,重要的是性能
66.雇佣好的设计团队,一个差的队友,会拖累整个团队,所以,团队的组合是非常重要的
67.增量式的软件开发方式,自动化测试
68.功能少而质量好,比功能多而质量差好
69.客户和软件开发者需要长时间的联系,维护是非常重要的
70.软件工程的科学管理是泰勒式的,而软件工艺的科学管理是新泰勒式的
71.科学管理,"你拿工资是干活的,而不是思考的",命令-控制
72.软件工匠不是雇工,一个军队的指挥官特别厉害和一对萨比,和一个指挥官只是指挥,和一堆牛逼的不得了的人物
73.好的软件无法定义,比如鲁迅的文章,只有鲁迅写的出来他的风格,管理者只是管理时间,资源等
74.最初软件工程还不是程序员(软件相关)提出来的,一个建筑师
75.团队的健康,管理是非常重要的,快餐式的开发方式也已经不成立了
76.优秀的管理者明白项目的节奏,对团队的成员有了解,并进行交流和适应
77.工匠喜欢自己的专业,并精于一门技术,工匠精神,而不是到了一定年龄转到其他领域,比如管理
78.经验丰富的人比新手好培养技术
79.开源社区的案例表明了工匠的维护性
80.优秀的开发者一直把自己设计的软件看为艺术
81.软件工艺拒绝精细的分工,比如程序员并不是最菜的,或者架构师,但是,同为程序员还是要有追求的
82.一个人能了解整个系统,软件工艺是一门思想,态度,而不是知识
83.软件工艺需要传承,即教导,一门真正的技术需要15年以上的时间
84.工匠挑选学徒和技师
85.会编程不一定会开发软件,编代码只是一个部分
86.重要的是学,而不是教,不是学校的那种,老师教,同学学,脱离实践的那种学习方式,所以让我听老师讲课,还不如自己去看源代码
87.学到老活到老,学徒的建议需要耐心的反馈
88.从低风险的产品开始学习,学会熟練的使用工具,这个是重点彻底了解eclipse的使用.
89.接受工艺学的文化和规范是非常重要的,即思想
90.软件工艺是软件工程的补充,而敏捷开发是软件工程的改革,这就是说软件开发的方式并不是直接把传统的工程学套过来,而是不断的改进,成为软件领域的独特开发,成为带有软件文化的思想了,例如经典文学对一个民族的影响,和现代快餐式的文学
91.二十世纪20年代-30年代的科学管理,席卷整个工业世界
92.科学管理用科学取代了经验法则,数字支配一切,一切需要度量
93.软件工程试图模仿传统的制造业,所以我们需要改革,正如现在一切都在改革,技术一直在更新
94.自适应的软件开发
95.最佳实践和科学管理
96.增量式和渐进式的开发方式
97.回避极端技术