在编程的时候，你会花多长的时间来思考？

[wyan453351466]

看到一个说法是，编程应该用 80%的时间思考 + 20%的时间写代码。

你如何看看待这个说法？

你会在编程前，先花 80%的时间用来思考吗。

或者说，你有在开发前，先写好思路 /文档 /流程图的习惯吗

[meepo3927]

确实是 80%的时间思考， 其中 90%是在思考怎么调试。

[37Y37]

对于我来说 80%可能有点多，但至少也有一半，可能跟写的东西有关，我写的一般也就只有我是需求，从前端到后端一人撸下来，也没太多时间限制，所以想的时间多点

[pingpingping]

先草草写下来，然后不断完善，完善过程中思考？
很久没写了，最近都是这么操作的，感觉效率不高可能

[diubo]

时间上不一定 80/20，但动手前的思考，确实对开发效率影响很大，尤其是前后端一个撸的情况下。

[Flobit]

反正先想清楚最好，避免写着写着发现不对……

[zgl263885]

不是必须，但是差不多，上去就是干的一般都干到半夜还干不完

[mcfog]

是 80%，但不是集中在编程前，不是瀑布式的先全想好，然后无脑实现。而是先总体设计，然后实现的同时考虑细节、异常、维护性等等

[season4675]

40%思考，10%写代码，50%调试和解 bug

[IGJacklove]

会先考虑逻辑可行性，觉得没问题就直接写。过于纠结时间比没什么意义吧

[Leonard]

看你写什么东西，写简单逻辑或者 UI 的话只管上手就行了

[zunceng]

实际开发中 项目越大 思考的占的比例越大 ， 主要原因是程序的主干框架变得更重要

前期主要是做抽象考虑程序的主干框架， 不考虑细节。
编码时处理细节也很重要 工业（生产）级别的代码 一般来说每个 error 都需要 handling， 这个需要查手册 局部的代码逻辑思考 必须在编码过程中处理的， 没必要一开始就想好。

[Vegetable]

思考实际上是在设计,不同人的岗位职责不同,设计需要的时间也肯定不一样.负责搭建架构的人肯定要想更多,按照接口文档撸 crud 自然就没什么可设计的,经验丰富的话就等于抄.

[zunceng]

对于一些依赖比较少的项目 比如 linux 内核，前期很多时间花在前期看论文查资料上， 编码时使用的其他模块 API 甚至 API 的报错对于开发者来说已经很熟悉了， 确实可以做到， 编码占很少时间。

对于现在一些应用开发， 处于一种 API 爆炸的阶段 一个应用可选择的第三方库，细节处理方式都很多， 对于开发者来说不熟悉就要花更多时间。

不用太在意 “应该用 80%的时间思考 + 20%的时间写代码” 这句话怎么适合自己适合团队就行

[fengbjhqs]

要看复杂程度， 经验，

[cwjokaka]

花少部分时间思考，先实现最基本的功能，测试，再优化

[sonxzjw]

看情况，流水线不怎么需要脑子的，20%绰绰有余
设计的话，我基本要超过 50%进行思考设计

[weer0026]

思考比重肯定很大，但是我没思路了就会先写一会儿找找灵感。

[wlfeng]

先全部理清了再动手，中途发现问题再做调整

[qinyusen]

90%的时间想清楚，然后写测试（测试即用例），然后 10%差不多就能写了，因为想清楚了，而且测试写完，不会有模糊不清的需求和功能，直接搬砖就行。。。10%时间很充足。

[zhujz]

公司急着上线，根本没时间想怎么搞，基本是能实现功能就上了。