好的分析员?
作者:陆麟
转载请征得作者同意.
2004.11.19
时间久了, 牢骚已经不是牢骚, 成为了习惯. 回头看前自己的文章, 杂乱得很.
也没有遇到什么不满, 不知怎么的, 今天又要想写点东西. 来说说项目动手前的"分析". 这篇文章是写给系统分析师的, 你不是, 那就不用看了.
现在无论公司大小, 都在推"团队",讲"合作". 开始注重"分析". 前2个针对大项目是有道理的. 不少项目就是搭积木. 靠的就是人.
人多了, 开展就快. 讲合作, 无非就是项目经理预先说好了你作某块, 他作某块. 果然, 分配项目是麻利了不少, 但是也有不少仍然快不起来的.
到底是PROGRAMMER的原因, 还是设计师的原因, 还是分析员的原因?
想必你很自信自己的分析能力, 先看看下面的文字, 然后再回头想一下, 你有没有把所有的东西都考虑到.
既然今天讲分析, 那就先说分析这块. 大家开发时大会小会也开了. 东西想来也讲得清楚, 怎么就是无法按时完成项目? 真的"讲清楚"了?
不是巴. 恐怕你连想都没有想清楚巴. 我来个例子. "我们需要一段简单的数据保存的代码, 能把某个时期的数据保存下来, XX你来.
半天完成". 真的就这么半天? 包括验证? 我们来仔细考虑一下巴. 要保存一定时期的数据. 写数据的功能当然是需要了. 有了写,
不读有可能么? 验证写得对不对也是要读才能验证巴. 好办, 那就把读的那部分代码也加上人. 有了读, 有了写, 要查询么? 不要查询?
那保存一定时期的数据干什么? 好办, 把查询也加上去. 查询自然是可以获得1条记录, 或者多条记录的. 那有时候我们希望通过时间来查询,
有时候通过某个特定内容来查询, 一起作进去? 有读有写有查询, "这段代码是不是让所有的数据结构都可以共用一下啊?" 好巴. 写得通用一点.
这样不停写, 总会把硬盘写满的. 要留有一个删除的接口. 让用户决定什么时候删什么数据. 支持多个线程同时读写么? 那是一定的,
现在还有只能单线程跑的东西么? 那多线程写, 是不是同步动作要做进去? CALLER的验证要不要作啊? 万一CALLER下了错误参数,
把其他正常数据破坏了怎么办? 那也加.
现在回头看一看"我们需要一段简单的数据保存的代码, 能把某个时期的数据保存下来"的要求, 程序员会得到什么样的最终任务派发:
1. 支持读
2. 支持写
3. 支持删
4. 支持多种查询条件
5. 支持各种数据结构
6. 多线程同步
7. 参数验证
差不多了巴. 好了, 你已经决定就这点了. 慢, 还没有完! 现在要考虑怎么保存了. 用磁盘文件形式保存还是数据库保存. "用数据库太复杂,
还是不用. 我们求个简单,实现要快". 继续做你的梦巴. 我们顺着磁盘文件保存继续下去. 好巴, 读写都不是问题. 写到查询那部分了,
我们按照的是时间, 每个时间点开个目录, 这个时间点记录数据开个文件. 以后查询要参考某个时间, 打开对应的目录就好了. 恩?
那如果按照特定内容来查, 就需要把所有的目录下的文件都历遍一下... 好巴. 算了. 就这么, 慢就慢巴. 这是半天能写完的么?
半天写出来的东西你打算花多久DEBUG?
你正在越陷越深. 现在程序不仅是多线程的问题. 现在程序管理来自多个客户端的请求. 同一时刻有2个客户发出了相同的数据要求记录. 天啊?
怎么当初没有设计一个保留栏位来记录不同来源的相同内容数据? 现在代码要重新改写. 所有涉及的地方都要动. 不仅是数据读写删查的那块.
包括所有的调用它的地方每行都要检查参数有没有问题. 靠!
现在问题越发严重了. 客户发现, A地写入的数据在B地不能实时反映出来. 如果应用开定时器, 不挺地取数据, 效率不好.
无法预期什么时候会有新数据进来. 定时器间隔久了, 就没有"实时"性了. 这样, 增加一个接口, 一旦库里面有数据变动,
立刻通知所有的连接的客户. 嘿嘿, 麻烦大了. 每个调用需要记录连接状况, 到时候要发送数据回去的. 客户报告,
SERVER端运行一定时间会死机. DEBUG了2天, 发现原来是那对方关机, SERVER没有得到通知,
所有的数据都还保留着,下次连接申请了新的内存, 久而久之,RAM不够了. 需要有超时机制巴. 把超时机制写进去. 下面的程序员:"天啊,
代码已经乱七八糟了. 还要PATCH? 哼哼, 进公司以来, 哪个项目不是这样修修改改? 老子加班到死, 你就一句话, 再修改一下.
老子不干了." 当然, 你不干很明智啊. 再做下去, 还要补呢. 你不信? 我说来你听听. 一个文件改动了, 所有的客户都得到通知,
现在文件大到几个G. 你不能把几个G全部送到所有的客户这边巴. 这就要考虑只送变化部分的问题. 只送变化部分, 那其中一个客户数据发送到一半,
后面连续有N个操作, 删->添加->删->添加, 下次操作是不是只要把最新的记录送出去就是了? 难道要发送4个动作?
2个客户对同一个记录一个要删, 一个要改. 靠, 让谁干? 是不是要增加RECORD LEVEL的LOCK? 你不打算做么?
代码是不是要动得不成形状了?
这到底是程序员的毛病还是前期规划的问题? 程序员会认为是规划问题. 但是, 我认为这很大一部分是系统分析员的问题.
规划时刻没有可能想到PROGRAMMING时刻的细节. 确实只需要提出"我们需要一段简单的数据保存的代码,
能把某个时期的数据保存下来"这样的需求就可以了. 但是把状况考虑得清晰点则是系统分析的事情. 不管公司里面是否有系统分析员这个职务,
"分析"是逃不走的. 一定要干的. 我这里不是小看国内的写程序的. 大部分的人都没有这个"分析"能力. 在需求提出的第一时刻洞察到潜在的危机.
不少优秀潜质的PROGRAMMER在很烂的"分析员"或者"项目管理员"的指导下被整得毫无信心. 脱离的PROGRAMMER行业.
这次要棒打的是干"分析"这个环节的人物.