文/潘加宇

现在很多开发人员还没有学会市场思维，仍像是象牙塔里的学生那样，保持着学生思维。事实上，软件工程更接近于经济学，而非计算机科学，需要开发人员具备市场思维。

世上无易事

要是我问你，跑百米容易还是跑马拉松容易？这还用问！当然是跑百米容易了，是吧？其实我想问的是：亚洲运动员要拿奥运冠军，是跑百米容易还是跑马拉松容易？答案似乎就颠倒过来了。近邻韩国和日本都已经出过奥运马拉松冠军，比起拿百米冠军，概率要大多了。 有了上面这个问题垫底，你应该可以猜到下面这个问题的意图：现在开发软件容易还是二十年前开发软件容易？现在的软件开发是可视化编程，就着框架搭积木，看起来容易多了。可惜，当我们的问题变成：通过开发软件来赚钱，比起二十年前是不是变得更容易了？答案也颠倒过来了。门槛的降低使得竞争者大量涌入，拉低了软件公司的利润和程序员的入职薪水，更要命的是，客户的胃口变得越来越大。二十年前，史玉柱在《计算机世界》登一个广告“M6401，历史性的突破”，然后就可以等到订单，这样的成功现在还能复制吗？ 当我们从市场竞争的视角去看问题的时候，容易的事情就变得不容易了。不过，很多开发人员还没有学会市场思维，还是保持着学校里的学生思维 ...

Continue reading

      本周虽然只工作三天，但却是超级忙碌的三天。开会、讨论文档耗尽了我的时间和精力。回想起来，印象最深的就只能说工作上的事儿了。

      和小戚阿飞一块整理业务架构是很愉快的事情，看着一大陀业务逻辑经过整理、讨论、再修改，慢慢形成条理清晰的业务对象搭建的架构，也小有一些成就感。
      最大的感触就是发现使用UML进行业务架构分析是很舒服的一件事情：
      首先用部署图描述了以后运营系统的逻辑划分和物理上的性能扩展性；
      然后用用例图描述了系统功能上现有的和要实现各个功能的关系，include和extend用在构建系统功能关系上，可以让OO的程序员们有共同的语言。画完之后，至少从宏观上看，系统下一步的演进意义所在，已经很清晰了；
      接下来关键Case里面就可以出活动图了，这种能够替代流程图的描述方法，每一个应用程序员其实都应该掌握的；
      宏观的告一段落后，下一步的对象模型已经是细致活。类图可以把我们需要的关键对象都描述出来；
      再后来，我们发现为了实现某些需要C/S共同配合的逻辑时，序列图也必须加进来
      希望下周能把所有悬而未决的业务逻辑都确定下来，这样业务架构才真的算功德圆满。

      连着两个上午的用户模型讨论，搞清楚了两件事：
        1. 在现有业务处理单元UID之上，引入新的账号单元是无法避免的；
        2. 已知的帐户、服务关系、订购关系等等，都要在原有处理逻辑的基础上，考虑对账号的处理；
      开始真的让人觉得很难接受，可以遇见的系统实现开销将会成多倍增长。但后来从大家抛出来的Story上看，UID也真的不适应了。真是变化快啊！

      用户模型是很让人惆怅的事情 ...

Continue reading

KPI（Key Performance Indication）即关键业绩指标。对本部门的指标量化和考评，我们将做如下尝试。

1. 分岗位制订考评系数（总分系数）
架构师、组长、DBA（1.2）、开发人员（1.0）
对组长和核心开发人员（架构师、DBA）倾斜，提高他们的系数，鼓励他们的工作

2. 任务完成率（基础分）
部门内部，项目和短期任务统一考评。
本季度内投入的工时数，单位为人天。
举例：假设某季度正常工作日62天，某人全勤，且加班12小时，则他的基础分62+12/8=63.5
这个本意是考察程序员的产出，因为目前无法量化每个人的具体工作量，只能按照工时来统计了。

3. 质量保证指标（扣分指标）：
1）每次svn提交，开发人员必须填写提交信息： 提交目的 ...

Continue reading

落实

 

 

审查者

 

研发组长对本组提交的代码质量进行检查

 

检查关键点

 

1. 检查代码符合编码规范；  
2. 是否有足够清晰的注释；
3. 检查数据库、文件等资源完全关闭。(测试层面解决：rnd减少连接池数量；本机性能测试；)
4. 代码检查不必花很长时间的，编码和评审大致5：1的时间。

 

检查时机

 

• 项目或短期任务上线前，由开发人员主动发起，请组长检查。
• 架构组目前由我检查。

 

参考

 

• 敏捷开发中和保证代码质量有关的实践有很多，我觉得在项目经理或研发经理、组长们可以学习一下，挑一些在自己负责的开发工作中做一下实践。
• 咱们推行的代码质量审核，是要求编码者的上级来审核代码，这和敏捷开发中的结对编码，一个人写完的代码，要讲给另外一个人，请他来看。目标是一样的，但执行上结对编程更能激发团队成员的积极性。

 

结对开发

 

• Pair programming is a software development technique in which two programmers work together at one keyboard. One ...

Continue reading

- 文档编写注意事项
1. 统一使用标准实体
例如ClientInfo/UserInfo/MobileInfo等，分别代表客户端（软件）信息/用户信息/手机（硬件信息）等

2. 协议文档中增加实现具体功能的协议交互序列图
通过序列图，能够清晰描述本协议使用场景和交互过程

3. 协议文档演进注意事项：
基线控制，注意文档的版本和修订日志

- Server端的模拟程序开发计划
1. 报文级的单元测试
实现简单的单次报文请求/回复
2. 基于单元测试的功能模拟测试程序
辅助程序的开发依赖于交互流程的明确
模拟多次交互的功能应用

Continue reading

1. 开发中单元测试要跟上
目前程序开发，很多代码在开发期间并没有充分跑通。系统测试期间暴露出很多应该在开发期间就发现的问题，造成测试期长。

2.充分而详细的设计是编码质量的保障
目前需求过来之后，往往都是直接编码，没有详细设计。
开发一般采取打补丁的方法，直接在原有程序上修修补补。这样在短时期上看，效率不错，但长期来看，代码结构化不好，功能含糊不清，不利于以后的开发。

3.设计、开发和辅助测试流水线开发
部门里面对现有业务逻辑掌握比较全面的，并且有设计能力的只有那么几个，但他们往往要跟随整个项目或任务的开发期，很多时间都花在编码和测试上了。这其实是个浪费。
应该尽量保证有设计能力的开发人员的主要精力都在设计上。编码和测试可以交给经验不太丰富的程序员来完成。

4.适当加强工作检查，促进开发人员提供工作效率
有一个建议：开发人员写工作日报，包括当天工作列表和实际完成情况。
每天早晚抽查。早上应该写清当天的工作列表，晚上应该写清工作完成情况。

5.适当的激励机制，奖励勤勉员工

Continue reading