大致说来，有两种方式
1. 脑子里演算，甚至纸上草稿，整个流程搞定了，再码
2. 想一点码一点，不断DEBUG，直到搞定
我自己是第二种模式
1. 脑子里演算，甚至纸上草稿，整个流程搞定了，再码
2. 想一点码一点，不断DEBUG，直到搞定
我自己是第二种模式
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 4628 days ago, the information mentioned may be changed or developed.
 |
davepkxxxMar 2, 2014
1
看文档质量
|
 |
2
太复杂的就 MindNode 画个图. 不过一般我都是直接选 2, 先从独立性较强的模块出发, 然后再组织到一起, 先做一个最小可用原型.
|
1 |
pirexMar 2, 2014
3
看情况，一般的是2
|
 |
emricMar 2, 2014
4
觉得第一个很有必要.
最近遇到了很多推到从来的情况. |
 |
fftsMar 2, 2014
5
我感觉我现在越来越多的时候开始用第一种了
|
 |
onemooMar 2, 2014
6
一般都是第一种
所以我很喜欢身边放着纸和笔 |
 |
binuxMar 2, 2014
7
从没用过第二种，确定第二种码出来的代码能执行？
|
 |
wuyadongMar 2, 2014
8
第一种，基本不debug，打log就行吧。
|
 |
arbipherMar 2, 2014
9
我一般是先写dummy function，返回定值，
确保这个文件能跑起来 然后在一个一个实现。 |
 |
iosMar 2, 2014
10
我是业余程式员
第二种 |
 |
11
补充下，自己码自己想实现的代码时用的方式（产品设计，定好接口什么的不算进去）
|
 |
hustlzpMar 2, 2014
16
随心，第一种第二种都会用。
|
|
arbipherMar 2, 2014
17
@artwalk 那和我的也不一样啊。我每次run的时候，程序和功能看上去是“全”的
# step one - dummy # def init(): pass def handle(): pass def clean_up(): pass def main(): init(); handle(); clean_up(); # step two - implement init # def parseConfigFile(file): return STATIC_CONFIG def is_config_valid(config) return True def init(): config = load_config(CONFIG_FILE_NAME) if (!is_config_valid(config)): raise IOError |
 |
leofmlMar 2, 2014
18
先写注释, 再写代码.
|
|
arbipherMar 2, 2014
19
https://gist.github.com/arbipher/9308302
我要是再在回复框里写代码我就吃键盘。。。 |
 |
zorcetaMar 2, 2014
20
我是先1然后放弃转2……每每如此
|
 |
21
遇到比较乱的或者逻辑性比较强的都1
|
 |
digfireMar 2, 2014
22
新手时期用1，后来工作压力大了开始变成2
|
 |
otakustayMar 3, 2014
26
码得久了，就是边想边码基本没debug就出来了……
|
 |
iEverXMar 3, 2014
27
没写过大项目，一般都是脑袋里想了一下怎么把架子搭起来，然后就开始动手写， 边写边整理思路。。写到一个函数的具体实现的时候，就是完全的DEBUG了
|
 |
R4rvZ6agNVWr56V0Mar 3, 2014
28
先构思，然后分出大概的模块，然后再码模块接口、写过程代码，最后拼装<->重构
|
 |
cyberscorpioMar 3, 2014
29
一般都是混用的吧。
|
 |
tywtyw2002Mar 3, 2014 via iPhone
30
@arbipher 求视频验证。。。 吃hhkb吧
|
 |
powerfjMar 3, 2014
31
想一下，然后一次性把骨架都写好，然后不断debug，让程序跑起来，跑起来之后再填充东西，感觉流程是有点混乱..
|
 |
anjunechaMar 3, 2014
32
先是第二种，如果发觉有一些问题再循环到第一种
|
 |
Matrix24Mar 3, 2014
33
第2种，我是业余选手
|
|
34
@cyberscorpio 就是说更偏向哪一种；比如上来IDE就打开，码崩溃了实在不行了再草稿，还是草稿好了，脑子里运行通过了再码
|
|
35
@tywtyw2002 Σ( ￣д￣；) 你！！ 太残忍了。同求视频
|
 |
37
没有先写 user case 的吗
|
 |
viator42Mar 3, 2014
38
写一段运行一次,有问题就debug,正常运行的话写下一段,直到完成整个流程.这样可以保证写过的代码是没有问题的
|
 |
lixmMar 3, 2014
39
一般整体是1，局部是2
|
 |
ayang23Mar 3, 2014
40
先把最核心的功能用bpython调试实现了，再把这几十行代码变成几百行代码的类或者函数，加上变量预处理，防错之类的东西，当然这个时候大框架已经出来了。
|
 |
jianghu52Mar 3, 2014
41
我以前也是二。现在有点变化。都是先写函数名，或者接口名，把整个程序的流程给固定下来。然后再单个函数单个函数的写。
|
 |
yahonMar 3, 2014
42
我一般是这样的 比如我要写一个js的插件
1》大致的框架功能定义（实现这个插件大概要什么功能 尽量解耦） 2》具体实现（如果之前的定义有弊端，回头修改（1）） |
 |
vob636Mar 3, 2014
43
一般到一定地步的。基本上都是第二种了……
|
 |
chisjMar 3, 2014
44
第二种比较有乐趣。
|
 |
str0ngMar 3, 2014
45
看功能的复杂性，一般代码都是第二种，搭框架都是第一种
|
 |
railgunMar 3, 2014
46
2
|
 |
MikeAfcMar 3, 2014
47
身边留纸笔，必须走清流程，不然很容易返工
|
 |
lsbwahahaMar 3, 2014
48
不管业务简单复杂，脑子里过一下，然后根据复杂程度画个流程图，一般用yed ，xmind
|
 |
CrossinMar 3, 2014
49
个人喜欢用螺旋式，先大概纸上画个框架后，写出最简单的功能，然后不断往上添加功能，再不断修改设计。开发过程中想到什么新东西就记下来，再下个修改中加上去。
所以现在在公司写代码很不习惯，不喜欢一开始订好详细的计划，要做成什么样，花多少时间。 |
 |
jMar 3, 2014
50
独立工作时，绝大部分时候是在基于现成的代码结构做调整，不存在从零开始。
纸笔大部分是由于非独立工作需要和别人去沟通需求，返工往往是理解错误造成。 |
 |
TaivasMar 3, 2014
51
容易搞定的2，困难复杂的1
|
 |
ahtsiuMar 3, 2014
52
1+2 吧，动手写代码的前几天，可能是编译都编不过去的。
纸笔很必要。 |
 |
hu437Mar 3, 2014
53
这个主要就是设计文档，参照设计文档；
1、使用axure设计出界面原型； 2、考虑好交互流程和相关的处理逻辑； 3、设计好数据库结构 4、开始码 |
 |
RicepigMar 3, 2014
55
我一般首先是用手码，偶尔才用脚。。。
其实，也看是什么代码，如果不能引起思考的，那就直接写写试试。如果有点儿兴趣，有点儿挑战的就苦苦思索一下。 |
 |
mfanerMar 3, 2014
56
好像都差不多，大问题先分解成小问题，小问题不用怎么考虑挨着就往下写
|
 |
akinonikuMar 3, 2014
57
先写测试再写代码吧
|
 |
missdeerMar 4, 2014
58
流程比较复杂的1，其他的2
|
 |
tonitechMar 4, 2014
59
看复杂程度，如果你要写个hello world还用1吗？
|
 |
icylogicMar 4, 2014 via Android
60
分解问题到自己觉得一天能搞定的单元，然后每个单元用2。
|
Select Language