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

精选留言(28)

• 

  godtrue

  我感觉自己处在一个由粗到细的转换过程，回想我们的代码产生过程，大概如下：
  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

  

   16
• 

  third

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

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

  2018-08-22

  

   8
• 

  艾尔欧唯伊

  粗方式才能有快速产出，产出积累到一定量之后，精益才能提取精华，浓缩沉淀。

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

  2018-08-22

  

   5
• 

  KaitoShy

  在没有成熟方案时，以快速实现为主，而有了之后再慢工出细活？

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

  2018-08-22

  

   4
• 

  依米

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

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

  2018-11-14

  

   3
• 

  Xhavit🍭

  在质量、成本和效率之间做好权衡和取舍，先完成，后完美，嗯，改掉这个阶段的完美主义思维

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

  2018-11-26

  

   2
• 

  Kuzaman

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

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

  2018-08-25

  

   2
• 

  godtrue

  因为架构师更贵

  2018-08-22

  

   2
• 

  Sands

  陶器故事在黑匣子思维看到过

  2018-08-22

  

   2
• 

  偏偏喜欢你

  老师您好，我现在正处于粗放的阶段，都是以完成需求为目的，暂时还没考虑到你所说的精益。

  作者回复: 有意识的形成这种写代码的思维方式，不要陷入重复中

  2018-08-22

  

   2
• 

  阿信

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

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

  2019-03-10

  

   1
• 

  苦行僧

  小到一个类名 一个函数名 一个变量名 一段超过几百行的类 都值得再次优化改进 我觉得程序员要有精益思维 增一分则多 减一分则少 如此种种改进 定能提高自己写代码 写出满意代码

  作者回复: 这也是一种产品和审美思维的修炼

  2018-12-25

  

   1
• 

  朱月俊

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

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

  2018-10-17

  

   1
• 

  belongcai蔡炳榕

  是的，我觉得码农的蜕变在于不断地迭代，提炼。

  作者回复: 对

  2018-09-15

  

   1
• 

  八戒

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

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

  2018-09-03

  

   1
• 

  天行冕下

  我理解的粗犷应该是:在有限的时间内解决我们需要解决的问题，而不是谨小慎微，面面俱到。
  但是，粗犷不是一种借口。我们的工作始终都是建立前人基础之上的，已有的设计模式、架构模式、成熟的框架等等，都是我们工作的基础。

  2018-08-24

  

   1
• 

  云学

  用心写代码成就卓越软件

  2018-08-22

  

   1
• 

  gkb111

  基本功能完成，不是放在那里，而是不停改进直至完美，这才是完美主义思维。

  2019-10-11

  

  
• 

  丁丁历险记

  处于你看完设计模式就死命折腾那位同学的状态

  2019-10-02

  

  
• 

  赵高龙

  目前处在逐渐精益的阶段，在之前写的系统有个功能写到四五百行代码，后来调整删减了三百多行。在调整完有很大的成就感，同时也看到当年那个粗放的少年。粗放确是精益的必经之路。

  作者回复: 很有形象感，粗放的少年

  2019-07-05

  

  