构之以技术，付之以匠心——读《构建之法》有感

       开发人员容易陷入这样一种魔怔的状态：技术为大，编码为重，其他都是浮云。但其实纵观软件的生命周期，从需求分析到后期维护更新，每一步都有讲究。编码，并不是唯一。这个感受在我拜读了邹欣老师的《构建之法》后更为深刻。

1.需求分析阶段

万事开头难，需求分析作为软件开发的开始，自然也是令人头疼。说真的在学校做课设时，我十分反感小组成员哗啦啦扯一大堆乱七八糟的跟想象作文似的需求分析。但进了公司，做实际项目的时候，需求分析有助于快速定位用户，定位功能，因而十分必要。

1.1 找出典型用户

做软件总不能漫无目的吧？你得搞清楚目标用户是什么人，才能逐步明确软件要做成什么样。设计出几个典型用户，我们就对潜在用户的年龄、工作、习惯、喜好等一系列特征有了一个初步的认识。

而且不同的典型用户可能会有不同的潜在行为。举个例子，以某款动作类游戏来说：玩家A是个画面党，那么游戏最好精美一些，如果人物建模和装备设计得相当好看，即使是付费道具，玩家A也可能心甘情愿地买单；玩家B争强好胜，在很多游戏的排行榜中名列前茅，如果推出数值强劲的角色和装备，那么玩家B为了追求更靠前的名次很大可能会掏钱。但不同的典型用户都要使用你这款产品，证明典型用户也是存在共同点的——玩家都是动作类游戏爱好者。不管怎么说，你这款游戏是动作类游戏，那就要求人物动作要流畅连贯自然，这一核心不能丢失。

1.2 搜集用户需求

但典型用户毕竟还是单方面意淫的产物，在实际生活中，用户所想可能与你有很大出入。

那么如何搜集用户需求呢？比较常用的方法是问卷调查。目前问卷调查的题型以多选题和顺位选择题为主，毕竟没有多少人愿意浪费自己的时间打字来回答开放式问题。但选择题不一定能覆盖所有可能的用户需求，因而调查问卷的设计也十分重要。

怎么让别人乖乖填调查问卷呢？奖励——比如说赠送会员，赠送软件内通用货币。我玩过的一款游戏很鸡贼，每次玩家填写调查问卷后都会得到数量可观的水晶——这个游戏中十分难以获取的货币，而水晶又是能换取强力角色和装备的唯一途径。这样，变强是你的最终目标，获取水晶是你的中间目标，你自然而然就会去填写问卷了。

采集到数据，问题又来了——怎么确保信息的真实性？如果用户只是为了拿到奖励，那他(她)完成问卷花费的时间可能不超过十秒。。。这样不经思考的数据有价值吗？所以也许要借助一些技术手段，判断用户是认真完成还是随手一填。需要注意的是，这一步绝不能放到用户填写问卷的过程之中。如果用户填写完发现拿不到奖励，那十有八九也不会再用你的软件了。

2.设计阶段

2.1 注重用户体验

用户是核心，因而设计要回归到用户角度。用户是些什么人？十有八九是不太懂开发的，他们只想借助软件实现自己的目标，所见即所得，你不能整出个按开发人员思维操作的软件把普通用户看的一愣一愣的，那就直接劝退用户，拱手送人了。所以私认为把用户当傻子的设计理念就很好，软件的界面越清晰，操作越简单，用户的认知阻力就越小，体验也就越棒。

2.2 UI设计

对用户而言，软件好看、好用就行了。而好用是建立在好看的基础上的，开发人员实现了许多炫酷的功能并暗自得意，但用户看到你这乱七八糟绿的发慌的UI恨不得一手机呼你脸上。UI的各个部件之间应有明显区分，但整体在大小、颜色、形状上要和谐统一。这里主要强调一个美观的UI有多么重要，不过多赘述。

2.3 要有特色

应用市场里形形色色的软件那么多，你这款软件release之后要能get并消除用户痛点，用户靠你的产品切实能解决问题，靠别人的不行，这就形成了人无我有的优势。如果大家都有，那就做到最好，这也是优势。

拿小米来说，早期发家靠的是什么？旗舰机的配置却只要旗舰机一半的价格，搭载了相同的旗舰soc，小米几乎总是售价最低的那个。再后来，小米有了自己的生态，米家推出的各种智能家居物美价廉。极致性价比，完善的生态。这就是小米的优势。

3.开发阶段

3.1 代码规范

类似于写作文时每段首行要缩进两格，敲代码前也要规定好格式规范，所有开发人员都要按照这个规范来编码。机器不用管代码格式，只要语法逻辑无误就可以运行，但程序员是人，过于难看的排版会让人逐渐失去耐心。谁都不想对着一堆i，j，a，b猜测变量和方法的含义，这就对程序员的英语水平提出了要求。写字好看能给人留下好的印象，好的命名习惯亦是如此。

每个人思考问题的方式不同，代码写得再清楚，有时也容易产生错误理解。所以，为了有助于他人理解，注释是一定要写的。这样后期维护时也会节约不少时间，没有人能清楚地记得几个月前敲了些什么。注释具有时效性，一定要随着项目更新而更新，一个错误的注释比没有注释更具误导性。

3.2 确定合作规模

       虽然不是每个公司都有比较完备的团队，但整个公司只有一个开发人员的情况应该并不多见。如果和同事关系还不错，可以试试两人合作的开发模式：一人敲代码，一人在旁检查错误，如此轮替。这样思路出现问题时可以及时得到纠正(两人都具备一定实力的情况下)，不会出现完成一个模块后才发现问题又要大规模修改的情况，减少了修改和重构的时间。但结对编程也容易加深矛盾，如果一个人巴拉巴拉说个不停，那正在编码的同事绝对想一键盘呼过去。。。因此，交流频率和交流时长都要适当控制。在予以他人反馈时，应尽量对他人的行为和后果作出客观评价，避免对他人的本质和固有属性进行攻击。

3.3 选择合适的技术

国内一直有这样的误区，觉得最新的技术就是最好的。其实不同的技术各有所长，适用于不同的领域。python是近几年的产物吗？并不是，只是时代发展到恰好需要它而已。很多时候，已经发布几年的成熟技术才是更好的选择。结合自己的经验，选择合适的技术才是王道。

3.4 应对需求的变动和增加

       需求是千变万化的，可能今天是根据用户心情改变手机壳颜色，明天就是根据用户发色改变壁纸。做好需求文档再开发显然已经不适应瞬息万变的时代。因此，即刻开始->每日开会讨论变动情况->根据变动修改代码的“敏捷”开发模式成为了主流。编码人员要预留位置来应对可能的需求变动和增加，同时保证项目处在一个随时可交付的状态。随时变动，随时交付，更强调适应性而非预见性，这是“敏捷开发”的优势所在。

3.5 注重效率

上面提到的这些，提高代码可读性也好，敏捷开发应对变动也好，都是为了能够第一时间将项目交付给客户。如果每天的开会流于形式，这对加快进度起不到任何作用。同理，如果一个公司的绩效根据代码行数来评定，那趁早离开比较好。每一行代码都要尽可能高效地完成它的任务。只要你愿意，一行代码可以拆成五行来写，但这真的有意义吗？

4.测试阶段

4.1 找Bug

       “千里之堤毁于蚁穴”，就算是测试中无法复现的bug和影响较小的bug，私认为仍有必要尽早解决。上面已经提到，在解决bug的同时要注意更新注释。有些人喜欢给发现的bug打上标记，然后继续其他工作，但时间一长，谁还能记得这个bug是待解决还是已解决？不如发现一个，消灭一个，这也是效率的体现之一。

       程序员所写的代码应尽量交给他人复审和测试，在你敲打键盘时，你已经默认自己的思路没有问题，所以，找自己的bug是最为困难的，但是分析他人代码时，我们往往会更加客观一些。

4.2 用户测试最为真实

       有条件的话，程序一定要有Beta版(公测版)。带入用户的角色进行操作，很多人开发或测试做久了，这一能力会渐渐丧失。这也体现出一个好的测试人员是多么难得：工作需要时，能把自己突然变成一个完全不懂技术的人。既然产品最终服务于用户，那么用户所做的测试才最为真实。

---

       在《构建之法》里，处处体现着匠心。软件开发是一项工程，更是一项艺术。在技术足够的情况下，付之以匠心，辅之以方法论，把产品当作艺术品去完成，个人能力将得到极大的提升。