现代软件工程 第一周博客作业

自我介绍

我是中国科学技术大学信息科学技术学院电子工程与信息科学系的大四学生，现在感到非常幸运能够来到msra实习，跟优秀的人合作和学习。

如果说自己的闪光点的话，我觉得我的应该是喜欢涉猎历史地理方面的东西，这种了解和思考得相对比较多吧。别的方面最多就是，身边的人都觉得我是个好人吧。

 

现状、经验和计划

 

我是信息学院电子工程与信息科学系的。如何选择这个专业说来话长。最初报考大学的时候，我对IT的了解仅限于高中的时候的VB编程课，也是由于在这个课堂的愉快经历，我希望大学中学习IT相关专业。招生老师问我知不知道计算机学院和信息学院的区别我都说不出个所以然，于是招生老师说，你选择信息学院比较好，因为这个学院相对未来选择较多，进去了解过以后再决定是否学习计算机也不迟，于是我便是信息学院的一名学生了。大二选择专业时，我已经学习了计算机的一些基本课程，也学习了一些电子电路相关的课程，参加了校内校外多个软件/硬件相关的比赛，可以说是对研究方向有所了解了。于是我想，相比与电路，我更喜欢控制和信号处理，于是选择了这个专业。

技能调查表中我的选择：

	目前水平	理想水平	提高手段
语言（偏后端）	3	9	练习，提高代码量，多涉猎各种算法和领域
软件测试	2	8	学习和掌握测试工具和方法
需求分析	1	8	分析典型案例，做真实的需求分析
行业洞察力	1	8	多读paper，多了解行业最新进展，学习行业历史
团队协作	4	10	在团队合作中加强交流，拒绝客气
理论素养	3	9	在工作的同时思考这样做在学习过的课程中是否有迹可循，从而在下一步工作时可以期望由此获得指导

之所以这样选择，是基于我目前处于并将长期（3-5年）处于研究生/博士阶段，参与和管理大型项目的知识能力事实上我短期内并不会用到，而以我有限的经验，并不能有理有据地评价和管理自己这种能力。理想水平是指在我对自己未来的工作期望中，我应该达到的水平。

我为何要来上这门课，最基本的原因是没有这6个学分我没有办法毕业。当然我可以划水，但是我觉得如果在这门课上我认真参与，一定会收获很大（基于在中科大校内邓宏平老师软件工程课上的经验而来，谢谢他精彩的课程）。羞愧地说，在大三的某个阶段我确实是有上课无用的想法的，事实（GPA）证明这是大错特错的。上课听讲可以获得一些在自学中无法获得的东西，知识和获取知识的方法都在其中。

关于借鉴与抄袭，我的看法是，在编写程序和文档时，有些基础的东西确实不需要每次都重新搭建，如通用算法的实现和技术文档的模板，然而如果涉及到的代码是作者的创新想法/没有开源/注明引用需咨询/用途是商业盈利等情况，或是照搬技术文档的内容，就可以说是抄袭/剽窃。

我对将来的规划是学生阶段专注做研究，毕业后做研究对项目的transfer。非常幸运我在本科阶段就能够来到MSRA这个环境，可以接触到研究、项目各种方面的大牛，我要利用好一年的时间，学习他们的不同的思维方式和工作方式。

 

阅读博客：

进入2012 -- 回顾我走过的编程之路，不要轻易在简历上写我热爱编程，我热爱学习

发现大牛之所以是大牛，不是面临的机遇多么好，自己的天赋多么高，就是充分条件了。想要成为大牛，首先要有的是对行业的热爱和坚持。我曾经读过一本小说《一个程序员的奋斗史》（https://book.douban.com/subject/24696924/），里面主人公的经历就是作者自己的经历，他从本科毕业的真·菜鸟一步步走到博客大牛，微软最有价值专家（MVP），拥有众多粉丝，没有他过人的意志力和在消极环境中不停止提高自我的信念是不可能的。可能大多数人（比如我）现在远远不能够成为大牛，除非我们付出超人的精力、体力和意志力，当然还必须保持自己对计算机和软件行业的热爱与探索欲。幸运的是，年轻的我还有足够的精力体力意志力，也相信自己在不短的时间内不会消减对计算机的探索欲。我希望能够在未来几年的学习中掌握更多的技术、思想、和方法，也做出自己的探索和实践，希望能够不荒废这几年，能够在毕业时在简历上有底气地写：我热爱编程和学习。

 

《构建之法》阅读疑惑

 

（1）关于“全栈工程师”

有人说一个人就可以快速成长成为一名全栈工程师，这让我想起街头卖艺的单人乐队（One-man-band），他们什么都会一些，可以很快地演奏一些曲子。与之对立的，是只研习某一乐器的乐手，你愿意花钱听哪种演奏呢？当一个小孩说长大了要做音乐家，你会让他走上担单人乐队的道路么？（《构建之法第三章，P53）

这一段似乎表达了所谓“全栈工程师”是如单人乐队的卖艺人，其技术并不能登堂入室不可能进维也纳金色大厅，关于这一点我有点疑惑，正如这一节的标题“专于精的关系”，看起来作者并不看好这种职业发展方向。

当我们谈论“全栈工程师”的时候，我们说的究竟是“交响乐作曲家写各个乐器的乐谱”，还是“演奏家满场奔走，操作各种乐器”呢？（《构建之法第三章，P53）

个人认为，一个不懂得交响乐团所有乐器的作曲家是写不出交响乐乐谱的，这里的不懂得是指，管乐吹不响/弦乐拉不响/鼓敲不响，或是只会把它们乒乒乓乓弄出do re mi，而不能符合音乐主题地让乐器协调起来。同样道理，全栈工程师也需要掌握至少理解前端后端、各种平台、不同的语言，做项目时使用哪种技术并不是根据工程师擅长哪种选择的，而是综合考虑各种技术的优劣，并结合工程师的实际能力来决定的，这时如果工程师掌握的技术比较多、学习能力非常强，无疑是有利的，这是我认为的全栈工程师的优势所在。如果新年联欢会上一个唱歌的节目临时需要伴奏，是同事中为了撩妹会弹吉他、跟家人学了手风琴、作为爱好会打鼓和吹口琴的爱好者，还是找业余时间沉浸于练习吹唢呐并在各种活动中独奏过的业余演奏家呢？

（2）关于合作的不同阶段和技巧（第四章 4.6节）

这一小节以两人跳舞为例，描述了两人合作的不同阶段和在这之中的一些技巧。书中将两人合作分成了五个阶段：

萌芽阶段

磨合阶段

规范阶段

创造阶段

解体阶段

然而，我在与人合作中，不论是两人合作还是团队合作，总会在磨合阶段陷入问题，不知道如何解决。问题在于，我总是在与人合作已经开始以后，仍然只能用“萌芽阶段”的客客气气的方法对待队友，不管队友是带飞大佬还是消极怠工，因此，我们总是陷入客客气气地自己完成自己觉得应该完成的工作，即使互相不满意也不会认真地讨论问题，最多是谁的进度慢道一句歉，而其他人选择原谅并帮他做了或是放弃掉他没有实现的部分，最终项目要么只有一两个人挑大梁，要么全崩。但是我不知道应该怎么在团队合作中不客气地提出意见，特别是对方道歉说我错了但是实际上不改得情况下。

（3）关于PM

《构建之法》第九章介绍了微软公司的PM职位，书中列出了微软PM与其他公司的项目经理的区别（P185）：

Project Manager	Program Manager
是团队的行政领导，带领大家在项目中工作	和大家平等工作，推动团队完成软件的功能
通常是团队和外界打交道的唯一代表	一个团队可以有很多PM
对项目的功能有最后的决定权	和其他团队成员一起形成决议
管事也管人	管事不管人
不一定做具体工作	一定做具体工作

我读了《构建之法》第九章中关于微软的PM职位相关的内容，了解到PM的工作内容和应该具备的素质，然而，我还有一些疑惑，可能因为是微软内部的人事问题，除了这个职位不是管理岗位以外，我没有办法在搜索引擎上得到更多的关于PM岗位设置的信息。我的问题是PM在团队的人际关系中通常是怎样的角色，既然是与团队成员地位平等，那么PM一般是有经验和资历的老人吗？如果不是，有没有什么机制可以保护PM，或者说，是什么让团队成员信任并没有在做开发和测试的跟自己资历差不多的PM的决定呢？

（4）“Walkman”和“Walking Man”

索尼公司在大型收录机领域取得成功之后，其创始人盛田绍夫想进一步让所有人都能随时听到音乐，有了随身听的想法。……公司的专家们认为……大众不会喜欢……最后产品快要上市时，大家要给它取名字，Walkman是最后的候选名字之一。公司请教了语言专家，语言专家语重心长地指出，Walkman是不符合语法的！动词不能修饰名词，改成Walking Man才是正解！

值得庆幸的是，盛田绍夫没有听专家的建议。Walkman（Walking Man）上市了，…… 开辟了一个市场，引起许多厂商的效仿。

《构建之法》第16章 P348

这里我有点不太理解，为什么语言专家的建议不应该被采纳。。我觉得他说的很有道理。“Walkman”这个名字里面蕴含了一些商业和运营的技巧吗？

（5）关于生态创新

在《构建之法》第16章16.1节中，讲了八条创新迷思，其中第三条是

在现实中，好的主意不一定赢

然后举出了更符合统计规律的键盘布局由于与大众习惯不兼容而无法应用的例子。后来在第六条迷思：

技术的创新是关键

中讲到，除了技术创新还有很多方面的创新，这之中有一个

生态系统的创新

iPhone/iPod/iTunes客户端软件/iTUnes网站在音乐购买/同步/播放整个流程中整合的创新。如果将Apple的产品与同类产品比较，各有千秋，但是把各个环节整合得如此流畅，打造成一个盈利的生态系统，Apple公司远远领先其他竞争者。

关于Apple公司成功的生态创新，我觉得很大一部分原因是它在手机市场、MP3市场的影响力。我的疑惑时，如果是一个小型的或是市场影响力有限的企业，想要做生态创新是有可能的吗？最近国内的小米公司在做智能家居，想要做成生态链，然而我使用的一些小产品并没有让我感到十分惊艳，只是新奇而已，而那些相比较贵的产品在没有与小米的主要产品（手机等）捆绑的情况下，有可能能够像苹果一样形成一个排他的生态链吗？