软件开发里，代码的精炼程度、设计资料的详尽程度以及工作分配方式等议题经常引发讨论。有人主张代码应当便于理解，设计资料需要完备，但这真的符合实际吗？咱们来仔细研究一下。
代码简洁至上
编写代码时，务求简明扼要，这得益于优秀的设计思路和规范的编写方法。代码本身应当具备自说明的能力，这一点从一些知名网络企业的程序员身上就能看得很清楚，他们用精炼的代码帮助新加入的同事迅速熟悉工作。当然，注释也并非无用，它能够对代码的内在逻辑进行必要的补充，使那些复杂难懂的部分变得容易理解，但注释终究无法取代代码自身的解释作用。
/**
* 图表模型
*/
class Chart{
/**
* 图表长度
*/
private int length;
/**
* 获取图表长度
* @return 图表长度
*/
public int getLength(){
return this.length;
}
/**
* 设置图表长度
* @param length 图表长度
*/
public void setLength(int length){
this.length = length;
}
}
设计文档之辩
class Chart{
private int length;
public int getLength(){
return this.length;
}
public void setLength(int length){
this.length = length;
}
}
有人认为设计说明应该足够周全，能够直接用于编写代码，不过如果过于周全，就容易流于形式。比如某些项目，投入很多精力撰写详尽资料，结果编码过程问题频出。实际上，设计方法多种多样，技术娴熟的程序员在编写代码时同步构思，依靠简单的图示同样能开发出高质量的软件，编写说明并非表达设计的唯一途径。
设计与编码融合
设计理念始终贯穿于整个编码环节，一个人负责设计、另一个人负责实现的最佳状态很难实现。比如和同事探讨测试驱动开发，擅长设计的人即使不采用这种开发方式，也能编写出高质量的代码。对于承接日本外包业务的公司，程序员如果拿到具体到方法层面的文档，这会扼杀员工独立思考的空间，在中国，有能力的程序员最好避免参与这类外包项目。
文档传承局限
有人觉得设计资料能够流传业务和技术经验，不过完备资料从开始写到保持现状都要花费不少力气，很难流传下去。有些项目，详细资料刚做好没多长时间就已经过时，再更新又得投入很多人力，知识无法顺利传递。
评审人员定位
评审设计文档时，程序人员注重方案和执行方法，不编写代码的测试人员参与会消耗时间、引发分歧。多数接触到的测试人员很少查看代码，关于代码层面的讨论他们本不该介入，否则会让评审过程失去核心。
跨产品挑刺难题
让熟练的开发者去审查其他项目的源码，往往发现不了真正有价值的缺陷。他们不清楚实际应用情况，必须投入许多时间研读程序、掌握背景信息，最终只能关注细枝末节。现在有些软件工具，原本是设计来辅助程序员的，结果却变成了针对程序员的工具。
关于软件开发里那些情况，你有没有别的想法？可以点个赞，发出去，并且留言交流。