开发人员编码能力的提升.pdfVIP

精品文档

如何提升程序员的代码编写能力

一、先列三个常见的开发场景：

1、拿到一个模块详细设计文档，大部分程序员的通常做法就是开始搭建界面代码，然后从第

一个按钮点击事件或页面Load事件开始写第一行业务代码。写的差不多了，就运行一下，发

现哪里不是自己想的那样，就改改，直到改到是自己预想的那样。

2、做完了一个功能模块或几块相关联的功能模块，输入111asd，发现新建正常、保存正常，

就提交给测试人员。测试员用测试用数据、测试场景用例来测试，发现有问题，就登记bug。

对于严重的影响下一步测试的BUG，测试员就用内部IM通知这个开发人员。对于不影响继

续往下测试的BUG，测试员就登记下来，等程序员有空时处理。

3、程序员一般工作不希望大家打扰，所以开发起来就是开发。等手头开发告一段落，就看看

BUG库。发现有与自己有关的BUG，就从第一个BUG开始看起。就开始通过IM和测试员

掰扯起来（这不是个BUG啊、业务逻辑不是你想的那样啊、我这里不能重现啊、你给的信息

描述不清晰啊），于是IM几来几往，甚至跑过去当面交流一番，甚至会拉扯上产品经理一起

讨论，更甚者需要项目经理或产品经理发起一个会议来集体讨论一下

这是不是很熟悉呢？这就是大部分程序员开发的三个步骤：写代码、自测、修复BUG。

二、说好的代码设计、代码测试呢？

代码设计？那不是都有开发平台么，已经固化了啊。那不是维护旧功能做完善修改呢么，又

不是写新代码，只能在现有代码基础上修改啊，你又不能大幅重构。

可编辑

精品文档

代码测试？你丫需求讨论期、产品设计期、设计评审期那么长，都把研发项目时间占光了，

就留下2个星期让我们写代码，我们哪里有时间搞那么深的测试。还想让我们搞结对编程？

还想让我们搞测试驱动开发？

而且你看测试，什么功能测试、集成测试、性能测试、安全测试、安装部署测试、升级测试、

迁移测试、UAT测试，一大堆测试，测试也需要很多时间。

一个项目，需求讨论、产品范围规划与评审、产品设计与设计评审占了一个半月，开发+自

测就一个月，测试占了一个半月，这就4个月了啊。

三、为啥程序员写代码总是写写测测？

刚才大家也都看到了，大部分程序员都是从界面代码开始写起，而且写一写，就运行一下看

看。为什么会是这种开发方式？

那是因为大部分程序员缺乏在脑子中的整体建模能力。只能做出来一点，真实的感觉一下，

然后再往下。

有些是产品经理的上游就有问题，没给出业务流程图（因为产品经理也没做过业务），也没

画清楚产品功能操作流程图。

为啥没给出业务流程图？因为产品经理不熟悉业务，另外，产品经理也没有流程建模能力啊。

为啥没画清楚产品功能操作流程图啊？因为不会清晰表达流程啊。

很多产品经理、程序员，都缺乏分类、分层、相关、先后能力，更别说总结、洞察能力。

这是基本训练，是一个做事头脑清醒的人必备的技能，这不是一个程序员或产品经理或测试

员的特定技能要求。

可编辑

精品文档

我经常看书就梳理书的脉络，每看一本就写一篇总结。我过去闲扯淡还梳理过水浒传、红楼

梦的人物关系图呢，其实就在事事上训练自己的关联性、层次性、洞察性。

我经常面试一个人时，我会问这样的问题：“你把我刚才说的话复述一遍，另外你再回答一

下我为什么会这样？”，其实，我就在看一个人的细心记忆、完整梳理、重现能力，我也在

看一个人的梳理、总结、洞察能力。

我个人写代码就喜欢先理解业务流，然后理解数据表关系，然后理解产品功能操作流，大致

对功能为何这样设计、功能这样操作会取什么表、插入或更新哪些表，哪些表的状态字段是

关键。

业务流、功能操作流、数据输入输出流，

然后我写代码的时候，就根据我所理解的定义函数，

定义函数的输入与输出。

然后，我会给函数的输入值，赋上一些固定值，跑下来看看能否跑通这几个关联函数，看看

还需要怎样的新增函数，或