程序设计是否应注重代码简洁性，而非单纯追求功能实现？

本文共计3123个文字，预计阅读时间需要13分钟。

一个人自娱自乐地写个小程序，然后和一帮人一起写个大项目。真的不一样。自己一个人，基本上不存在交流，互相理解的难题。人越多，越能理解别人的意图，越能花时间解释意图。

一个人自娱自乐的写个小程序，跟一帮人一起写个大程序。真的是不一样。

自己一个人，根本就不存在交流，相互理解的问题。人越多，理解他人意图，向他人解释意图就越来越花时间。只要是需要交流的任务，并非是人越多越好。有人加入，为了使加入的人有事做，原来的事就要重新划分，而分开之后要配合,又要花时间交流。发觉很多重要的软件开始都是几个人做出来的。而漫画中，进行任务也采用小组模式，好像<幽游>,<猎人>都是四人小组。

这里，最基本的问题就是任务的划分，最理想的划分是相互独立。而要做到这种独立，正交的划分，是很困难的，更困难的是你会发现那最初的任务会随着时间变动。传统的软件工程会说，首先是定义需求，跟着大体设计，详细设计，编码，单元测试，整体测试等等。但真正实施起来，发觉没有那样理想，很多项目都不是重新编写，而是在原有的代码上加强，很可能原来的根本就是沙地，很是流沙，而却要在上面起高楼。假如一个项目规定是半年完成，花上一个月去定义需求和设计，跟着去编码了，就会发现很多事情是想不到的，有些看来很简单的事一卡就卡上一个月，毫无进展。发觉这本来是很简单的问题牵涉到项目的结构，而之前结构很难修改，又或者不舍得去修改，为解决这问题，就使出一些歪招，看起来好像很巧妙，却打乱了原来的结构，跟着这些古古怪怪，想不到的问题一个个冒出，原来的设计渐渐偏离，又没有去修改文档。时间越来越紧，项目拖后，公司上层发觉不对路了，就加人，新人来，拿起最初的设计文档看，发觉根本对不上。旧人就又花时间会帮他理解项目。到原定的发布限期，程序却一运行就死机，最终结果迟上两三个月发布，发布之后很多bug,再花两三个月改错，发个补丁包。