当然，比这个更重要百倍的还是实实在在的思考，这也是标题如此命名的原因 我在本课程的目标 在原有实践经验的基础上，系统化学习软工领域的理论知识，总结以前以及现在的得与失，提高自身知识水平（
好吧，既然是概述，那么就先说点什么，光一个表格个人感觉表现力太有限了。如果对笔者的自报家门没啥兴趣的话，可以直接跳到下一节。
首先，本人很早就有计算机方面的技术背景（早到什么程度呢，我学编程那会，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）的概念，提出把软件开发从“艺术”和“个体行为”向“工程”和“群体协同工作”转化。其基本思想是应用计算机科学理论和技术以及工程管理原则和方法，按照预算和进度，实现满用户要求的软件产品的定义、开发、发布和维护的工程。从此也诞生了一门新的学科——软件工程。软件工程这门学科算是正式诞生了。
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加密的网站密码，已经属于可以轻松破解的类型了。
于是乎，在历史的进程下，之后人们还会面对哪些曾经呢？让我们拭目以待吧。
项目管理软件2、支持各种复杂情况的代码管理
3、与现代开发中的团队协作相性优秀
4、主流版本控制，各大网站支持丰富 1、原生git为纯命令行，对新手不算太友好 svn 1、图形界面
2、与windows相性良好 1、图形界面（没错，这也是缺点）
2、功能面不如git，没有git一样高的可玩性
3、整体生态远远不如git Github 1、开源代码多，群众基础强大
2、操作简单，即上即用 1、（天朝限定）速度慢
2、私有仓库是收费的 BitBucket 1、私有仓库无限制
2、功能丰富，专为团队开发设计 1、（天朝限定）速度慢
2、没有太多开源代码（至少远远比不上github）
3、代码闭源 Gitlab 1、代码开源，自行安装，自行配置
2、完善的团队协作支持
3、（天朝限定）速度快
4、完美的ci支持 1、私有的gitlab基本不存在开源代码
2、免费版只提供部分功能