说说我理解的职业开发人员(2)

　　这个问题非常普遍，也很严重。我思考了很久，发现比较合适的解决办法是进行角色的互换，尤其是开发方(包括开发人员)，不能局限于“按照规程实现功能”的角色，而应当深入思考和理解业务。

　　不少开发人员最“理想”的工作环境就是：根本不关心自己的工作成果给谁用，怎么用，会产生什么结果，他们更喜欢这样的描述：什么类型的数据从哪里来，怎样处理之后，最后交给哪里。在架构清晰、流程完备的大公司里，或许你只需要安心填格子即可，但是拥有这样工作环境的开发人员，占总数的多少呢?更多的人面对的还是变化不定的需求，甚至连业务部门自己都不清楚自己要的是什么，这种情况下，只关心“数据从哪里来，怎样处理，交给哪里”之类的问题，无异于盲人骑瞎马，无异于挖坑埋葬自己。

　　相反，如果你清楚某个实现方案的缘由，知道它是基于何种应用场景，如何设计出来的，就可以在相当程度上把握它的价值和所需的工作量。如果更主动一些，可以和业务部门谈，这么做，将来会遇到什么问题，如果将来要改，哪些环节是可以改的，哪些环节是不能改的——如果你设身处地地为对方考虑，给出的建议一定比技术味道浓厚的“做不出来”更有说服力。如果做不到这么主动，你也可以预估，哪些业务是稳定不变的，哪些业务是一定会遇到问题需要改变的，然后可以合理分配工作量：对那些明显没什么前途的项目，可以适当保留资源，以免将来竹篮打水;对那些目前业务部门认为不重要，其实又相当有价值的项目，可以适当多投入精力，以免将来措手不及——要知道，业务部门提的“紧急”需求，多半不会考虑开发的工作量。

　　需要补充的是，做到上面这点，其实有相当的难度：一方面，你的技术功底必须足够扎实，在满足需求时，不仅仅是“模仿”现实，而应当知道这种现实，在数字世界里应当如何表达，如何重构，受到哪些条件和规则的限制(比如同一个抽象操作的不同实现，到底是选择Switch语句还是多态，其实是有章可循的，必须根据实际情况选择);另一方面，又要能跳开技术的局限，从更全面的视角理解、把握业务。不过，这是非常值得花功夫的——从某种意义上可以说，当前热门的“领域驱动开发(Domain Driven Development)”，说的大抵就是这回事。

　　时间

　　在软件开发中，时间绝对是一个非常重要的因素。在这方面，已经有无数的巨著，无数的案例，无数的先烈，但是时间，仍然是一个值得讨论的话题。

　　总的来说，人月是一个神话，我们不可能绝对精确地把握开发时间，但是这并不意味着，我们不能从某种程度上把握时间。我个人的经验是，计划是在现实参照下的不断调整和修正中逐渐准确的。最重要的，并不是确定远大的目标，然后限定多长时间必须完成;而是可以把大的项目拆分为不同的模块，把整个开发流程划分为不同的阶段。如果你的模块划分得足够细致，就可以以每个模块的工作量，相对准确地得知整个项目的耗时;如果你的流程划分得足够合理，就可以在各个阶段拿出看得见、用得着的结果，供业务方使用。这样，一方面避免了“到最后一起推出，却发现与业务方想象大相径庭”的尴尬;另一方面，在开发过程中，每个阶段结束，就可以提供一个阶段的生产力，作为开发方，在面对质疑时，有足够的资本和底气。

　　从个人方面，我注意到，职业开发人员还有另一个特点：就是可以相当精确地估计某个“小活”的工作量。以我自己和我的一些朋友为例，面对一些细致而且明确的需求，我们经常可以精确估计到工作量，时间精确到以半小时计。在紧密协作的“背靠背”编程中，我会说：现在是几点，所以我会在几点之前，给你提供怎样的功能，其行为是怎样的，接口是怎样的(行为和接口可以事先约定)。这样的自信，既要求对所需技术、会遇到难题的把握，也要求在头脑里对任务有完整清晰的模型。虽然难度不小，但能做到这一点，确实是职业素养的典型体现。

原文转自：http://www.ltesting.net