| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 班级博客 |
| 这个作业的要求在哪里 | 作业要求 |
| 我在这个课程的目标是 | 熟悉敏捷开发，提升多人协作技能 |
| 这个作业在哪个具体方面帮助我实现目标 | 阅读《构建之法》，初步认识软件工程 |
看完《构建之法》后我不理解的问题与个人思考
问题一 PSP和TDD结合
原书介绍PSP流程（第2章写到）Development的组成结构:
分析需求、生成设计文档、设计复审、代码规范、具体设计、具体编码、代码复审、测试
需要质疑的是，现在的软件更新速度和开发环境，这些环节的顺序不再是如此的明显，Test和Code Review这两个环节应该是伴随整个软件周期的。书中又写到
在写技术模块的规格说明书的时候，要越详细越好，最好各项要求都可以表示为一个单元测试用例。……单元测试必须由最熟悉代码的人（程序的作者）来写。
单元测试的测试用例可以依照规格文档来构造。那么其实在完成最初的架构和模块设计、在具体编码之前，大部分单元测试的目标对象和测试用例就已经可以得出。我认为，应当在规格设计后先写好单元测试用例和模块接口，每个模块具体编码完成后尽可能早的进行单元测试，而不应该等到全部编码完成、复审后再测试。那么是不是可以考虑用TDD的策略来思考和完善这一个操作？
问题二 规格、范式、参数的思考
在教材4.3代码设计规范中，作者提到关于goto的阐述
函数最好有单一的出口，为了达到这一目的，可以使用goto。只要有助于程序逻辑的清晰题现，什么方法都可以使用，包括goto
同样在第四章，代码规范部分有
在Debug版本中，所有的参数都要验证其正确性。在正式版本中，对从外部（用户或别的模块）传递过来的参数，要验证其正确性。
如何验证正确性？那就要用assert。当你觉得某事肯定如何时，就可以用断言。……
这里其实我有如下一些质疑和思考:
-
代码规范和约定是面向修改和接口的，不是面向自己的。从个人的角度来看
goto,assert等功能的用法都是灵活而自由的，但是考虑到整个团队，不能将这些策略灵活自由的运用，因为一份代码终将离开你，终将获得自己的新生命，而在获得新生命的过程中，这些曾经运用良好的trick，将成为它重获新生的枷锁：也就是说，规范是为了之后更好的维护，做出的妥协。只要有助于程序逻辑的清晰体现，什么方法都可以使用这个观点我并不赞成，并非所有方法都适合于广泛的受众。 -
所有的参数都要验证其正确性”是一件难以实现的工作。我们拿python举例，如下面这个锂离子，类型说明注释并不意味着检查，是一种对未来工作的警示，而不是对当前每一次应用的验证，同样过度的validation是对自己代码的不信任和对系统工程的阻碍。
def add(x:int, y:int) -> int:
return x+y
问题三 NABCD模型
在竞争环境下，NABCD模型中，NAC对产品是否成功的影响似乎过小，BD对产品的影响似乎过大：
我们要在竞争性的环境中实践软件工程，那就要做实用并且创新的项目。……大家可以参考NABCD模型。
N：需求，你的创意满足了用户的什么需求？
A：做法，看看你有什么独特的招数，不光是技术上的，也可以是商业模式上的。
B：好处，会带来什么好处？要花费什么才能得到好处？得到的好处超过迁移成本？
C：竞争，用户需求 vs 我们产品 vs 别人产品
D：推广，如何把产品交到用户手中？
很好奇的是BD的这种过大印象，是不是对软件本身有了商品化的期待：NABCD的核心变成了B与D后，是否不再是一个软件工程概念而变成了一个营销与商业发展概念？
对于软件工程和最后的应用落地我没有太多的经历，也没有看到有相关的介绍，很好奇这个问题应该如何去正视。
问题四 创新和技术的关系
关于作者的两点迷思，我觉得很好奇。
创新的迷思之七：成功的团队更能创新？
很多成功的企业进入了“创新者的困境”。当成功的企业步入中年，它们当年发迹的市场成熟了，当年赖以成功的创新技术成了主流的成熟技术，又叫“维持性的技术”，在成熟的市场和维持性的技术环境中，技术的创新并不是影响企业成败的主要因素……那些没有成功包袱的小公司反而能把颠覆性的创新带到市场，挑战成熟企业的霸主地位。
统计数据表明，70%的创新者说，他们最成功的创新，是在他们的拿手领域之外的。
我们先引入一个现象：知识的诅咒。
这种情况，就是《让创意更有黏性》这本书所提出的“知识的诅咒”概念：当一个人知道一件事后，他就无法想象自己是不知道这件事的。
-
在创新的过程中一个领域内的master做出创新是因为他们破处了知识的诅咒，发现了在他们了解的领域之中还有不知道和未探索的部分，这才是创新？而不是上文中统计数据所说的，他们在拿手的领域之外创新？
-
成功团队如何定义？一个不断创新的团队是不是也是一个成功的团队？我们的思维是不是把成功、成熟、创新、霸主地位、这些词条给聚类了呢？没有客观的分析出到底这些团队是处在什么要的地位，我觉得成功和创新没有必然关系。
问题五 结对编程
我觉得pair会有如下挑战
- 两人的软件工程水平差距
- 如果两人的水平悬殊，一位是经验丰富的高手，另一位是初涉职场的新手，这种情况下的结对编程毫无疑问会演变成为高手的个人表演，新手的参与程度会比较低。而如果两人的水平相当，如何能够保证两双相似的眼睛的 review 结果能够优于单独编程，不致于浪费人力。
- 两人的性格差异
- 每一位开发者都有自己的偏好，无论是代码的品味、编辑器的设置等与编码相关的，还是待人处事等与人际交往相关的，都可能会产生冲突。如何避免与解决两位开发者之间的冲突，我认为这是一个难点。
- 两个人写一份代码
- 怎么才能像作者说的取得更高的投入产出比呢？我个人感觉投入更多产出更少了。如果不喜欢被盯着工作会不会影响效率呢？如果领航员在领航时划水效率不就更低了吗？
- 质量是否取决于一对程序员中各方面水平较高的那一位
- 如果是真的取决于水平较高的以为，那为什么我不直接让水平较高的那一位做不就好了吗？这样结对编程看起来更像是给人表演自己写代码。如果两个人水平差不多，我们分开写两份代码不会产出更多吗？
请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？
- 软件
- 英文 software 出现时间：
- 1851年，词义是“毛质或者棉质品(woolen or cotton fabrics)”和"比较容易腐烂的富婆(relatively perishable consumer goods)"。
- 第一次以计算机软件的含义出现是 Paul Niquette 在1953年创造。
- 同年8月，Richard R.Carhart最早出版的“software”的一词。
- 第一次以印刷形式出现是1958年由 John Tukey.
- 英文 software 出现时间：
- 软件工程
- 1965年6月，最早出现在许多公司的服务列表中 COMPUTERS and AUTOMATION
- 第一次正式使用是1966年的ACM会议，由当时的主席President Anthony A. Oettinger在"letter to the ACM membership"中提到(Volume 9,number 8)
- 1968年秋季，NATO（北约）的科技委员会召集了近50名一流的编程人员、计算机科学家和工业界巨头，讨论和制定摆脱“软件危机”的对策。在那次会议上第一次提出了软件工程（software engineering）这个概念
大家知道了软件和软件工程的起源，请问软件工程发展的过程中有什么你觉得有趣的冷知识和故事？
全世界广泛使用的linux系统是Linus Benedict Torvalds和他的伙伴一起开发，所以以他的名字命名（自己命名的），而且linux发明的初衷是为了玩一款在unix上运行不够流畅的游戏。
上网调查一下目前流行的源程序版本管理软件和项目管理软件都有哪些， 各有什么优缺点？
查询wiki和相关资料得到下表
| Name | Users | Projects | Alexa rank (lower = more popular) |
|---|---|---|---|
| Assembla | Unknown | 526,581+[45] | 23,052 as of 9 September 2019[46] |
| Buddy | Unknown | Unknown | 73,518 as of 9 September 2019[49] |
| CloudForge | Unknown | Unknown | 339,271 as of 9 September 2019[50] |
| Gitea | Unknown | Unknown | 209,697 as of 9 September 2019[51] |
| OW2 Consortium | Unknown | Unknown | 610,052 as of 9 September 2019[66] |
| Rosetta code | Unknown | Unknown | 62,045 as of 9 September 2019[67] |
| SEUL | Unknown | Unknown | 1,268,571 as of 9 September 2019[68] |
| GitHub | 31,000,000[52] | 100,000,000[52] | 65 as of 9 September 2019[53] |
| Bitbucket | 5,000,000[47] | Unknown | 989 as of 9 September 2019[48] |
| Launchpad | 3,965,288[59] | 40,881[60] | 12,344 as of 9 September 2019[61] |
| SourceForge | 3,700,000[69] | 500,000[69] | 407 as of 9 September 2019[70] |
| GitLab | 100,000[54] | 546,000[55][k] | 2,146 as of 9 September 2019[56] |
| GNU Savannah | 93,346[57] | 3,848[57] | 100,244 as of 9 September 2019[58] |
| OSDN | 54,826[62] | 6,294[62] | 8,529 as of 9 September 2019[63] |
| Ourproject.org | 6,353[64] | 1,846[64] | 1,191,954 as of 9 September 2019[65] |
| Name | Users | Projects | Alexa rank (lower = more popular) |
可以看到使用最多的是GitHub，其次是Bitbucket，Launchpad，SourceForge。
Microsoft TFS（Team Foundation Server）：
优点：任务版上能将需求、项目进度一览无余，对于小团队而言，比甘特图更有用；集成了项目管理、版本控制、BUG 跟踪，能有效实现 SCRUM；能与 VS 无缝接合
缺点：搭建、维护tfs比较复杂，硬件要求也比较高。
Mercurial：
优点： 是一种轻量级分布式版本控制系统，采用 Python 语言实现，易于学习和使用，扩展性强。
缺点：分支管理不灵活，功能相对较弱。
Git：
优点：
适合分布式开发，强调个体。公共服务器压力和数据量都不会太大。速度快、灵活。任意两个开发者之间可以很容易的解决冲突。离线工作。
缺点：资料少（起码中文资料很少）。学习周期相对而言比较长。不符合常规思维。代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。
GitHub：
优点：GitHub是一个非常万能的工具。对于任何大小的项目，他都是理想的工具；他也是伟大的web工作流工具。首 先，他可以作为一个版本控制系统和协作工具，用它来发布工作。利用GitHub，你可以将项目存档，与其他人分享交流，并让其他开发者帮助你一起完成这个项目。优点在于 ，他支持多人共同完成一个项目，因此你们可以在同一页面对话交流。创建自己的项目，并备份，代码不需要保存在本地或者服务器，GitHub做得非常理想。
缺点：
如果：是Github使用新手需要不断实践和时间。他可能不是捕捉创意过程和记录创意点子的最佳工具。对于这种特殊功能模拟可以选择LayerVault 或其他相似工具。之前，我们已经强调过Github非常适用代码跟踪，但是却不是最好的设计跟踪工具。将图片内容转 化为代码，或者将设计用于产品设置，看起来依旧不是那样顺利。
Trac：
优点：
Trac做一个SCM配置管理平台，意味着它有良好的扩充性；Trac的权限体系是比较完备的设计；非常灵活，可以随心所欲的定制，可以和TortoiseSVN集成。
缺点：
1.不支持多项目 2.需求和缺陷没有分离 3.用 wiki 来替代 Word 等工具编写文档对于产品策划来说门槛太高了 4.中文化不完整，美术人员接触起来困难重重 5.不显示中文名，本地化做得很差 6.核心功能很少，不安装插件基本上没法用。
BUGZILLA：
优点：
1、BUGZILLA不收费,2、BUGZILLA现在有中文版支持
缺点：
1、BUGZILLA只能管理缺陷
2、本地化不够好
Rational：
优点：采用迭代式开发模式，以降低项目风险；
·专注于构架，开发出更有弹性的系统，以迅速适应不断变化的业务需求。
缺点：对于个人用户的功能开发远不如github方便
Apple XCode：
优点：
1.可以自动创建分类图表。2.自动提供撤消、重做和保存功能，无需编写任何编码。
缺点：Apple系设计壁垒
选择两个源程序/项目管理软件进行实践
git
git有很多辅助开发软件，gitlens是一个非常清晰易用的套件。
github
不仅是一个git的网页版平台，还支持pull request，issue，action等功能，十分的方便，不愧为用户量最大的项目管理平台。