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

1、拿到一个模块详细设计文档,大部分程序员的通常做法就是开始搭建界面代码,然后从第一个按钮点击事件或页面Load事件开始写第一行业务代码。写的差不多了,就运行一下,发现哪里不是自己想的那样,就改改,直到改到是自己预想的那样。

2、做完了一个功能模块或几块相关联的功能模块,输入111asd,发现新建正常、保存正常,就提交给测试人员。测试员用测试用数据、测试场景用例来测试,发现有问题,就登记bug。对于严重的影响下一步测试的BUG,测试员就用内部IM通知这个开发人员。对于不影响继续往下测试的BUG,测试员就登记下来,等程序员有空时处理。

3、程序员一般工作不希望大家打扰,所以开发起来就是开发。等手头开发告一段落,就看看BUG库。发现有与自己有关的BUG,就从第一个BUG开始看起。就开始通过IM和测试员掰扯起来(这不是个BUG啊、业务逻辑不是你想的那样啊、我这里不能重现啊、你给的信息描述不清晰啊),于是IM几来几往,甚至跑过去当面交流一番,甚至会拉扯上产品经理一起讨论,更甚者需要项目经理或产品经理发起一个会议来集体讨论一下

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

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

代码设计?那不是都有开发平台么,已经固化了啊。那不是维护旧功能做完善修改呢么,又不是写新代码,只能在现有代码基础上修改啊,你又不能大幅重构。

代码测试?你丫需求讨论期、产品设计期、设计评审期那么长,都把研发项目时间占光了,就留下2个星期让我们写代码,我们哪里有时间搞那么深的测试。还想让我们搞结对编程?还想让我们搞测试驱动开发?

而且你看测试,什么功能测试、集成测试、性能测试、安全测试、安装部署测试、升级测试、迁移测试、UAT测试,一大堆测试,测试也需要很多时间。

一个项目,需求讨论、产品范围规划与评审、产品设计与设计评审占了一个半月,开发+自测就一个月,测试占了一个半月,这就4个月了啊。

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

刚才大家也都看到了,大部分程序员都是从界面代码开始写起,而且写一写,就运行一下看看。为什么会是这种开发方式?

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

有些是产品经理的上游就有问题,没给出业务流程图(因为产品经理也没做过业务),也没画清楚产品功能操作流程图。

为啥没给出业务流程图?因为产品经理不熟悉业务,另外,产品经理也没有流程建模能力啊。为啥没画清楚产品功能操作流程图啊?因为不会清晰表达流程啊。

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

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

我经常看书就梳理书的脉络,每看一本就写一篇总结。我过去闲扯淡还梳理过水浒传、红楼梦的人物关系图呢,其实就在事事上训练自己的关联性、层次性、洞察性。

我经常面试一个人时,我会问这样的问题:“你把我刚才说的话复述一遍,另外你再回答一下我为什么会这样?”,其实,我就在看一个人的细心记忆、完整梳理、重现能力,我也在看一个人的梳理、总结、洞察能力。

我个人写代码就喜欢先理解业务流,然后理解数据表关系,然后理解产品功能操作流,大致对功能为何这样设计、功能这样操作会取什么表、插入或更新哪些表,哪些表的状态字段是关键。

然后我写代码的时候,就根据我所理解的业务流、功能操作流、数据输入输出流,定义函数,定义函数的输入与输出。

然后,我会给函数的输入值,赋上一些固定值,跑下来看看能否跑通这几个关联函数,看看还需要怎样的新增函数,或者看看函数的输入输出参数是否满足跑通。

剩下的事,就是我填肉写详细逻辑代码了。

当然,大部分人没我这样的逻辑建模能力。怎么阅读理解也想象不出来,也没法定义函数。毕竟有逻辑建模能力的程序员都很少,100个人里有10个,已经是求爷爷告奶奶好幸运了。

那怎么办呢?

我建议是分离分工配合,这就是现实中没办法的办法。让有逻辑建模能力的人来设计函数框架、来设计工具来设计代码模板,然后让没有逻辑建模能力的人来填肉写详细逻辑代码。

我们可以先从最紧要的模块开始这么做。不紧要的模块,还让它放任自流,让熟练手程序员继续涂抹。

我曾经还让有头脑的程序员做榜样,给大家分享他是怎么规划函数的,怎么做维护性代码的代码结构改善的。但是发现效果并不佳,其他人并没有因此能做代码设计。可能逻辑建模能力是个人的基本素质,是从小到大训练成型的,不是你一个大学已经几年的人能够短时间内可以训练的。

所以啊,还是让能走的人先走,让从最紧要的模块开始这么做。

不必担心这样做后,因为过去一件事被分工(一个做代码框架一个填肉)成两个人做了会降低工作效率。我们很多的工作效率低就是因为半瓶子醋搞出来的,来回反复修改。

真是应了刘德华在电影里说的那句话:说你又不听,听又听不懂,听懂了又不做,做又做不好,做不好还不服气。

四、为什么大部分程序员不做代码测试或白盒测试或单元测试呢?

还是因为没有代码设计。因为没有函数啊。所以,一个按钮功能有多复杂,代码就有多长。我见过2000行的函数,我也见过1000多行的存储过程和视图SQL。怎么做白盒测试啊,这些代码都粘在一起呢,要测,就得从头到尾都得测。

所以啊,先学会设计函数,先写好函数,这就求爷爷告奶奶了。很多开发了5年的熟练手程序员,可能都未必会写函数。

函数的输入输出值就很有讲究。很多人都写死了,随着版本迭代,发现过去定义的函数参数不够用了,于是就新增了一个参数。然后,相关性异常就爆发了,其他关联的地方忘改了,到底哪些有关联,怎么查啊,本系统没有,没准其他系统就调用你了,你根本不知道哪个神经人曾经COPY过你的代码修吧修吧就改成了他的功能呢,而且里面的很多代码他看不懂也不敢删,只要他实现的功能正常了他也不管了。于是,你改了你这个函数,他的系统就莫名出错了。

所以,我一般会定义几个对象来做参数。另外,我也很注重函数的日志、函数的异常保护、异常抛出、异常返回。另外,我也很注重参数输入值的合法性校验。

所以啊,应该开发Leader们先制定函数编写规范最佳实践,输入输出参数怎么定义比较好,函数的返回值如何定义比较好,函数的日志记录应该怎么写比较好,函数的异常保护、异常抛出、异常返回如何写比较好。先教会一般程序员,先从会写函数开始啊。

当然,你光有一份规范,程序员们还是不理解、不实际应用啊。所以,还得Leader们做好典型的代码模板,里面是符合函数规范的代码框架,只有这样,一般程序员们才会照猫画虎适应了函数设计的编程习惯。

所以啊,我专门重新定义了leader的明确职责,其中第一个重要职责就是:负责工具/框架/模板/规范的制定,并且负责推广且普及应用落地。

你不明确定义Leader的这个重要职责,你不对这个职责做明确的KPI考核,谁尿你啊。你以为好的工具/框架/模板/规范是靠人们的热情、自发产生的么?我们还没有那么自觉高尚啊。

五、为什么大部分程序员不写注释啊?

我经常说一句话,千万别多写注释。为啥?

因为我们经常遇到的问题不是没有注释,而是更糟的是,注释和事实代码逻辑是不相符的。这就出现常见问题了:残存下来的设计文档是一个逻辑、注释是一个逻辑说明、真实代码逻辑又是一个,钟表多了,你也不知道正确时间了。

所以啊,产品文档、注释、真实代码,三者总是很难一致同步。我为了几百人研发团队能做到这个同步花了大量心血和办法,但我最终也没解决了这个问题,还把Leader们、总监们、我都搞的精疲力尽。

索性回归到一切一切的本源,代码,就是程序员的唯一产出,是最有效的产出。那么,让代码写的不用注释也能看懂,咱得奔着这个目的走啊。

为啥看不懂,不就是意大利面条式代码么,又长又互相交杂。

OK,我就规定了,每个函数不能超过50行。用这一个简单规定和静态代码检查插件,来逼迫大家尝试着写函数。有的函数属于流程函数,是串起其他函数的,有的函数就是详细实现函数,实现一个且唯一一个明确作用的。

有了流程函数和功能函数,而且每个函数不超过50行,这就比过去容易看懂了。

六、为什么大部分程序员不抽象公共函数啊?

我经常说一句话:千万别抽象公共函数啊。为啥?

因为大部分程序员缺乏抽象洞察能力。特别是有些积极热情有余、爱学习爱看书、半瓶子醋晃悠的二杆子,看了几本UML、重构、设计模式、整洁代码之道,就跃跃欲试了,还真敢给你抽象公共函数了。

一开始,他觉得80%相似,20%不相似,于是在公共函数里面简单写几个if..else做个区隔就可以。没想到,越随着版本迭代,这些功能渐渐越变越不一样了,但是这个代码已经几经人手了,而且这是一个公共函数,谁也不知道牵扯多少,所以谁也不敢大改,发现问题了就加一个if..else判断。

没想到啊没想到,这个本来当初公共的函数,现在变成了系统最大的毒瘤,最复杂的地方,谁也不敢动,除非实在万不得已,手起刀落。

所以,我平时告诫程序员,纯技术的、纯通用的,你们可以尝试搞搞抽象公共函数,对于业务的,你们还是简单粗暴的根据Leader们做的代码模板代码框架,乖乖的复制、修改、填肉吧。

你们啊,先从做模板做代码片段开始吧,咱们放到咱们内部代码片段开源库里,看谁的代码片段被别人复制的多,说明你的代码抽象设计能力越好了。那时候,我就大胆放心让你撒丫子跑了。在没有学会跑之前,给老子乖乖的复制、修改、填肉吧。

怎么提升个人的代码编写能力相关推荐

  1. linux中pss用法,使用 pss 提升你的代码搜索能力 | Linux 中国

    原标题:使用 pss 提升你的代码搜索能力 | Linux 中国 搜索代码库是开发者每天都要做的事情.从修改 bug 到学习新代码,或者查看如何调用某个 API,能快速在代码库中导航的能力都是一大助力 ...

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

    啊呀妈呀,那个熟悉的阿朱又回归了,呕心之作,跪了. 一.先列三个常见的开发场景: 1.拿到一个模块详细设计文档,大部分程序员的通常做法就是开始搭建界面代码,然后从第一个按钮点击事件或页面Load事件开 ...

  3. 如何提升文档编写能力

    在我身边的程序员中,无论是现在的同事还是过去的同事,普遍缺乏文档编写能力或能力严重不足,甚至有些编程能力很强的程序员也不能写出一篇可读性较强的设计说明书.产品手册等项目必备文档.其实,文档编写能力是成 ...

  4. 如何才能提高文档编写能力呢[转]

    如何才能提高文档编写能力呢 该如何才能提高文档编写能力呢,可以采用了以下几种方法,只要坚持不懈的做下去,相信会有提高. 1.尝试编写个人简历和经历,用文字来认识自己是不错的方法.要想别人认识你,首先自 ...

  5. 《探索文心千帆大模型平台: 代码编写从此变得轻松》

    文章目录 前言 一.初识文心千帆 1.1 功能丰富 1.2 注册登录 二.内置第三方大模型 2.1 ERNIE-Bot模型 2.2 ERNIE-Bot-turbo模型 2.3 BLOOMZ-7B模型 ...

  6. 怎么提升写代码的能力

    作者 | 毕玄 来源|阿里巴巴云原生公众号 对于程序员而言,我始终认为代码是展现能力的关键,一个优秀程序员写的代码,和一个普通程序员写的代码是很容易看出差别的,代码作为程序员的硬实力和名片的展示,怎么 ...

  7. 如何提升你的代码能力?

    前言 作为程序员,我们怎么提升我们的代码能力? 在回答这个问题之前,我们需要先给代码能力下一个定义,搞清楚究竟什么是代码能力.只有找对了路才方便发力,很多同学对这个问题其实是不够清楚的.往往会觉得代码 ...

  8. Python代码编写过程中有哪些重要技巧?

    近几年,转行做Python技术岗的人越来越多,大家对于Python的关注越来越高,尤其是工作后,很多人都想知道Python代码编写过程中有哪些重要技巧?小编告诉大家,在编写Python代码过程中,除了 ...

  9. 张正友标定论文的解读和C++代码编写

    1.概述 张正友标定相机内参是非常经典的标定算法,现在代码已经被集成到MATLAB和opencv里面.不过因为算法涉及到基础的相机坐标系.图像坐标系.公式推导,以及优化算法,故根据张正友论文进行分模块 ...

最新文章

  1. 在linux 下怎么查看服务器的cpu和内存的硬件信息
  2. 使用WinSCP在WIndows与树莓派之间传递文件
  3. 数据结构与算法必备的 50 个代码实现
  4. 手把手实现腾讯qq拖拽删去效果(二)
  5. Angular workspace默认的packages
  6. MySQL 如何复制表
  7. 前端常用 JavaScript 方法封装
  8. 二级c语言2013年真题,2013年3月全国计算机二级c语言真题
  9. 四款亲试好用的PDF编辑器推荐,看看哪款最适合你
  10. 电子设计(1)二极管防电源反接电路
  11. java判断是否英文_java如何判断字符串是否是英文
  12. 广播(BroadcastReceiver)---安卓中的四大天王之一
  13. 数据库实验三 数据查询一
  14. 安卓上哔哩哔哩视频的导出
  15. iphone一键转移_苹果手机如何一键转移数据 转移教程介绍
  16. 读《孙悟空是个好员工》有感(2005-5-23)
  17. WinRAR 无法关联zip、rar等文件
  18. 【第三方OA对接】01华为云WeLink对接项目总结
  19. 2021年第二届“大湾区杯”粤港澳金融建模竞赛B题解题思路和部分代码
  20. 【IPFS直播】 利用ipfs协议传输进行直播

热门文章

  1. 资深研发真实编写的骚注释,你学废了么?
  2. html 图片自动滚动播放,小卖弄:纯CSS实现图片滚动播放效果
  3. linux 系统命令被后门修改_一次Linux系统被攻击的分析过程
  4. JSD2212班第二次串讲-面向对象阶段
  5. 池化方法总结(Pooling) 和卷积 。 第三部分讲的很好
  6. 高等数学--高阶导数与隐函数,参数方程(三)
  7. vue系列教程之微商城项目|项目介绍
  8. 【差分约束】SCOI2011糖果
  9. 学51单片机,总是感觉学不会该怎么办呢?
  10. R语言ECM误差修正模型、均衡修正模型、受限VECM、协整检验、单位根检验即期利率市场数据