软件工程，不只是编码。
——题记
最近通读了一遍Code Complete，虽然看的不算十分细致，但是感触还是有不少。
在这学期开始之前，我始终以为，软件工程，不过就是一个编码的过程，充其量不同的人编码的效率不同罢了。不过，读过这本书以后，彻底改变了我的肤浅的看法。
书中的第一章叫做“欢迎进入软件构建的世界”，一开始就提及软件构建所涉及的活动：定义问题，需求分析，规划构建，软件架构，详细设计，编码与调试，单元测试，集成测试，集成，系统测试，保障维护等等。可以说，软件的构建，是一个十分重要的过程。将做一个项目的精力集中于构建活动，绝对是磨刀不误砍柴工，可以大大提高程序员的生产率。书中有一个食物链的例子就特别形象和有说服力：健康的生态环境中，海鸥吃新鲜的鲑鱼，鲑鱼吃新鲜的青鱼，青鱼吃新鲜的水蝽。这是一条健康的食物链。 如果环境被污染了，水蝽在污染的水域游泳，那么海鸥，食物链的最后一环吃下的不仅仅是是不健康的鲑鱼体内的垃圾，还有青鱼，水蝽体内的污染物。软件开发中，架构师吃掉需求，设计师吃掉架构，程序员，软件食物链的最后一环，消化掉设计。如果一开始就被污染了，我们就不要指望程序员快乐了。整个软件都会具有放射性，周身都是缺陷，绝对导致程序员脾气暴躁、营养失调。特别是在我们这种小规模的团队里，每个人都担负着不知一项任务，若是没有一个充分的构建过程，一定会有更大的影响。所以，项目一开始的构建活动就决定了最终的成功与否。
另一点记忆深刻的是，软件构建的核心就是管理复杂度。书中用了不少的篇幅来讨论变量名、语句、类名等等程序的基本要素，和很多改善和调整代码的方法，这一点在其他同类书籍上是很少提及的。而这些关于基本要素的提及，正是围绕管理复杂度来展开的。虽然说我们到现在为止也没有写过什么大规模的项目，但是对这些细节的重要性还是有一定体会的。比如说变量名，若是像最开始学习编程的时候一样用a、b、c等命名，那估计第二天就看不懂自己的程序了。再比如说各种嵌套、循环语句，若是动辄用个五六层for循环嵌套各种条件语句，那估计写完以后就看不懂了。所以说，管理程序的复杂度是软件构建的核心。说白了，就是让自己的程序可读性好，清晰明了。
还有一点是，首先为人写程序，其次才是为机器。作者说计算机不关心你的代码是否好读，它更善于读二进制指令，而非高级语言的代码。我想这一点是很明显的，所以说，编写可读性好的代码，是为了便于别人看懂。每个coder一定都有研读别人代码的经历，面对那些程序混乱而且没有注释的代码，你是不是会感觉到非常无奈呢。所以说，即使你觉得只有自己才会读的代码，也不要太过随意的编写，因为经常可能有人需要修改你的代码。况且，可读的代码写起来并不比混乱的代码多花时间吧。我想，一个好的coder写出来的代码一定是可读性好的代码。So，我们应该尽可能让自己写出来的代码成为一种艺术与科学相互融合的产物，那一定会给coder带来无法想象的满足感。
另一方面，在读完老师的软工讲义后，也有些新的感触。首先，老师的博文比Code Complete有意思多了，虽然很多人说Code Complete的语言风格很幽默，但是在读了老师的博文和大体看了一下《移山之道》后，我还是觉得Code Complete的幽默感稍微差一点。读讲义后主要的感想有如下几点：
团队合作其实并没有我们想象的那么简单。以前几个人在一起合作一个项目的时候，只是一起写代码，讨论讨论而已。实际上，团队合作需要做不少的工作。首先，明确的分工是必须的，不同的成员要在不同的方面投入精力，像PM之类的作用我们以前根本没有意识到，还有测试的工作也是很重要的一环。
创新，并不是一个简单的事情。像老师上课讲的一样，有的人也许能提出或者做出一些新的东西，取得一些不错的受益，但是第一个创新者往往不是这个行业最后的霸主。怎样面对竞争，怎样解决用户需求，使出什么奇特的招数，给用户什么样的好处，这些才是关键。
还有一个是软件工程师的职业道德问题。流氓软件，真是一种日益泛滥的东西。用户信息泄露，也是个日益严峻的问题。就像老师说的，职业道德不是万能的, 但是没有职业道德是万万不能的啊…
感想颇多，但是大多都不知从何说起，就先写到这吧。
至于问题，有以下两个：
第一是对敏捷编程的不理解。如果说敏捷编程一般是对产品可靠性不高、用户需求经常变化、有高容错率的小规模项目适用，那为什么敏捷编程还会这么热呢？难道对于某些大公司也会经常采用这样的方式，这样的方式在软件的构建上不会不够充分吗？
第二是关于测试和反馈的。现在的软件测试确实做的不错了，但是总是会有一些bug无法发现。那么在软件正式发布后，这些bug一定会对用户体验有所影响。那么，怎么样来让用户愿意及时通过有效途径来反馈这些问题？我想这是很现实的一个问题，因为我们每个人都可能经常遇到软件崩溃或者出现一些bug的时候，但真正愿意去反馈的时候又有多少呢？
