颠覆软件

职业规划，这可是一个时髦的词啊

想说说这个话题的来源是因为csdn的一位朋友给我的邮件邀请，问我是否愿意做他们的讲师，我感到奇怪的是他们怎么知道我有这样的想法，对我了解也未免太充分了，呵呵。

回到IT的从业之路上来，我个人以后的大致想法是通过大量的实战项目的实施，从一线不断的总结经验和教训，以及我对整个项目管理过程的感想，未来可以做技术类的咨询或者讲师，或者独立软件开发也说不定。其实讲师确实是我比较感兴趣的一门职业，因为我确实有这样的能力，即我知道的一定也能让别人明白，这个能力似乎不是每个人都有,另外，我的表达方式比较夸张，往往给人容易留下很难忘的印象。我的表达方式就是“一针见血”，每次都要把问题中的“血”给弄出来才罢休，呵呵，王婆卖瓜一把 所以，我做讲师确实是一个我希望做的事情，但是现在还是觉得火候不够，也许再等几年会正式考虑这个问题。先谢谢这位朋友的好意。

软件创造价值！ 我希望更多的做技术的人能够重新认识这个问题，上一次参加一个培训，听说很多人通过编写共享软件赚了N多的刀拉,再看看网络飞速发展的今天，编写一个软件只要有价值，通过互联网这个杠杆可能会有你意想不到的成果也说不定。

技术可以变得如此有活力，让我们一起为之努力、奋斗吧。

纯粹意义上的项目经理是不用管技术的问题的，只负责管理，但是在一个中小公司可能出入就很大了，比如，在我所在的公司，项目经理=客户需求+项目管理+软件架构+程序编码+部署+测试+项目验收，如果需要的话也可以兼个DBA ,还好，我以前的功底相对比较扎实，从linux到windows server到sqlserver 到oracle到jboss到websphere算不上精通也都基本能独立搞定，但要说效率有多高可能就不好说了.

我个人还是倾向于“分布式”，即各司其职，有人设计，有人实现，有人管理，有人维护，我还是欣赏我当初参加工作时在北京网通小灵通账务管理的项目中的人员分配的方式，现在想来还是比较合理，在我们B/S组分配是：一名项目经理，主要负责总体和客户的沟通，一名需求管理人员兼DBA；一名技术经理带2个 后台开发人员；后台开发人员各带一名前台开发人员；一名测试人员负责测试，同时负责用户平时的基本修改意见的汇总，如果有较大的变动则通过项目经理。而反观我们现在的一些项目会发现，程序员居然和客户沟通起来了，真是不怕天下大乱，用户A提一个问题，程序员A修改了，过一段时间A又提一个问题给B，B也修改了，有一天程序员A和程序员B都走了，客户觉得我的好多以前提的东西你们怎么现在的人都不知道啊？ 双方都受伤害。其实，合理的架构才能保证有序的结果，一个小打小闹的团队怎么能应付日益变化的客户需求呢。

如果条件允许，我建议一个具有竞争力的团队应该是一名架构设计人员，一名DBA，3-5名中等水准的开发人员，一名美工，一名测试，其中DBA和美工是共享人员，临时参与，测试放到一个更重要的位置，即，始终跟踪全部的客户需求，所有的修改变更都是通过测试人员，程序员和客户之间隔离开。其实这不就是“面向对象”么？ 松耦合和紧耦合肯定不是一回事。现在很多的公司的高层人员普遍比较短视，所谓的理由就是“成本”，我的回答是：出来混迟早要还的！ 现在不这么做，迟早要付出代价。

key words:数据库 主键

在一个差屁股的项目中看到数据库的设计着实让人窝火,业务也算有点复杂，但是关键的表其实也就不超过10来个，但是能把你整晕，让人不得不佩服当初数据库设计的人员的构思. 总体来看存在问题就是主键命名不当，外键的命名也不规范，在和项目组人员的沟通过程中我就强烈暗示大家以后的项目中主键不要想花里胡哨的名字了，直接全部一刀切”ID”就OK了(要是非要找一个理由，不妨看看rails的最佳实践做法)，直观明了，外键的名字用父表的表名_id .

另外，我的一位同事提到给表的前面加上业务前缀，或者叫模块前缀，也有实际意义，主要是在项目相对比较复杂，模块比较多的时候比较有用，比如 businessa_table,businessb_table,可能也会看起来麻烦一些，看情况了。

详细设计思路

1. 指导方略

① 软件架构师完成设计规范的制定

② 设计任务由架构师分配

③ 设计的过程由架构师来进行制定

④ 推荐使用

n Rational RMC

2. 获得设计素材

① 局部分析

n 边界对象

n 实体对象

n 控制对象

② 健壮性分析

③ 场景装换

④ 对象整理工作（获得80%的类）

3. 去除重复性设计

① 类更小分解

n 重复性提取

② 重复性类只做一次

4. 去除相似性设计

① 共性与个性的分离

② 封装共性到基类

n 抽象类或接口

n 深层次设计

考虑扩展性问题

à 桥接模式

对象管理

à 工厂模式

算法问题

à 模板模式

à 策略模式

à 状态模式

à 职责链模式

流程问题

à 状态模式

à 构建者模式

à 管道过滤器模式

管理问题

à 微核模式

取自架构

à 管道过滤器

à 代理者模式（10种）

à IOC模式

à AOP模式

à 反射模式

5. 发现变化趋势

① 用例的扩展点发现变化趋势

② 看到趋势后–封装变化趋势

6. 类的元模型提取

① 类不断的原子化

② 类的分类

7. 类的质量设计

① 质量属性

n 用户的视角获得质量描述

② 设计质量

n 服务性元素

8. 类的环境设计

① 类的依赖平台

② 软件环境

n 操作系统

n 语言

n 框架

UML容易让一些人望而生畏，这也不奇怪，因为它看起来有些复杂，不过作为一种描述的文档，它毕竟是有用的。

use case:在需求阶段，捕捉用例，为后面的分析提供初步的依据

健壮性分析 :画出边界对象、控制对象、实体对象

序列图:描述场景

类图

整体关系如下：

继续谈我的软件设计师课程中的体会：

这次课程中看到老师的硬盘里充满了实际的项目，一方面佩服老师做过的项目之数量之惊人，另一方面也感受到到处充满着设计的内涵，从系列的文档之中感觉到做的之专业。

老师提示： 多阅读经典源代码，比如jive,junit,类库等等，最好也多从宏观的角度来观察，比如uml角度，设计模式的角度。这次我就把jdk和junit、hibernate等的代码导入到EA,下一步就是好好的阅读下 ,希望能有收获。

另外一点：技术的互通性是正常的，做java的不要对微软有敌视，反之也然，作为架构师或系统分析师，应该从设计的角度来看待二者，具体展现可能不同，但是思想总是可以借鉴的。当然，这是更高的一个境界了。

最近参加了一个软件设计师的课程，老师推荐了几本比较经典的书

• 《UML宝典》

• 《UML业务建模》

• 《设计模式》GOF

• 《面向模式的软件体系结构》1-3

• 《数据库重构》

• 《重构》

• 《UML企业应用建模》ORM POEAA

• 《高质量编程艺术》