软件工程个人博客作业

软件工程个人博客作业

项目	内容
作业属于哪个课程	2020春季计算机学院软件工程
作业的要求	个人博客
课程的目标	阅读建材，提出问题，查找项目控制软件并比较、实践

看完《构建之法》后的疑问

1. 关于结对编程

在原书第85页，有如下描述：

在开发层次，结对编程能提供更好的设计质量和代码质量，两人合作解决问题的能力更强。两人合作，还有互相激励的作用，工程师看到别人的思路和技能，得到实时的讲解，收到激励，从而牡蛎提高自己的水平，提出更多创意。

我的疑问在于，考虑工作和学习中的结对编程，我们需要考虑到合理的分配两个人的任务，如果只是将工程分解为数个模块分给两个人做，那结对编程和团队编程有什么区别呢？

其次，编程并不是做数学题，我们还要考虑到代码风格等等问题，我觉得两人合作解决问题的能力更强这句简单的描述缺乏说服力，强行结对可能并不能有文中事半功倍的效果，在后文我们也能发现，作者所指的结对编程需要大量的磨合，这种高投入的方法真的适合高强度的现代开发吗？

最后，看别人的思路与技能来启发自己，为什么我们一定要在工作中做而不是在其他时间阅读他人代码和文档来起到相同的作用。

2.关于"写了再改模型"

书中对于这种模型是持批判角度的，但是我的疑问是，有的时候哪怕我们花了很多时间预先进行思考与规划，也有可能在编码过程中出现问题，毕竟编码是一个细节很多的工作，在真实开发软件时，会不会出现临时增加需求的情况呢(在一些论坛里看见过这类吐槽)，也就是说，程序员可能不得不陷入写了再改的境地。那么当我们陷入这种情况时，有没有什么方法可以让我们能够减少改动？

3.关于功能团队模式

书中说“很多软件公司的团队最后都演变成功能团队，简而言之，就是具备不同能力的同事们平等协作，共同完成一个功能。”

在这里，可以自由组织的形式可能使得代码风格等接近的同事组队，如果这种组队固化后，每次项目的功能模块实现应该如何分配呢，每个组的工程能力会不会两极分化？

4.关于PM

观察、理解和快速学习能力PM要能够在一个新的领域中很快上手。PM要能理解用户，能站在用户的角度上考虑问题，观察发现用户不善于表达的需求，体察团队成员的言外之意，倾听老板/客户/利益相关人的弦外之音。要有能够理解别人的处境、心理、动机的能力——同理心。一个PM平时或许能玩转很多高技术的工具，但是当工作需要时，他/她能突然把自己变成一个完全不懂技术的菜鸟用户，从用户的角度来看问题。

PM是离用户最近的人，负责把用户的声音传达给开发者和策划人员，但是他同样也应该是将开发者的声音传达给用户的人。就我个人看到的吐槽，很多PM反而是外行人员，他们只能做到前者，却因为缺乏专业素养，往往不能分辨出用户的非合理需求，这时开发人员应该如何与之进行技术层面的协调呢？

5.关于形式化的设计方法

在书中239页提到，一些科学家一直在努力，希望用无歧义的、形式化的语言描述我们要解决的问题，然后用严密的数学推理和变换一步一步把软件实现出来，或者证明我们的实现的确完整和正确地解决了问题。

我联想到了oo时的JML，这是一种对于规格的描述，对于每个class都会有这样的JML描述来约束输入和输出，但我觉得其描述太过详尽，又是甚至将内部的算法也描述了一遍，这样显得有些画蛇添足，为什么我们不直接写一份清晰的代码呢？但是如果不这样详尽的描述，又怎么形式化地进行正确性验证？

请问 “软件” 和 “软件工程” 这些词汇是如何出现的 - 何时、何地、何人？

软件(Software)

In 2000, Fred Shapiro, a librarian at the Yale Law School, published a letter revealing that John Wilder Tukey's 1958 paper "The Teaching of Concrete Mathematics" contained the earliest known usage of the term "software" found in a search of JSTOR's electronic archives, predating the OED's citation by two years. This led many to credit Tukey with coining the term, particularly in obituaries published that same year, although Tukey never claimed credit for any such coinage. In 1995, Paul Niquette claimed he had originally coined the term in October 1953, although he could not find any documents supporting his claim. The earliest known publication of the term "software" in an engineering context was in August 1953 by Richard R. Carhart, in a Rand Corporation Research Memorandum.

“软件”一词最早发表于John Wilder Tukey于1958年发表的论文"The Teaching of Concrete Mathematics"，最早出现于1953年Richard R. Carhart的Engineering context。

软件工程(Software Engineering)

The origins of the term "software engineering" have been attributed to various sources. The term "software engineering" appeared in a list of services offered by companies in the June 1965 issue of COMPUTERS and AUTOMATION and was used more formally in the August 1966 issue of Communications of the ACM (Volume 9, number 8) “letter to the ACM membership” by the ACM President Anthony A. Oettinger; it is also associated with the title of a NATO conference in 1968 by Professor Friedrich L. Bauer, the first conference on software engineering. Independently, Margaret Hamilton named the discipline "software engineering" during the Apollo missions to give what they were doing legitimacy. At the time there was perceived to be a "software crisis". The 40th International Conference on Software Engineering (ICSE 2018) celebrates 50 years of "Software Engineering" with the Plenary Sessions' keynotes of Frederick Brooks and Margaret Hamilton.

In 1984, the Software Engineering Institute (SEI) was established as a federally funded research and development center headquartered on the campus of Carnegie Mellon University in Pittsburgh, Pennsylvania, United States. Watts Humphrey founded the SEI Software Process Program, aimed at understanding and managing the software engineering process. The Process Maturity Levels introduced would become the Capability Maturity Model Integration for Development(CMMI-DEV), which has defined how the US Government evaluates the abilities of a software development team.

Modern, generally accepted best-practices for software engineering have been collected by the ISO/IEC JTC 1/SC 7 subcommittee and published as the Software Engineering Body of Knowledge (SWEBOK).

"软件工程"于1968年秋NATO讨论制定，研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的学科。

软件工程中的趣闻

项目管理软件中用户最多的就是git系列，而其创始人正是Linus。

Linux的开发者来自五湖四海，最初他们都将自己的代码发送给Linus手工合成，因为当时的管理软件中，Linus坚定地反对CVS和SVN，这些集中式的版本控制系统不但速度慢，而且必须联网才能使用；而有一些商用的版本控制系统，虽然比CVS、SVN好用，但那是付费的，和Linux的开源精神不符。

后来，过大的代码量让Linux难以继续手动管理，他选择了BitKeeper，而该公司也授权让他们免费使用。

之后，Linux开发者中几位试图破解BitKeeper的协议，公司收回了免费使用权，Linus不得不花了两周时间来写一个分布式版本控制系统——Git。

版本管理软件和项目管理软件

在维基百科上可以看到一些主流版本管理软件和项目管理软件统计数据如下：

经查阅资料，部分软件的优缺点如下：

• Microsoft TFS

  • 优点：

    任务版上能将需求、项目进度一览无余，对于小团队很有用

    可以与 VS 无缝接合

  • 缺点：

    TFS在个人成本上的消耗相对来说更大一些。

    TFS通过复杂的看似功能强大配置管理，将联机看做是整个项目周期的常态，这在实际使用中造成极大的不便。

    整个系统是用 asp 实现的，用浏览器访问相当慢

• Github

  • 优点：

    基于web，允许你使用Git的源代码管理功能

    开源的程序更容易被别人看到

    github的公开项目免费

    github 不断在修改增进界面

  • 缺点：

    不适合新手，新手需要多加练习

• Trac

  • 优点：非常灵活，可以随心所欲控制可以和SVN集成
  • 缺点：功能不是很强大

• Bugzilla

  • 优点：免费，有中文版支持，bug管理能力强
  • 缺点：快速搜索结果不准确。只能管理缺陷。

• Git

  • 适合分布式开发，强调个体。

    公共服务器压力和数据量都不会太大。

    速度快、灵活。

    任意两个开发者之间可以很容易的解决冲突。

    离线工作。

  • 缺点：

    学习周期相对而言比较长。

    不符合常规思维。

    代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。

• Apple XCode

  • 优点：

    编译速度极快，每次操作都很快速和轻松。自动提供撤消、重做和保存功能，无需编写任何编码。

  • 缺点：

    更新版本后，某个插件可能会失效。

• SVN

  • 优点：

    管理方便，逻辑明确，符合一般人思维习惯。

    易于管理，集中式服务器更能保证安全性。

    代码一致性非常高。

    适合开发人数不多的项目开发。

  • 缺点：

    SVN服务器管理复杂

    SVN强迫使用者即时处理冲突，然后才能提交。导致代码不能即时提交。

    SVN速度超慢。提交、更新、浏览历史的速度都很慢。

实践

Git

类似于linux命令行的形式，也支持windows的部分cmd操作，只要熟悉能够快速使用。

但个人感觉熟练使用它需要大量学习成本，虽然其很多操作我们不太用得上，但一旦需要用时可能就会一头雾水。

Github

更类似于博客园这样的社区，只不过其中嵌入了项目管理功能，能够支持多人协同管理，也能快速查找别人造好的轮子为己用，相较于其它几款，我认为Github更加适合开始新项目的团队，不仅能够管理自己的代码，也是学习别人的项目、提取灵感的利器。

比如star功能就能提供很多资料与值得学习的项目供随时查阅。