上位机开发常见问题思考

1.日常思考

1. 使用配置软件还是硬编码在程序中？最近在开发一款兼容多款设备的上位机软件，开始用了很多配置文件，包括所有业务对象的生成、对象的配置参数等，重度依赖于配置文件，每次功能更新都要同步更新使用的配置文件，而且配置复杂，很容易出问题。现在准备将大部分配置写在代码中，将IP地址、测量参数等需要个性化配置的参数放在配置文件，这样大大减少了配置软件的难度。实现业务载体从配置文件到代码的转变。
2. 配置文件全部由代码生成比较麻烦，而且json的自由度比较高，全部由C++生成也感觉不太优雅，考虑将配置文件放入Qt 资源文件中，从资源中读取json文件，再读取ini配置文件，将json文件装配成可供设备初始化的完整对象，这个方案比较优雅。
   
3. 关于数据传输，最近在开发过程中遇到了一个问题，软件通过tcp接受大量光谱仪的光谱数据，在转为json通过zmq发布后，会经常遇到光谱数据接收不到的问题，后来查看了带宽占有率快达到了80%，于是把json数据通过zlib压缩后发布，数据体积降低了80%，带宽占用率降到了20%多，光谱仪数据接收也正常了。Get！
4. 程序开发要有明确目标，程序员有很高的成就动机，他们会努力达成指定的目标，但必须告诉他们目标是什么。而且目标之间会发生冲突的，通常不可能在所有本目标上做得很好。
5. 在需求输入阶段就做好质量保证，成本很低，错误越早发现修复的成本越低。
6. 多线程问题： 正常思路先用单线程运行业务，在出现性能瓶颈时才选择使用多线程，这样可以让你更容易发现出问题的点。很多程序在单线程下运行的好好的，多线程经常出现卡死、闪退现象。避免这种问题主要就是，能单线程就单线程。在对业务进行仔细分析的情况下，小心、审慎地使用多线程，稳定比性能更加重要。

2.写代码

1. 软件命名风格，作为一个写过C#、C++、python三种语言的程序员而言，三种代码的命名风格差异也让我头疼不已。中间尝试过将C#和C++使用一种融合风格，python使用python的命名风格，使用过程中发现，每次调用标准库代码时，都和自己写的代码不太一样，感觉甚是别扭，更不用说python这种动态语言了。折磨了一段时间后，发现将不同的代码风格融合确实容易写出不三不四的代码，还是决定遵循每个语言的命名规范来写，简单粗暴，日后别人读起来也更轻松！
2. 很多程序都有包含计算值的变量，比如total、average、maximum等，建议把这个限定符放在名称的最后。主要原因是变量名称中最重要的部分，即为变量赋予主要含义部分，放在最前面方便阅读，其次是建立这个规范，防止后续的命名混淆，再其次就是对称性（这个我不太认同）。（摘自《代码大全》）
3. 有些程序员很抵制标准和规范，一些僵化和低效的标准规范，会破坏他们的创造性和程序质量。这真的让人觉得遗憾，因为有效的标准是我们所能掌握的最强大的工具，没有之一。（摘自《代码大全》）
4. 每个项目都要有命名规范和缩写规范，在遇到新的命名规范时要及时更新文档
5. “深入语言去编程”而非“用语言来编程”
6. 不要将所有全局数据都放在一起，请花时间思考一下每个全局变量属于哪个类，然后将该数据机器访问器子程序与该类中的其他数据和子程序打包到一起。（摘自《代码大全》）
7. 头文件不应保安using声明：这是因为头文件的内容会拷贝到所有引用它的文件中去。对于某些程序员来说，由于不经意间包含了一些名字，反而可能产生始料未及的名字冲突。

3.C#命名规范

1. get、set命名规范

//单纯的默认属性,get;set;分行写
public int StartAddress 
{ 
    get; 
    set;
}