标签：style 细节 甲骨文公司 设计思想 评价 span 个人 也有 自身
如何衡量一个软件工程师
如何衡量一个软件工程师？这是《构建之法》第三章的核心问题。第一章讲述了团队的流程，第三章则是对第一章的具体描述，从笼统的团队具体到个人。软件开发流程不光指团队的流程，还包括了个人开发流程，因为软件团队是由个人组成的，简而言之，个人在团队中也有独立的流程。那么问题来了，如果我们去面试，该如何定义我们自身呢？又或者说，看到一个同行的软件工程师，该如何形容他的技术？
第三章通过对足球的比喻，向我们形象的阐述了这个问题的关键。足球中有传接、盘带、射门等具体技术，映射到软件工程上来，一个软件工程师也是这样，他们也有自己的成长。就像我们从小开始学习，一步一步，从小学升到初中高中，再到大学，甚至还有研究生等，我们的知识量在逐渐的积累，所学习的内容也在逐步的变难。对于软件工程师的成长，书上是这么描述的：积累软件开发相关的知识，提升技术技能；积累问题领域的知识和经验；对通用的软件设计思想和软件工程思想的理解；提升职业技能；实际成果。这是针对个人的成长，其实要想看清个人的成长，最直接的就是出套“试卷”给他做做。也就是询问他的成果，甚至对他进行实战考验。
再从未来看向现在，在刚过去的上海市等级考试中，我考了97分的成绩达到了优秀，但这只是二级罢了，漫漫考级路遥远着呢，考级也算是对软件工程师评价的一个标准。通过阅读，我才了解到，并不是说只有国家或省市才有等级考试，你拿到了证书，的确国家承认你有相应的能力，但是很多大公司自己本身就有一套全面的等级考核标准。比如说微软的MCP,甲骨文公司的OCP等等，如果你通过了上述考核内容，那么你加入他们的公司，才会更有底气。
整个第三章我最获益的就是一句话：技能的反面是“解决问题”。我们大学生在刚走出校门的时候去面试，如果面试官给我们出个问题，比如现场敲代码，我觉得以我这个水平，绝对不敢说不犯错。问题不在于多难，多复杂，而是我们本身对这些问题不够熟悉。面试官给你的是大问题，是最终实现的方向，那么小问题呢。小问题就是你在敲代码的过程中遇到的一系列细节问题，比如说漏打字母，漏敲分号，甚至串行等因为不细心而犯下的错误。我们在出校门前，多多练习，不管问题大小，把那些低层次的问题都解决了，那么我们才算是真正意义上的解决了问题，才算是学到了技能。
标签：style 细节 甲骨文公司 设计思想 评价 span 个人 也有 自身
原文地址：http://www.cnblogs.com/hynbrx/p/6746160.html
