半个月前在哈尔滨面试本地一家企业的时候，第三轮面试一个技术总监问我“你觉得什么样的程序是好程序？”，是啊，怎样算好。其实如果能知道什么样的程序不好，自然就知道什么样的程序好。
我回答说，1容易测试的程序是好程序。
如果一个程序在交给测试人员之前就能进行自动的或半自动的，单元或功能的测试，程序的框架支持这种测试，那么这就是好程序。
后来我知道，这点有点类似TDD，即测试驱动开发。这个术语翻译的不太好，在汽车电子或嵌入式领域，驱动指的是一种程序，而在这里是做动词用，我理解为让测试去驱动开发。
2.适应性强的程序是好程序。
需求总会变，开发人员常抱怨需求的变化，这恰恰暴露一个问题，他们的程序适应不了这种需求。
需求又可以分为大需求和小需求，大需求类似系统性变化，往往颠覆框架。就拿我过去做全液晶仪表为例，第一年没用图形引擎，用的是纯OpenGL手写，第二年用的是Kanzi，以后可能用QT。而对于操作系统，可能是linux，也可能换成QNX或者其他，对于硬件，可能是NXP的也可能是高通的。在上述变化下如何保证框架不变？那你首先需要一个好的框架，这个框架或设计本身就允许这种变化！
小需求类似业务功能的改变，还是拿仪表举例，这个界面起初需要以透明动画方式出现，后来觉得还是以移动动画出现好，将来还可能换成别的动画，你的程序应该能很容易的适应这种变化！
3.适合多人开发的程序是好程序。
如何进行多人开发，GitHub和svn只是代码版本的管理工具，仅有这些远远不够，重要的还是框架，简单的说让框架和业务分离，框架是树枝，业务是树叶。让开发者职责分离，或分层，分为系统开发和业务开发，二者互不影响。
4.高度工程化
如果做到了上述几点，一个团队的开发效率会大幅提升，这也许该叫做软件工程，工程的东西一般都专业化，流程化，系统化，精准化，可复制，低成本，高效。这样就如同一个流水线，分工明确，高度专业。其应该叫做代码工厂。
实际上，如果做到了TDD,6大设计原则，23种设计模式中的几种，cmmi流程，那么这大体就是好程序，看来这里理论的东西还真有用。
和他聊了1小时，这家企业当年也是我曾经很向往的企业，因此产生换工作想法后，在哈尔滨也是圈里人都知道的好公司，人称小华为。我也想珍惜每一次沟通的机会，因为相见就是缘分。
没想到的是在这即将离别的时候最终也收到了这家公司入职的邀请，如果我同意，就会发offer了。薪资在本地很有竞争力，估计也算第一梯队了，我们在哈尔滨有代步车，父母有房，我和媳妇都有工作，这样的生活应该很滋润，到了北京，得租房，媳妇得重新找工作，还不一定能找到很理想的。我问家里人去不去，媳妇说，是很安逸，但是不想耽误我的理想!
理想?没想到媳妇会这么说。我都不知道我的理想了，自从当年从广东回来，就深知哈尔滨的软件工作不好找，五险一金+双休的工作都是少数，找到了工作也不一定能施展你的才能，我也渐渐和同事一样，没事看看上证指数，今天哪个同事换车了，明天哪个领导升值了。
但是每到周末和节日，我媳妇往往放很少的假，所以我利用这个时间研究代码，现在想来，只要你不断努力，总会有收获。
有时忽然看到老东家TCL集团的李东升说要打造500强企业，心中还有些失落，如果当年我能一直留在那，现在会是怎样，如今10年过去了，除了一些颠沛流离和坎坷外没有太多收获，也浪费了很多机会，这就是命吧。
还是去北京！
言归正传，知道了什么是好程序，自然也能分清什么程序不好，很显然北京这家公司我即将面对的程序就不好。
它是用c++写的，但是基本就是c，c和c++很像，但很不一样，是思想不一样而不是语法，如果用c++的语法而不是思想来写程序，那还是c程序。
全局变量满天飞，业务逻辑混乱，各模块高度耦合，无法分离进行单元或功能测试，无法保证多人开发协同性（虽然用了git），最最重要一点，无法仿真。
我们组坐的是AVM，有个目标板子，他们现在还不具备跨平台仿真能力，所以，开发效率非常慢。
这是一个烂摊子。
也是一个好机会，把烂摊子收拾成好摊子，就能体现你的价值，哈哈，给我一段时间，我能使这个组的效率提高10倍，但前提是得按我说的做。就像在哈尔滨一样，我的效率是同事的5倍一样，这个我在简历里也有写，但是哈尔滨国企的官僚作风并不推广你的技术和方法。我想北京至少能强些吧。
于是我给自己定了一个一年目标。
1.编写高质量c++代码。
2.掌握AVM算法并优化。
3.向跨平台移植。
