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

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

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

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

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

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

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

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

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

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

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