技术笔记一月二十二日

2009年,入行也有一些时间了,水平有限,没法写出什么有深度的文字,只能想起什么就写点,也许到了零九年年末,能积累一些东西出来。今天写的都是一些务虚的笔记。

1,编程能力无所谓天才白痴之分,只有用不用心的区别。

2,一个好的团队能让人发挥百分之二百的能力,而一个不和谐的部分能让木桶里的水都漏光。对于一个中型或者大型的项目来说,核心的成员应该是非常团结的。

3,基本上现阶段所有的软件工程开发理论都没什么用,都是学院派搞出来骗人的。ISO9000,CMMI,六西格玛,莫不如此。而且,所有的软件工程辅助工具,都还处于非常初级的阶段。

4,所有的技术革新或者是技术推动,应该是从上至下的,这一点,在企业里搞过管理信息系统的都知道。

5,技术交流或者是技术分享,重点并不在于交流的成本有多高,而是在于人们是否有意愿去分享,或者说企业文化是否鼓励分享精神。

6,开源或者免费软件的使用,是一个双刃剑,开源会减少表面上的成本,但是相应的学习成本以及部署成本也比较高。

7,微软平台,已经不是开发的主流平台,java和web,是现阶段比较流行或者说占据了大部分市场(企业市场、个人消费市场),微软的强项,只剩下windows操作系统和office,而这两方面,都在被人不断的蚕食,微软的日子将会越来越难过。一提到微软基本上就是官司或者是被人嘲讽,这一点很致命。

8,个人预测,苹果借助它的iphone,将会继续占据IT时尚前沿阵地,引领这两三年智能手机市场。手机开发将会是web开发之后的又一个流行趋势。随着国内3G市场的开放以及手机上网网速的提高,这些大网站都会推出手机专门浏览的入口,或者针对手机进行定制。手机软件会变得流行起来。而且,手机的在线特性,使得手机软件盗版变得困难,这一点可以从网络游戏得到证明。

理想中的软件开发模式,应该是这样的:

需求简洁清晰,问题明确,客户要求的变动在预期范围内。

前期开发基础架构,不过多考虑扩展性,但是留出扩展的余地,高内聚低耦合,在早期允许冗余代码的存在,但也要注意代码味道,如果发现坏味或者是超过两次的代码重复,或者是超大的函数,就要开始重构或者重写。

前期开发,测试人员就要进入,同时构建单元测试用例,而编程人员每完成一个特定的逻辑功能块,也要写相应的unittest,如果测试发现问题,也要先写unittest,然后进行修改。

在前期就要确定整个系统的debug log体系以及错误处理方式(异常、返回值、message等等),并且伴随相应的一套unittest程序,对于非通用性软件来说,unittest程序基本上需要自己定制,而且需要定期维护,这个成本看起来比较高,可收益也是很大的,在我最近参与的项目中,unittest的使用保证了大部分功能的正确性。谈到这里还要跑题说一下,以前经常碰到有人说“这个地方不能改,非常关键,改了没法确定是不是对的”,主要就是因为缺少unittest的保证,关于unittest以后还要写写自己的一些心得体会,比如什么时候必须用,什么时候可以不用。

当程序大的框架搭起来以后,或者经过一段时间的试用,客户需求会变得比较复杂,这时候要注意不断的调整代码结构,删掉或者重写坏味的代码,重构有问题的、或者比较复杂的函数,另外,定期维护unittest以及定期进行组内的code review都是必要的。

对于大中型项目来说,客户要求需要进行项目管理,基本上就是建立defect管理系统,进行需求的优先级排列,如果是小公司,Python的Trac是一个很好的选择,可以集成svn这套版本管理软件,另外内置了bug列表和wiki功能。

如何使用c++,以及windows的新技术,是一个需要权衡的问题,我个人的原则是,技术上尽量使用的简洁,比较常用就是vector以及string这两个stl模板类,也不使用什么炫目的模板编程技巧,也不过多的进行封装或者抽象,尽量少用COM或者是高级的windows技巧,选择通用的技术而非微软专用的技术。使用c的编程理念,加上c++的基本语义支持,足够了,至于什么偏特化、c++模板技术、dcom、连接点,都是非必要的。

项目进入后期,需要考虑自动编译以及自动单元测试的实现,在这一点上,java要比c++容易得多,c++程序员或者说微软平台程序员,基本上不会去考虑类似的实现。另外,微软平台程序员缺少的技能是脚本编写能力以及正则表达式使用能力,在这一点我也有缺陷。

c、python、web开发、iphone开发,是我在2009年比较感兴趣的技术,另外,有空学学外语也很必要,感觉自己这两年有些吃老本,是该充充电了。

《技术笔记一月二十二日》有2个想法

发表评论