【软工做业&思考】关于软工的一些概念性理解暨第一次阅读做业

概述

项目	内容
本次做业所属课程	2019BUAA软件工程 周二班
本次做业要求	第1次我的做业 固然，比这个更重要百倍的仍是实实在在的思考，这也是标题如此命名的缘由
我在本课程的目标	在原有实践经验的基础上，系统化学习软工领域的理论知识，总结之前以及如今的得与失，提升自身知识水平（怎么一股生命在流逝的味道）
本次做业的帮助	将《构建之法》与实际经验进行结合

好吧，既然是概述，那么就先说点什么，光一个表格我的感受表现力太有限了。若是对笔者的自报家门没啥兴趣的话，能够直接跳到下一节。

首先，本人很早就有计算机方面的技术背景（早到什么程度呢，我学编程那会，Google在大陆还能直接上，QQ号还都是8位的），在编程方面，私觉得还算是略知一二，或者说有那么一点点的经验。

其次，本人在大一开始就进行过实用系统的开发，其中包括：

• Questionor刷题网站（连接：https://questionor.cn，如今每届北航学子刷航概题还都在这上面）
• 同袍APP（最懂北航学子的手机app，不过如今出于一些复杂缘由暂时没法使用）
• 若干以赚钱为目的的外包项目（大概，在大一就能绰绰有余的cover掉包括学费在内的一切我的支出）

嘛。。。先打住，再这样下去实在有点像是产品软文了。[捂脸]

此外，笔者带过不止一个技术开发团队，做为团队的leader。踩过坑，也从屎山里面爬出来过；胜利过，也失败过；团队里你们一块嗨过，也层不止一度出现严重分歧，甚至分崩离析过。其中，私觉得还算是有一点点略微的心得。

说这些的目的呢，其实特别简单。笔者从没认为本身如何如何，只是阐述一下客观事实，作一些微小的工做，或者说，铺垫。以防止下面看到有些内容的时候，被认为是在分享刚编的故事。

好了打住，先说到这。下面是正文。

我的的思考

其实说来，本人的疑惑和思考可能和大部分同窗有些不同。因此我就尽可能按照个人方式来表达，而且能够的话也说一些我对其余同窗疑惑的理解吧。

思考一：PM作开发和测试以外的全部事情

PM作开发和测试以外的全部事情

这话确实颇有道理，说的也没错。（或者倒不如说，非技术背景出身的PM也没办法插手这事）

然而，要是，PM也是技术背景出身，甚至仍是有必定经验的技术人员呢？

笔者本身就遇到过相似的状况。

在笔者以前早期带的团队里面，就是会出现有的时候全体进展缓慢的状况。这个其实也正常，都是身边的同窗，不是谁都有写过十几年的代码的。

因而，尤为是ddl迫近的时候，笔者我当时遇到这样的状况，经常本身就看不下去了。一拍腿，老子本身上。

果不其然，本身一上阵，问题最终就很快被解决了。

若是只从结果的角度来看，这固然是皆大欢喜——这世上历来就没有过啥好手段坏手段，能解决问题的就是最好的。

对于临时的小队伍来讲，这还算好，最起码结果是好的。然而以后发生的事情证实，这种作法对于长期的团队来讲，是很是危险的。

笔者带过的一个团队，当时就这么干的。期初几回，笔者一我的单挑的成效都很不错。越到后来，就发现你们都开始起不到做用。笔者甚至一度很生气，去质问过他们，甚至逼过他们。但是最终，笔者得出了一个使人绝望的答案——他们真的啥也不会了。

或者换句话说，在该锻炼队伍成员，该磨合团队协做模式的时候，这些事情同样都没有作。最终，这个所谓被称之为团队的东西，彻底成了由一个强力单体，和若干起不到任何做用的人，构成的乌合之众。对于强力单体，看似有团队，实则孤立无援，最终早晚被硬生生累垮。对于其余人，看似有团队，实则毫无归属感，天然不可能愿意卖力，就算愿意，也并不能真正的帮上忙。

这还不算完，若是有一天，这个团队的强力单体出现了情况的话，那么，这个所谓的团队，会马上面临灭顶之灾，且毫无自保的能力。

这样的故事其实历史上已经上演过无数次：

• 诸葛亮鞠躬尽瘁，死然后已。他在的时候，把三国中最弱的蜀国治理的层次分明。然而他事必躬亲，因而致使的局面就是，其余不如他的人才彻底没有成长的空间。等他一死，蜀国一会儿就出现了严重的人才断层。很快，蜀国就灭亡了。
• 月厨们都知道，Saber生前的经历。甘愿当圣人，想要一己之力拯救臣民。然而等有一天光辉再也不的时候，就注定要面临生命中的卡姆兰之丘，心里无比挂念的臣民也同样得不到任何拯救。

因此，我的认为。就算PM，或者说领导，有着极强的我的输出能力，也绝对不能够随随便便就亲自上阵（固然，偶尔救急能够，可是毫不能够成为常态）。不是由于什么领导的架子，而是出于整个团队的可持续发展考虑。

不过，这里面具体的分寸，也确实是一个值得深思的问题。从一碗鸡汤爬出来，立马跳进另外一碗鸡汤，也不是正确的思考问题方式。笔者也认为，本身目前这块实际上作得还远远不够成熟。

思考二：Bug的定义

问题源自guzhanpeng同窗的博客。第一个疑问，里面说到了bug的定义问题。

首先我想说的是，Bug自己就不是一种单一的定义。

这位同窗百度搜索到的结果是：

程序错误（英语：Bug），是程序设计中的术语，是指在软件运行中由于程序自己有错误而形成的功能不正常、死机、数据丢失、非正常中断等现象

这个固然没有错，这个是程序设计意义上的bug。

然而，实际上从用户、从需求的角度来讲，不符合需求的，就是bug。这个bug是产品需求意义上的bug。这二者并不存在矛盾抑或是冲突。

或者也能够说，bug能够通常性定义为和指望不符的状态及其诱因：

• 对于程序而言，结果错误、运行时错误、崩溃，这确实就是和指望的正确结果不符的状态。
• 对于产品而言，你程序就算对了，可是人家要个苹果你给人家运来一车梨，还美其名曰梨很好吃咱们也很辛苦，这显然就是在扯淡了。没错，这也是与指望状态不符的状态。

综上，其实所谓bug的两种定义（固然，也可能有更多的层面），本质仍是统一的，只是站在了不一样的需求立场上而已。前者是程序层面的正确，后者是产品层面的更优。根本上，BUG与否，仍是取决于想要的是什么。

思考三：领头羊是否必要

17.1 “领导力”中，强调了团队领导的重要性。联想到即将开始的团队编程，领导该如何肯定？极可能出现两种状况：一种是团队里有个大牛，因为他的技术最好，你们都听他的。另外一种是你们互相讨论，少数服从多数，实际上没有一个真正的领导。实际上，因为你们都是技术人员，对项目方向上的把控水平可能都差很少，因此我认为没有领导的小团队，应该也是能够的吧？

这个是来自于Jason同窗的问题。

先说结论，要，并且很是重要。而后，请听我慢慢分析。

这位同窗的观点中，有这么一句

团队里有个大牛，因为他的技术最好，你们都听他的

这句话自己也是错的。错的缘由，思考一中已经有了详细的说明。即使在决策层面，要是决策权彻底捆绑在了一个emperor的头上，那么这就像极了封建专制制度（没有褒义或者贬义）——一人独裁。

一人独裁的好处是很明显的，显然这位同窗也明白这个好处——只要这个leader足够的靠谱。可是一人独裁的坏处，其实和好处同样的明显——只要这个leader不够靠谱，团队的结局就注定只有灭亡。中国历朝历代无数的开国之君，和亡国之君，他们都已经用他们一辈子的经历，向后人证实了这件事。

那么既然不该该一人独裁，那么，就应该绝对的民主么？答案是否认的。

反面教材，其实也很好找——如今的不少欧美国家，也就是不少人口中“皿煮”的圣地，就会存在这样的问题。是的没错，他们的三权分立、议会制，确实在权利的制约平衡上作的至关不错。

然而这样也带来了新的问题。俗话说得好——屁股决定脑壳。各方的立场与利益不太可能老是一致，既然不一致，那么在这样的体制下，不一样势力之间的通力协做将变得几乎不可能，反而彻底变成了权力的博弈战，内耗极其严重。

在人的团队中，虽然没那么复杂，可是大体道理也是相似的——若是一个团队，没有一个明确的领头羊的话，那么这个团队的秩序将是很大的问题。而秩序，则对于达到团队最优解而言，是相当重要的。简而言之，若是一个团队里面，仅仅是由于全部人水平都差很少就全部人地位绝对一致的话，那么带来的后果就是团队工做的协调和调度上将会变得极为困难，甚至出现集体负责，等于集体不负责的状况。遇了事情，意见不一，始终没人拍个板，也是一件很是麻烦的事。

就笔者自己而言，笔者也曾在总体实力较强的团队里面待过（在那个团队里面，几乎全部人都有和笔者差很少少的实力），然而那个团队依然是有个leader的存在，统筹规划着整个团队的事务进展，一板一眼调配着资源。其余人也都参与决策，各抒己见，可是犹豫不决之时，必定是leader拍板。

综上，个人结论是，领头羊是必要的，可是也不能够搞成整个团队只有惟一的领头羊参与决策。民主是必要的，可是过分的民主还不如专制来的靠谱。

思考四：编程之法

只要有助于程序逻辑的清晰体现，什么方法均可以使用，包括goto。

这话，在如今看起来是个政治不太正确的话，尤为是在这个已经普遍推荐使用结构化程序设计的年代，这听上去彷佛确实像是历史的倒退。

然而，这句话的本质确实对的。

看到有些同窗认为这话不对，其实我以为，他们只是没有理清楚因和果的关系。

首先，在软件开发的蛮荒时代，先辈们之因此提出告终构化程序设计，缘由就是，不结构化的话，程序质量将变得难以保证，工程项目也将难以维护。因而指定了一个标准，供后人参考。

然而，不要忘了，这个标准的意义在于，让软件质量变得更好。而不该该是反过来的。

早在先秦，商鞅便说过

治世不一道，便国不法古。

任何的法度，任何的规则，其根本目的都只有一个——追求最优地解决问题。

而若是死搬教条，却反而忽视了问题的本质，走的太远忘了为啥而出发的话，那就是买椟还珠的笑话了。

思考五：猪、鸡和鹦鹉的故事

加入一个团队时，要弄清楚本身在团队中投入的级别是什么，别人的指望值是什么。不要拿着卖白菜的钱，操那卖白粉的心——太不值得。

这句话，实际上是大实话，也是笔者认为不少同龄人始终没想明白的一件事。

实际上某种程度，团队成员和团队的关系，与软件产品和甲方的关系，仍是颇为相似的——前者是卖家，后者是买家。前者买卖的是生产力（以及潜在的价值），后者买卖的是产品自己。本质上，都不过是供求关系而已。

正如上文中关于bug的论述

人家要一个苹果，你给人家拉来一车梨，纵使你说这梨子如何如何好吃咱们如何如何辛苦，但是你就是没给人家须要的东西，那就是扯淡。

没错，若是你提供的东西，其实并非人家所须要的，那么你对于人家而言的价值就是零。若是你甚至还认为本身劳苦功高，认为人家有义务把你当大爷同样的供着，那就不只是没价值，还会惹人生厌了。

这些话，看上去很政治不正确。实际上，每个真正当过技术团队的leader，办过实事，招过兵买过马的leader，都会明白这句话的含义。（笔者曾经招过一些“学霸”进本身的小团队，然然后来发现这人考试能力是不差，但是给团队几乎带不来什么效益，甚至能够说干啥啥不行。不只如此，还自视甚高，认为是咱们团队对不起他。这样的人，用上面的话说，他们对于应试教育而言，是完美的。可是他们对于技术团队而言，那真的就是除了BUG一无全部了。）

其实这些车轱辘话说来讲去，根本矛盾仍是供求关系。笔者认为，这个问题也是软件工程，甚至是整个产业界，的根本问题之一。

显然，从团队成员角度，确实是应该好好掂量对方对本身的指望的：

• 若是对方对你指望很高，你却实际上根本不可能办到，那么即使人家给你开价再高，你也最好走为上策，这是作人最基本的素质。
• 若是对方对你指望很低，而你实际上能够创造比这个高的价值的话，那么笔者认为：
  • 你能够想办法让leader（或者甲方）认同你的价值，而后一块儿创造更大的价值
  • 若是上一条行不通，那么根据笔者的经验，你*给他们想要的就行了（笔者以前就遇到过难以沟通的需求甲方）
  • 固然，若是实在不爽的话，也能够选择跳槽。既然没机会兼济天下，那么独善其身也能够做为次级的选择。

从团队的角度，那么该作的是这样的：

• 尽力去观察团队成员，和他们多沟通，了解他们切实的需求，而后，尽可能给他们想要的（这很重要，供求关系，实际上也应该是双方面的，各取所需的合做关系才有稳定的可能）
• 若是沟通了，发现这样的人真的没有价值的话（固然也可能只是对咱们团队没用），那么也不必强留，看着办便可（固然，条件容许的话也能够先留着，毕竟多条人脉总有用得着的时候）

以上，就是笔者对团队内供求关系的理解。

软件的起源

• 化学家和统计学家约翰·图基（John W. Tukey）在1958年撰写一篇科学文章时，首次使用“软件”这一术语。据报道，他早在1953年就已经提出这个词，用来标记计算机程序（即“软件）与使用这些程序的计算机（或“硬件”）之间的区别。软件的概念被提出。
• 软件工程的最初概念，是1968年Margaret Hamilton在阿波罗计划期间提出来的。软件，开始和工程接轨。
• 1968年NATO会议上首次提出“软件工程”（Software Engineering）的概念，提出把软件开发从“艺术”和“个体行为”向“工程”和“群体协同工做”转化。其基本思想是应用计算机科学理论和技术以及工程管理原则和方法，按照预算和进度，实现满用户要求的软件产品的定义、开发、发布和维护的工程。今后也诞生了一门新的学科——软件工程。软件工程这门学科算是正式诞生了。

冷知识、趣闻

世界上第一个BUG

1945年9月，美国海军编程员、编译器的发明者格蕾斯·哈珀正带着他的小组构造一个叫“马克二型”的计算机。这个计算机使用了大量的继电器， 一种电子机械装置。虽然已进入9月，但天气依然炎热，房间里没有空调， 全部窗户都敞开散热。为了早日将“马克二型”构造完成，格蕾斯·哈珀带着小组成员夜以继日的工做。

所谓好事多磨，在9月9日下午三点，电视剧情节般的意外如期而至。忽然，“马克二型”死机了，而技术人员尝试了许多方法，最后才定位到第70号继电器出错。要知道，“马克二型”用了1万7千多个继电器。

既然找到是70号继电器出错了，那么接下来的事情也就好办了。格蕾斯·哈珀仔细观察这个出错的继电器，而后发现一只被继电器打死了的飞蛾躺在中间。因而格蕾斯·哈珀当心的用镊子将飞蛾夹出来，用透明胶布将飞蛾贴到“事件记录本”中，并注明“第一个发现Bug的实例”。

没错，世界上第一个BUG，还真就是一直虫子。

千年虫问题与2038危机

千年虫问题（摘自百度百科）：

计算机2000年问题，又叫作“千年虫”、“电脑千禧年千年虫问题”或“千年危机”。缩写为“Y2K”。是指在某些使用了计算机程序的智能系统（包括计算机系统、自动控制芯片等）中，因为其中的年份只使用两位十进制数来表示，所以当系统进行（或涉及到）跨世纪的日期处理运 算时（如多个日期之间的计算或比较等），就会出现错误的结果，进而引起各类各样的系统功 能紊乱甚至崩溃。所以从根本上说千年虫是一种程序处理日期上的bug（计算机程序故障），而非病毒。

2038危机（摘自百度百科）：

也许你们都已经知道计算机的2000年问题是什么概念，可是何时又冒出来一个2038年问题的呢？

用C语言编制的程序不会碰到2000年问题，可是会有2038年问题。这是由于，大多数C语言程序都使用到一个叫作“标准时间库”的程序库，这个时间库用一个标准的4字节也就是32位的形式来储存时间信息。

当初设计的时候，这个4字节的时间格式把1970年1月1日凌晨0时0分0秒（这个时间名叫 the Unix Epoch）做为时间起点，这时的时间值为0。之后全部的时间都是从这个时间开始一秒一秒累积得来的。

比方说若是时间已经累积到了919642718这个数值，就是说这时距离 the Unix Epoch已通过去了919642718秒，换算一下就应该是1999年2月21日16时18分38秒。

这样计算时间的好处在于，把任意两个时间值相减以后，就能够很迅速地获得这两个时间之间相差的秒数，而后你能够利用别的程序把它换算成明白易懂的年月日时分秒的形式。

要是你曾经读过一点儿关于计算机方面的书，你就会知道一个4字节也就是32位的存储空间的最大值是2147483647，请注意！2038年问题的关键也就在这里———当时间一秒一秒地跳完2147483647那惊心动魄的最后一秒后，你猜怎么样？

答案是，它就会转为负数也就是说时间无效。那一刻的准确的时间为2038年1月19日星期二凌晨03:14:07，以后全部用到这种“标准时间库”的C语言程序都会碰到时间计算上的麻烦。

这就是2038年问题。

其实，这类的问题还有不少：

• 曾经，现代计算机之父冯诺依曼，表示在计算机上编写程序是没有意义的事情，应当花时间在硬件上。而后，软件时代就到来了。
• 曾经，比尔盖茨表示，64KB内存足以应对世界上一切的程序需求。而后，2000年先后的内存都是上百MB的级别。
• 曾经，人们认为，两位十进制数表示年份，确定是够的。而后，2000年如期而至。
• 曾经，人们也觉得，timestamp弄个C语言的int32类型，就铁定够用了。而后，2038年也不远了。
• 曾经，人们也认为，MD5是永久坚不可催的。而后，如今的MD5在存储海量数据的撞库面前根本不堪一击，用MD5加密的网站密码，已经属于能够轻松破解的类型了。

因而乎，在历史的进程下，以后人们还会面对哪些曾经呢？让咱们拭目以待吧。

项目管理软件

软件	优势	缺点
git	一、功能齐全 二、支持各类复杂状况的代码管理 三、与现代开发中的团队协做相性优秀 四、主流版本控制，各大网站支持丰富	一、原生git为纯命令行，对新手不算太友好
svn	一、图形界面 二、与windows相性良好	一、图形界面（没错，这也是缺点） 二、功能面不如git，没有git同样高的可玩性 三、总体生态远远不如git
Github	一、开源代码多，群众基础强大 二、操做简单，即上即用	一、（天朝限定）速度慢 二、私有仓库是收费的
BitBucket	一、私有仓库无限制 二、功能丰富，专为团队开发设计	一、（天朝限定）速度慢 二、没有太多开源代码（至少远远比不上github） 三、代码闭源
Gitlab	一、代码开源，自行安装，自行配置 二、完善的团队协做支持 三、（天朝限定）速度快 四、完美的ci支持	一、私有的gitlab基本不存在开源代码二、免费版只提供部分功能