看到一个说法是，编程应该用 80%的时间思考 + 20%的时间写代码。
你如何看看待这个说法？
你会在编程前，先花 80%的时间用来思考吗。
或者说，你有在开发前，先写好思路 /文档 /流程图的习惯吗
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 2520 days ago, the information mentioned may be changed or developed.
 |
meepo3927Dec 11, 2019
1
确实是 80%的时间思考， 其中 90%是在思考怎么调试。
|
 |
37Y37Dec 11, 2019
2
对于我来说 80%可能有点多，但至少也有一半，可能跟写的东西有关，我写的一般也就只有我是需求，从前端到后端一人撸下来，也没太多时间限制，所以想的时间多点
|
 |
pingpingpingDec 11, 2019
3
先草草写下来，然后不断完善，完善过程中思考？
很久没写了，最近都是这么操作的，感觉效率不高可能 |
 |
diuboDec 11, 2019
4
时间上不一定 80/20，但动手前的思考，确实对开发效率影响很大，尤其是前后端一个撸的情况下。
|
 |
YanSepDec 11, 2019 via Android
5
反正先想清楚最好，避免写着写着发现不对……
|
 |
zgl263885Dec 11, 2019 via iPhone
6
不是必须，但是差不多，上去就是干的一般都干到半夜还干不完
|
 |
7
是 80%，但不是集中在编程前，不是瀑布式的先全想好，然后无脑实现。而是先总体设计，然后实现的同时考虑细节、异常、维护性等等
|
1 |
season4675Dec 11, 2019
8
40%思考，10%写代码，50%调试和解 bug
|
 |
IGJackloveDec 11, 2019
9
会先考虑逻辑可行性，觉得没问题就直接写。过于纠结时间比没什么意义吧
|
 |
LeonardDec 11, 2019
10
看你写什么东西，写简单逻辑或者 UI 的话只管上手就行了
|
 |
zuncengDec 11, 2019
11
实际开发中 项目越大 思考的占的比例越大 ， 主要原因是程序的主干框架变得更重要
前期主要是做抽象考虑程序的主干框架， 不考虑细节。 编码时处理细节也很重要 工业（生产）级别的代码 一般来说每个 error 都需要 handling， 这个需要查手册 局部的代码逻辑思考 必须在编码过程中处理的， 没必要一开始就想好。 |
 |
VegetableDec 11, 2019
12
思考实际上是在设计,不同人的岗位职责不同,设计需要的时间也肯定不一样.负责搭建架构的人肯定要想更多,按照接口文档撸 crud 自然就没什么可设计的,经验丰富的话就等于抄.
|
|
zuncengDec 11, 2019
13
对于一些依赖比较少的项目 比如 linux 内核，前期很多时间花在前期看论文查资料上， 编码时使用的其他模块 API 甚至 API 的报错对于开发者来说已经很熟悉了， 确实可以做到， 编码占很少时间。
对于现在一些应用开发， 处于一种 API 爆炸的阶段 一个应用可选择的第三方库，细节处理方式都很多， 对于开发者来说不熟悉就要花更多时间。 不用太在意 “应该用 80%的时间思考 + 20%的时间写代码” 这句话怎么适合自己适合团队就行 |
 |
fengbjhqsDec 11, 2019
14
要看复杂程度， 经验，
|
 |
cwjokakaDec 11, 2019
15
花少部分时间思考，先实现最基本的功能，测试，再优化
|
 |
sonxzjwDec 11, 2019
16
看情况，流水线不怎么需要脑子的，20%绰绰有余
设计的话，我基本要超过 50%进行思考设计 |
 |
weer0026Dec 11, 2019
17
思考比重肯定很大，但是我没思路了就会先写一会儿找找灵感。
|
 |
wlfengDec 11, 2019
18
先全部理清了再动手，中途发现问题再做调整
|
 |
qinyusenDec 11, 2019
19
90%的时间想清楚，然后写测试（测试即用例），然后 10%差不多就能写了，因为想清楚了，而且测试写完，不会有模糊不清的需求和功能，直接搬砖就行。。。10%时间很充足。
|
 |
zhujzDec 11, 2019
20
公司急着上线，根本没时间想怎么搞，基本是能实现功能就上了。
|
 |
gpra8764Dec 11, 2019
21
写底层至少要按这比例，堆 UI 差不多适当降低思考比例
|
 |
otakustayDec 11, 2019
22
思考大部分并不是在编程的时候的，比如吃饭时、蹲坑时、睡觉时、看动画时、玩游戏时、坐地铁时……所以真正编程的时候，思考绝对不会有 80%的比例的，太假了
|
 |
zhybb2010Dec 11, 2019
23
前后端一个人，运维架构一个人，纯思考占总项目时间的 30-%40%，coding 中思考占 coding 中的 70%。。。
|
 |
xxyangDec 11, 2019
24
看有没有复杂的逻辑，没有的话信手拈来
|
 |
imkuangDec 11, 2019
25
大部分时间花在思考怎么调试、修改上了
|
 |
INCerryDec 11, 2019
26
40%的时间和产品撕逼
|
|
INCerryDec 11, 2019
27
40%的时间和产品撕逼
30%的时间和对接方撕逼 20%的时间在试图理解别人的代码 2%的时间写代码 8%的时间在调试 |
 |
visonmeDec 11, 2019
28
曾经有过这样 80%思考（程前准备），20%编码， 那种感觉确实很爽（编码过程) ,而且效率确实很高，各种出错率都低了不少....
可现实中，这样的机会很少，大多数时候都是 10%思考，40%跟各类人群沟通 /确认 /等等 30%编码 20%修改 |
 |
good1uckDec 11, 2019
29
0s
|
 |
JamesRDec 12, 2019
30
20%写代码，50%测试修 Bug，30%思考。
|
 |
wangkun025Dec 12, 2019
31
我花 80%的时间胡思乱想
|
 |
charlie21Dec 12, 2019 via Android
32
主要是思考怎么和别人的垃圾代码对接。自己写 不用思考
|
 |
loadingDec 12, 2019 via Android
33
80，10，10
思考，ctrl c,ctrl v |
 |
drivebyDec 12, 2019
34
 ) |
 |
sikong31Dec 12, 2019
36
先快速实现一遍，摸清细节，再慢慢改。除非经验特别丰富，计划赶不上变化
|
 |
luvrootDec 12, 2019
37
90%在做别的事情，1%的时间在 一把梭子，拿起键盘就是干，9%的时间再被各种隐藏 bug 坑得死去活来。
|
 |
FlexGapDec 12, 2019
38
思考肯定是有的，但是就我个人来说，可能不会花 80%那么多。还有就是看项目，小项目一般就是草写之后不断迭代优化。
|
 |
zhanlanhuizhangDec 12, 2019
39
每次，思考的时间占用过多。造成后面天天加班，赶进度。
|
 |
lewinlanDec 12, 2019
40
大概 50%思考，50%编码+单元测试+整体测试解 bug
看项目难易度，如果是起一个新的模块，那思考的时间会多一点，相当于干了产品经理的活。如果是熟悉的或者相对健壮的模块增加功能，那思考时间就少很多。 |
 |
CantSeeDec 12, 2019
41
40-50%的时间来进行思考 10%开发,30%调试和优化,20%摸鱼
|
 |
jedihyDec 12, 2019
42
写 iOS 和前端的时候基本不思考，直接撸。基本不会推倒重来，因为就那么多东西。
|
Select Language