2019-03-02
关于错误。我们曾经犯过不少错误。编程相关的决策错误大抵是不会导致软件项目失败的，特别是在当前这种互联 公司持续运营项目的模式下，多数程序在服务端服务端运行。软件开发团队会持续的迭代项目。每次交付的内容也是阶段性成果，对外交付的是服务。不像二三十年前，软件交付并分发出去之后，迭代改进只能等到下个版本了。所以，对于我们软件开发者的压力也小了些。但是，对于需要对外交付的软件，则需要格外小心。
关于UI lib的选择，不要选择MFC或者C#的WinForm或者WPF，或者其他小众的UI lib。最好需要Qt。因为，偏工业软件并不需要在UI 显示效果上有很高的要求，即使是Maya，2011年之后也是采用Qt技术实现UI的。用户最在意的是软件的核心功能，炫酷的样式或者交互只是锦上添花。
对于，模块之间接口暴露程度。越是偏上层，越没有必要隐藏模块内的数据结构。需要隐藏的东西最好设置protected或者impl 实现。对外提供指针，而非id或者某种handle。之前吃过这个亏，非常大的亏。我从最开始时便反对这种方案，奈何没有作用，用handle代替指针给后续两年的开发过程带来非常多的bug。所谓的解耦，并不是把自己的模块隐藏起来，解耦的目的也不是为了将来有一天重新实现某模块，并替换掉老的模块。这不现实。解耦，是为了在后续开发过程中，发现某模块内设计不合理，能以很小的代价进行修改，对其他模块的影响也能尽量的少。
对于，C++版本以及 std、boost是否选用问题。我觉得，对于新创项目，还是尽量选择新版本C++以及 std、boost，它们的质量比我写的代码质量好太多了。须知，编译器也是有bug的。之前项目中，我帮助发现了一个由vc12 foreach 语法糖导致的bug。而且，对于这种偏上层代码，我们不需要担心其他开发团队依赖于本项目的问题。lib带来的依赖冲突问题基本上不需要考虑。
对于，脚本嵌入，最好选用Python。Lua真的不适合CAD/CAM项目。虽然Lua语言本身小巧，容易操纵，但Lua语言本身的表达能力偏弱，使用者较少，第三方lib的广泛性以及成熟程度都不及Python。我们在之前的项目就犯过这个错误。
对于第三方lib的选择，非核心算法模块，或者将来自己的程序肯定会修改实现方式的功能，如果有第三方lib，就尽量使用。最大的原因在于自己写的代码，非常有可能在质量上比不过经过锤炼的第三方lib。所谓的学习成本，还是很低的。并且，一个人的学习，可以形成文档，第二个人完善文档，之后其他人的学习成本就会低很多。
对于各种方便的、取巧的方法，如使用全局变量，需要保持警惕。须知，Nothing comes for free。使用起来简单，但是，用多了，就会导致忽略模型正确的class 层次关系，对重构模块或者项目带来很大的难题。不要为了避免重复构造关键对象而使用单例模式（基本上单例与全局变量总是一起出现）。不要过分担心软件设计里面的问题，还没有遇到耦合问题，就考虑对各模块解耦；还没有遇到性能问题，就考虑优化而对模型层次关系做出修改 ，这些做法都矫枉过正了。
关于自动化测试，CAD/CAM软件一般难以进行自动化测试，因为对于二三维窗口的业务操作，很难录制脚本。而且，由于操作交互变化较多，即使实现了脚本录制的方案，录制的脚本有效期也不会持久。这都导致自动化测试工作难以开展。我们可以利用内置的脚本语言，对于主流程做简单的测试，避免录制交互操作，而是使用脚本替代完成，让脚本直接调用内部接口。这便要求各个模块尽可能多的暴露接口给脚本模块。
在详细设计阶段，一定要做好UML图。并且需要专人负责持续修改。让团队成员对于项目的整体架构保持熟悉。强调一点，《道德经》有言”无名天地之始，有名万物之母“。对于命名，拥有决策权的各组长一定要控制好。尽量避免缩写，避免***Manager这样的模糊不清的表述，避免歧义。
P.S. 2018四月份开始写的东西，到现在才写完，真费劲。可能行文很杂乱吧，本来也不是一次成文，从笔记里面提炼出来的总结而已。
如果有任何意见，欢迎留言讨论。
[ 主页 ]
COMMENTS
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！