概述
好吧，既然是概述，那么就先说点什么，光一个表格个人感觉表现力太有限了。如果对笔者的自报家门没啥兴趣的话，可以直接跳到下一节。
首先，本人很早就有计算机方面的技术背景（早到什么程度呢，我学编程那会，Google在大陆还能直接上，QQ号还都是8位的），在编程方面，私以为还算是略知一二，或者说有那么一点点的经验。
其次，本人在大一开始就进行过实用系统的开发，其中包括：
- Questionor刷题网站（链接：https://questionor.cn，现在每届北航学子刷航概题还都在这上面）
- 同袍APP（最懂北航学子的手机app）
- 若干以赚钱为目的的外包项目（大概，在大一就能绰绰有余的cover掉包括学费在内的一切个人支出）
嘛。。。先打住，再这样下去实在有点像是产品软文了。[捂脸]
此外，笔者带过不止一个技术开发团队，作为团队的leader。踩过坑，也从屎山里面爬出来过；胜利过，也失败过；团队里大家一块嗨过，也层不止一度出现严重分歧，甚至分崩离析过。其中，私以为还算是有一点点略微的心得。
说这些的目的呢，其实特别简单。笔者从没认为自己如何如何，只是阐述一下客观事实，做一些微小的工作，或者说，铺垫。以防止下面看到有些内容的时候，被认为是在分享刚编的故事。
好了打住，先说到这。下面是正文。
个人的思考
其实说来，本人的疑惑和思考可能和大部分同学有些不一样。所以我就尽量按照我的方式来表达，并且可以的话也说一些我对其他同学疑惑的理解吧。
思考一：PM做开发和测试之外的所有事情
这话确实很有道理，说的也没错。（）
然而，要是，PM也是技术背景出身，甚至还是有一定经验的技术人员呢？
笔者自己就遇到过类似的情况。
在笔者之前早期带的团队里面，就是会出现有的时候全体进展缓慢的情况。这个其实也正常，都是身边的同学，不是谁都有写过十几年的代码的。
于是，尤其是ddl迫近的时候，笔者我当时遇到这样的情况，常常自己就看不下去了。一拍腿，老子自己上。
果不其然，自己一上阵，问题最终就很快被解决了。
如果只从结果的角度来看，这当然是皆大欢喜——这世上从来就没有过啥好手段坏手段，能解决问题的就是最好的。
对于临时的小队伍来说，这还算好，最起码结果是好的。然而之后发生的事情证明，这种做法对于长期的团队来说，这是一件非常危险的事。
笔者带过的一个团队，当时就这么干的。期初几次，笔者一个人单挑的成效都很不错。越到后来，就发现大家都开始起不到作用。笔者甚至一度很生气，去质问过他们，甚至逼过他们。可是最终，笔者得出了一个令人绝望的答案——他们真的啥也不会了。
或者换句话说，在该锻炼队伍成员，该磨合团队协作模式的时候，这些事情一样都没有做。最终，这个所谓被称之为团队的东西，完全成了由一个强力单体，和若干起不到任何作用的人，构成的乌合之众。对于强力单体，看似有团队，实则孤立无援，最终迟早被硬生生累垮。对于其他人，看似有团队，实则毫无归属感，自然不可能愿意卖力，就算愿意，也并不能真正的帮上忙。
这还不算完，如果有一天，这个团队的强力单体出现了状况的话，那么，这个所谓的团队，会立刻面临灭顶之灾，且毫无自保的能力。
这样的故事其实历史上已经上演过无数次：
- 诸葛亮鞠躬尽瘁，死而后已。他在的时候，把三国中最弱的蜀国治理的井井有条。然而他事必躬亲，于是导致的局面就是，其他不如他的人才完全没有成长的空间。等他一死，蜀国一下子就出现了严重的人才断层。很快，蜀国就灭亡了。
- 月厨们都知道，Saber生前的经历。甘愿当圣人，想要一己之力拯救臣民。然而等有一天光辉不再的时候，就注定要面临生命中的卡姆兰之丘。
所以，个人认为。就算PM，或者说领导，有着极强的个人输出能力，也绝对不可以随随便便就亲自上阵（当然，偶尔救急可以，但是绝不可以成为常态）。不是因为什么领导的架子，而是出于整个团队的可持续发展考虑。
不过，这里面具体的分寸，也确实是一个值得深思的问题。从一碗鸡汤爬出来，立马跳进另一碗鸡汤，也不是正确的思考问题方式。笔者也认为，自己目前这块实际上做得还远远不够成熟。
思考二：Bug的定义
问题源自guzhanpeng同学的博客。第一个疑问，里面说到了bug的定义问题。
首先我想说的是，Bug本身就不是一种单一的定义。
这位同学百度搜索到的结果是：
这个当然没有错，这个是程序设计意义上的bug。
然而，实际上从用户、从需求的角度来说，不符合需求的，就是bug。这个bug是产品需求意义上的bug。这两者并不存在矛盾抑或是冲突。
或者也可以说，bug可以一般性定义为和期望不符的状态及其诱因：
- 对于程序而言，结果错误、运行时错误、崩溃，这确实就是和期望的正确结果不符的状态。
- 对于产品而言，你程序就算对了，但是人家要个苹果你给人家运来一车梨，还美其名曰梨很好吃我们也很辛苦，这显然就是在扯淡了。没错，这也是与期望状态不符的状态。
综上，其实所谓bug的两种定义（当然，也可能有更多的层面），本质还是统一的，只是站在了不同的需求立场上而已。前者是程序层面的正确，后者是产品层面的更优。根本上，BUG与否，还是取决于想要的是什么。
思考三：领头羊是否必要
这个是来自于Jason同学的问题。
先说结论，要，而且非常重要。然后，请听我慢慢分析。
这位同学的观点中，有这么一句
这句话本身也是错的。错的原因，思考一中已经有了详细的说明。即便在决策层面，要是决策权完全捆绑在了一个emperor的头上，那么这就像极了封建专制制度（没有褒义或者贬义）——一人独裁。
一人独裁的好处是很明显的，显然这位同学也明白这个好处——只要这个leader足够的靠谱。但是一人独裁的坏处，其实和好处一样的明显——只要这个leader不够靠谱，团队的结局就注定只有灭亡。中国历朝历代无数的开国之君，和亡国之君，他们都已经用他们一生的经历，向后人证明了这件事。
那么既然不应该一人独裁，那么，就应该绝对的民主么？答案是否定的。
反面教材，其实也很好找——现在的很多欧美国家，也就是很多人口中“皿煮”的圣地，就会存在这样的问题。是的没错，他们的三权分立、议会制，确实在权利的制约平衡上做的相当不错。
然而这样也带来了新的问题。俗话说得好——屁股决定脑袋。各方的立场与利益不太可能总是一致，既然不一致，那么在这样的体制下，不同势力之间的通力协作将变得几乎不可能，反而完全变成了权力的博弈战，内耗极其严重。
在人的团队中，虽然没那么复杂，但是大致道理也是类似的——如果一个团队，没有一个明确的领头羊的话，那么这个团队的秩序将是很大的问题。而秩序，则对于达到团队最优解而言，是至关重要的。简而言之，如果一个团队里面，仅仅是因为所有人水平都差不多就所有人地位绝对一致的话，那么带来的后果就是团队工作的协调和调度上将会变得极为困难，甚至出现集体负责，等于集体不负责的情况。遇了事情，意见不一，始终没人拍个板，也是一件非常麻烦的事。
就笔者本身而言，笔者也曾在整体实力较强的团队里面待过（在那个团队里面，几乎所有人都有和笔者差不多少的实力），然而那个团队依然是有个leader的存在，统筹规划着整个团队的事务进展，一板一眼调配着资源。其他人也都参与决策，各抒己见，但是犹豫不决之时，一定是leader拍板。
综上，我的结论是，领头羊是必要的，但是也不可以搞成整个团队只有唯一的领头羊参与决策。民主是必要的，但是过度的民主还不如专制来的靠谱。
思考四：编程之法
这话，在现在看起来是个政治不太正确的话，尤其是在这个已经广泛推荐使用结构化程序设计的年代，这听上去似乎确实像是历史的倒退。
然而，这句话的本质确实对的。
看到有些同学认为这话不对，其实我觉得，他们只是没有理清楚因和果的关系。
首先，在软件开发的蛮荒时代，先辈们之所以提出了结构化程序设计，原因就是，不结构化的话，程序质量将变得难以保证，工程项目也将难以维护。于是指定了一个标准，供后人参考。
然而，不要忘了，这个标准的意义在于，让软件质量变得更好。而不应该是反过来的。
早在先秦，商鞅便说过
任何的法度，任何的规则，其根本目的都只有一个——追求最优地解决问题。
而如果死搬教条，却反而忽视了问题的本质，走的太远忘了为啥而出发的话，那就是买椟还珠的笑话了。
思考五：猪、鸡和鹦鹉的故事
这句话，其实是大实话，也是笔者认为很多同龄人始终没想明白的一件事。
实际上某种程度，团队成员和团队的关系，与软件产品和甲方的关系，还是颇为类似的——前者是卖家，后者是买家。前者买卖的是生产力（以及潜在的价值），后者买卖的是产品本身。本质上，都不过是供求关系而已。
正如上文中关于bug的论述
没错，如果你提供的东西，其实并不是人家所需要的，那么你对于人家而言的价值就是零。如果你甚至还认为自己劳苦功高，认为人家有义务把你当大爷一样的供着，那就不仅是没价值，还会惹人生厌了。
这些话，看上去很政治不正确。实际上，每一个真正当过技术团队的leader，办过实事，招过兵买过马的leader，都会明白这句话的含义。（）
其实这些车轱辘话说来说去，根本矛盾还是供求关系。笔者认为，这个问题也是软件工程，甚至是整个产业界，的根本问题之一。
显然，从团队成员角度，确实是应该好好掂量对方对自己的期望的：
- 如果对方对你期望很高，你却实际上根本不可能办到，那么即便人家给你开价再高，你也最好走为上策，这是做人最基本的素质。
- 如果对方对你期望很低，而你实际上可以创造比这个高的价值的话，那么笔者认为：
- 你可以想办法让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危机
千年虫问题（摘自百度百科）：
2038危机（摘自百度百科）：
其实，这类的问题还有很多：
- 曾经，现代计算机之父冯诺依曼，表示在计算机上编写程序是没有意义的事情，应当花时间在硬件上。然后，软件时代就到来了。
- 曾经，比尔盖茨表示，64KB内存足以应对世界上一切的程序需求。然后，2000年前后的内存都是上百MB的级别。
- 曾经，人们认为，两位十进制数表示年份，肯定是够的。然后，2000年如期而至。
- 曾经，人们也以为，timestamp弄个C语言的int32类型，就铁定够用了。然后，2038年也不远了。
- 曾经，人们也认为，MD5是永久坚不可催的。然后，现在的MD5在存储海量数据的撞库面前根本不堪一击，用MD5加密的网站密码，已经属于可以轻松破解的类型了。
于是乎，在历史的进程下，之后人们还会面对哪些曾经呢？让我们拭目以待吧。