程序员进阶攻略
胡峰
京东成都研究院技术专家
33679 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 65 讲
蜕变:破茧成蝶 (3讲)
结束语 (1讲)
程序员进阶攻略
15
15
1.0x
00:00/00:00
登录|注册

09 | 粗放与精益:编程的两种思路与方式

好与精益
多与粗放
粗放与精益:编程的两种思路与方式

该思维导图由 AI 生成,仅供参考

几年前,我给团队负责的整个系统写过一些公共库,有一次同事发现这个库里存在一个 Bug,并告诉了我出错的现象。然后我便去修复这个 Bug,最终只修改了一行代码,但发现一上午就这么过去了。
一上午只修复了一个 Bug,而且只改了一行代码,到底发生了什么?时间都去哪里了?以前觉得自己写代码很快,怎么后来越来越慢了?我认真地思考了这个问题,开始认识到我的编程方式和习惯在那几年已经慢慢发生了变化,形成了明显的两个阶段的转变。这两个阶段是:
写得粗放,写得多
写得精益,写得好

多与粗放

粗放,在软件开发这个年轻的行业里其实没有确切的定义,但在传统行业中确实存在相近的关于 “粗放经营” 的概念可类比。引用其百科词条定义如下:
粗放经营(Extensive Management),泛指技术和管理水平不高,生产要素利用效率低,产品粗制滥造,物质和劳动消耗高的生产经营方式。
若把上面这段话里面的 “经营” 二字改成 “编程”,就很明确地道出了我想表达的粗放式编程的含义。
一个典型的粗放式编程场景大概是这样的:需求到开发手上后,开始编码,编码完成,人肉测试,没问题后快速发布到线上,然后进入下一个迭代。
我早期参与的大量项目过程都与此类似,不停地重复接需求,快速开发,发布上线。在这个过程中,我只是在不停地堆砌功能代码,每天产出的代码量不算少,但感觉都很类似,也很粗糙。这样的过程持续了挺长一个阶段,一度让我怀疑:这样大量而粗放地写代码到底有什么作用和意义?
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

编程的两种思路与方式:粗放与精益 本文探讨了编程过程中的两种思维方式:粗放与精益。作者通过自身经历和比喻,阐述了编程的精进之路,强调了在追求更好编程质量的道路上,需要经历“更多”这条路。文章借鉴了传统行业中的精益生产理念,强调了在编程中追求质量、成本和效率的平衡。作者分享了自己在编程过程中的体会,强调了不断尝试、不断精进和进阶的重要性。文章提出了一个观点:编程是一个不断精益化的过程,好不是完美,而是一个不断进步的过程。在编程的道路上,需要在“多”与“好”之间取得平衡,同时考虑功能、质量和效率的需求。读者可以从中获得对编程思维方式的启发,以及在编程过程中如何取得平衡的思考。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《程序员进阶攻略》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(36)

  • 最新
  • 精选
  • 我感觉自己处在一个由粗到细的转换过程,回想我们的代码产生过程,大概如下: 1:prd评审 2:表结构设计、缓存结构设计、程序逻辑梳理,输出对应的文档,进行初评 3:代码编写 4:自测、提测 5:代码review 6:调整和完善代码 7:合并主干回归测试 8:上线准备、上线申请、上线、产品及业务线上验证 9:线上观察 其中第5步,资深和架构都会参与,一般都会提出一些改进和完善意见。这个环节可看出编码功力的深浅及考虑的是否全面。 主要会考察一下方面: 1:业务逻辑是否OK 2:是否打点 3:日志是否OK 4:代码性能是否良好 5:基本的编码规范是否符合 6:代码可读性如何 7:异常处理的是否合理 刚开始总会拉下些什么,现在这个模式已经比较熟练了,不过还是会有一些改进意见,比如:应用交互是否OK、代码抽象层级是否合理 非常感谢我们的代码review同学们,让我成长不少。

    作者回复: 不错,但是为什么Review在提测之后?

    2018-08-22
    33
  • third
    1.个人觉得粗放并不是多,核心在“迭代”,这是一个慢慢变好的过程 迭代的好处就是试错和反馈。 试错,是快速找到自己根本没有意识到的错误,看一遍和做一遍差距太大 反馈,你会在做不停做中得到反馈,并迭代 2.快速是其中关键因素,迭代速度越高,成长也越快 3.粗放和精细,背后其实是成本 比如文中老师和老师同学的例子。老师做了改进,吸收到了《设计模式》的一些知识,很大程度上,是因为老师开始做这件事情的成本其实比那个刚开始做的老师同学低得多。 毕竟,当时的老师已经有一个程序了。 而老师的同学在一个零基础上做程序,其实成本更高。 4.个人想法 理解我们在当下得到的一切,都是此前一切总和结果中,最好的一个。 粗放也好,精益也好。 其实我们的能力都是一样的 变得精益也许只是一个结果,成本更低。 要写更优雅的代码,更好的运行一切的一切,都是因为越来越复杂的代码和框架逻辑,更加大型的用户使用量等等硬性制约而已。 慢慢成长就好

    作者回复: 对,成本是一个核心考虑点。从多到好的过程中,反馈与迭代改进在发挥关键作用

    2018-08-22
    10
  • 依米
    老师,我也是发现自己编码速度越来越慢,不过不是老师的情况,大约是和你的同学类似,越来越不敢下手写代码了,写之前要纠结很久,各种考虑,很不喜欢现在的样子,但还是会不自觉的沉浸在里面,该咋办?

    作者回复: 限定时间,必须交付,纠结是无法交付的

    2018-11-14
    8
  • 艾尔欧唯伊
    粗方式才能有快速产出,产出积累到一定量之后,精益才能提取精华,浓缩沉淀。

    作者回复: 恩,是这样的。关键是你得去迭代并提炼,而非重复

    2018-08-22
    6
  • KaitoShy
    在没有成熟方案时,以快速实现为主,而有了之后再慢工出细活?

    作者回复: 哪里该快,哪里该慢,是考验人的地方

    2018-08-22
    5
  • 阿信
    介绍编程的两种思路,完美型和现实型。 看这篇文章,脑海中想到了两件事情,一是卖油翁的故事;二是态度(吴军老师写的)一书中提到的一些观点:最好是更好的敌人(或者说进步一点比什么都不做好)、做事情时境界要高。 陶器制作第一组的同学,可以说是熟能生巧;陶器制作第二组的同学以及课程设计的同学,境界是比较高的,但在其事情落地上执行方式有点问题,因为没有找到完美的方案而踌躇不前,最终没有输出满意的成果。 套用到我们自身的工作,以及绝大多数程序员身上,大量的开发(+用心理解)可以提升我们的水平,我们要求输出的成果有deadline,设计时我们格局可以大一些,考虑后来的扩展,实现时可以分步来执行,多次的改进让我们朝着目标前进,甚至超过原有心中的完美方案。

    作者回复: 嗯,这样的平衡很好,现实经常是这样的

    2019-03-10
    3
  • xhavit
    在质量、成本和效率之间做好权衡和取舍,先完成,后完美,嗯,改掉这个阶段的完美主义思维

    作者回复: 嗯;完美主义总是相对的

    2018-11-26
    3
  • 朱月俊
    我现在编码状态是:务必要在可能出异常的代码附近加日志;一定要测试程序的性能是否符合要求;编码风格务必符合规范;参照同类开源代码参考编码方式。

    作者回复: 这样的状态和要求不错呀

    2018-10-17
    3
  • 八戒
    老师,最近在处理问题的时候,总是觉得项目以前的代码有问题,冗余不够精简,喜欢去提取公共模块封装再处理,尝试着怎么把代码质量提上去,不知道这是不是就是您说的精益阶段呢

    作者回复: 是的,不过干这个事情要谨慎些,步步为营

    2018-09-03
    2
  • Kuzaman
    本章收获颇多,我是做测试的,甚至不是测试开发级别,只是偶尔写写代码。目前只能处于粗放阶段,我一直困惑于精细还是粗矿,买了很多书很多视频看,总想着精细化,后来代码一直没有产出。听了老师的课,真是答疑解惑,因此决定先出量粗矿着到一定程度再说。感谢!

    作者回复: 恩,写得多了,感觉就来了

    2018-08-25
    2
收起评论
显示
设置
留言
36
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部