前面几篇，我们一直在讨论怎么做好系统的架构设计。架构设计很重要，但是如果代码编写的不好，那再好的设计也是白费。今天，我们来聊聊编码过程中，需要注意哪些问题。
我觉得代码编写过程中，有两个方面需要额外的注意，一个是代码的健壮性，一个是代码的可维护性。
健壮性
先说一下健壮性，简单讲就是代码在边界条件下的表现如何。大部分人写代码，一般只会考虑正常的逻辑情况。但是，一个优秀的工程师，主要是看他对边界条件的理解。
什么是代码的边界？我们可以把计算机系统抽象为针对用户的输入，经过逻辑处理，给出相应的反馈。那我们就可以在输入、逻辑处理、反馈三个阶段来考虑边界。
在用户输入阶段有哪些属于边界，我们可以去思考。比如用户的输入有没有特殊的字符或者极限值。再比如极端情况下，有多少人同时在请求系统等等。
在逻辑处理阶段呢，比如极限情况下有多少数据量需要处理，以及运算所需的时间和空间成本如何，异常的数据怎么处理，当硬件资源出现问题的时候又需要怎么处理等等。
在给出反馈阶段呢，比如特殊情况下如何反馈给用户，极端情况下的数据能否展示出来等等。
大家可以看到，这三个阶段都可以认真的去考虑。你把边界条件考虑的越详细，代码的健壮性就越高。无论出现什么状况，系统就越稳定。
举个实际代码编写的例子，当我们写一个函数的时候，有输入参数，也有输出参数。如果不对输入参数进行必要的校验和判断，就直接使用，这样的代码在边界情况下就很容易出问题。
再比如，在编写业务逻辑的过程中，我们采用了一种数据结构和算法。这时候，我们就需要考虑这种数据结构和算法在大数据量、大并发的情况下表现如何，时间和空间成本分别是什么样的等等。
如果不提前考虑这些问题，在真正实际应用的过程中就会碰到各种意想不到的状况。
可维护性
业务在不停的变化，相应的支撑系统就要不停的更新和维护。代码的可维护性决定了一个系统生命周期的长短。那怎么做好可维护性呢？
我觉得首先要解决一个思维模式的问题，写代码并不是完成任务就可以，本质是在交付一个产品。就是要拿产品交付的心态去写代码。
什么是产品交付心态，就是首先考虑真实用户的感受。也就是说在写代码的时候，就要考虑其他人需要理解我的代码，需要修改或者扩展我的代码，他的感受是什么样的，我如何让他更方便。
有了这个心态，其他的事情就顺理成章了。要不要写注释，那就看一下当前这段代码好不好理解了，如果不好理解，那就必须要写注释。要不要为变量起一个好的名字等等，你会发现当你换一个心态在做的时候，这些抉择就变得很自然。
其次就是要有一个基本的评判标准，到底什么样的代码就算是易于维护了。我觉得越简单的事情越容易被人理解，也就越容易被维护。
我们一定要尽可能的保持逻辑的简洁性。比如一个方法就只能完成一件事情，代码行数不能过多。一个类就只能承担一个对象的职责，不要试图让他做无关的事情。简洁算是基础的一种评判标准。
代码品味
无论是代码的健壮性还是可维护性，都很难有唯一、可量化的标准，很难简单的去管理或者检查。他更多的是一种编码的习惯，对每个人来说都不是一蹴而就的。都需要我们对自己有很高的要求，经过长期的刻意练习，才能达到。
怎么能持续的坚持下来，养成一个好的代码习惯呢？我觉得首先我们自己得重视这个事情，整个团队氛围也要重视这个事情。甚至在团队中养成一种代码的品味，每个人都养成这样的品味，这样才能持续的把这个事情做好。
总结一下，好的代码要有健壮性和可维护性，尽可能的考虑代码的边界情况，让代码的组织足够简洁，持续的产品交付，最终形成我们自己的代码品味。
