好帖！这些原则都很重要，但有一点要注意，所有的原则都是死的，绝大多数规则都存在某种特定的环境和需求下是无效的
另外我觉得文档的工作量可能不止10%，而且不应该放在最后，它应该在项目需求确定时就有了框架，随着项目的推进逐步细化，最起码跟代码框架这部是同步进行的，也就是说程序写完时，你已经有了完整项目文档
程序的结构化、系统化、易移植性……不仅仅是为了阅读方便，还关系到代码可重用性。将设备拆分成不同的块很好，这符合软件工程里面自顶向下思想。我也喜欢这样，厂里有十几种不同型号的设备，看起来各不相同，但拆分成模块后它们都是一样的，只是不同设备需要的模块有所不同而已。如果分开来写，程序大小从2K到12K不等，最后采取的办法是用了10K左右来写模块，在一个程序里面写一样配置单元，通过触摸屏来配置不同的单元，每个单元可细化配置，比如PID是远程还是本地，全控还是微调，通过模拟量还是通讯给定，速度采集选择同不的算法等，人机界面的呈现方式也根据选择的机型变化。最后再根据现有的机型做一个配置向导，选择一下机型就自动配置相关参数，对现在机型的配置完全傻瓜化，对新机型则可以手工配置每一个参数，程序可以直接或改动很少就能适应新机型。最后这个程序的大小到了15K，虽然比最大的一个程序还大了3K，但以后只需要维护一套程序，如果发现BUG不用每套程序都修改，对以后的维护、持续开发减轻的极大的工作量