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

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的概念提出把软件开发从“艺术”和“个体行为”向“工程”和“群体协同工作”转化。其基本思想是应用计算机科学理论和技术以及工程管理原则和方法按照预算和进度实现满用户要求的软件产品的定义、开发、发布和维护的工程。从此也诞生了一门新的学科——软件工程。软件工程这门学科算是正式诞生了。冷知识、趣闻世界上第一个BUG1945年9月美国海军编程员、编译器的发明者格蕾斯·哈珀正带着他的小组构造一个叫“马克二型”的计算机。这个计算机使用了大量的继电器 一种电子机械装置。虽然已进入9月但天气依然炎热房间里没有空调 所有窗户都敞开散热。为了早日将“马克二型”构造完成格蕾斯·哈珀带着小组成员夜以继日的工作。所谓好事多磨在9月9日下午三点电视剧情节般的意外如期而至。突然“马克二型”死机了而技术人员尝试了许多方法最后才定位到第70号继电器出错。要知道“马克二型”用了1万7千多个继电器。既然找到是70号继电器出错了那么接下来的事情也就好办了。格蕾斯·哈珀仔细观察这个出错的继电器然后发现一只被继电器打死了的飞蛾躺在中间。于是格蕾斯·哈珀小心的用镊子将飞蛾夹出来用透明胶布将飞蛾贴到“事件记录本”中并注明“第一个发现Bug的实例”。没错世界上第一个BUG还真就是一直虫子。千年虫问题与2038危机千年虫问题摘自百度百科