这是一个创建于 3799 天前的主题，其中的信息可能已经有所发展或是发生改变。
我原本以为写代码就像电影中的黑客一样，噼里啪啦噼里啪啦，代码就写完了，接着修改错误和 bug 就成，但我发现实际上根本就不像那样啊，每写完一个函数，我就会停下来重新看一遍是否有什么不对的地方，有错误就修改，在一个函数里涉及到变量或者算法的写好后也会停下来重新检查一遍，这样感觉速度有点慢。
有时候就算写好伪代码，再写正式代码在某些地方也会停下来思考下一步该怎么写，总之不可能连贯的写完一个完整的程序，是我太 low 了吗
还有，你们在写 c ， python 之类的程序时，明知道某一行代码会出错，也不去修改，非要运行一遍，让程序报错才去修改，如果有两个错误，只修改第一个，然后再运行一遍，才去改第二个错误，这是病，得治吗
有时候就算写好伪代码，再写正式代码在某些地方也会停下来思考下一步该怎么写，总之不可能连贯的写完一个完整的程序，是我太 low 了吗
还有，你们在写 c ， python 之类的程序时，明知道某一行代码会出错，也不去修改，非要运行一遍，让程序报错才去修改，如果有两个错误，只修改第一个，然后再运行一遍，才去改第二个错误，这是病，得治吗
第 1 条附言 2015 年 12 月 1 日
看来第二个问题的确得治了，至于第一个问题大家都有，原来写代码真的不是像电影中那样
 | 1 dorentus 2015 年 11 月 30 日 via iPhone 换个非常慢的电脑用几天，就能治好了 |
 | 2 harry890829 2015 年 11 月 30 日 @dorentus 哈哈，这个办法好，能治 楼主说的这个问题，还是写的项目小，编译运行一下子就完成了，要是一个项目光编译就要几分钟，上个厕所什么的，你试试？我们项目里加测试日志，初期经常少加，编译等几分钟，运行起来再触发到测试的函数又是几分钟，分析一下日志，发现我擦，刚才加的日志没有用，少加了，后来我们都是宁可多加不少加，等测试完全删了就好 |
 | 3 lxrmido 2015 年 11 月 30 日 一开始是写完整个程序再开始调试、修改； 后来是写一个函数调试一下，写几行停一下思考一下； 现在是写到觉得累了才站起来开始调试…… |
 | 4 wolfan 2015 年 11 月 30 日 不用换机器，把内存换成 1G 的试试也能治好~ |
 | 5 azhao 2015 年 11 月 30 日 不用治,这是 bugs 先行的编程方法,测试先行的姐妹 |
 | 6 4everLoveU 2015 年 11 月 30 日 用键盘写 |
 | 8 starz 2015 年 11 月 30 日 产生 bug ，然后解决 bug 才会更有成就感吧~ |
 | 9 imn1 2015 年 11 月 30 日 1L 说得好，测试其实不能少了低端电脑，总是拿台 i7 8 核来测，项目上线会很惨 |
 | 10 Halry 2015 年 11 月 30 日 via Android 都是这样吧，不可能一下子就写好的，除非你写 hello world |
 | 11 wolffn 2015 年 11 月 30 日 lz 这是刚开始搬砖没几天，时间久了就习惯了 |
 | 12 zhujinliang 2015 年 11 月 30 日 via iPhone 来搞个单片机什么的，标称擦写寿命 1 千次而且价格不便宜的那种，每调试一次都是钱 |
 | 13 acros 2015 年 11 月 30 日 via iPhone 写得太少吧。 我一般是先思考写完后是什么样的，然后开始噼里啪啦写，当然中间会碰到意外（但不会写一两个函数就卡着），再停下来思考，再噼里啪啦.... 最后运行，出来 compile 信息再改呗 |
 | 14 k9982874 2015 年 11 月 30 日 via iPhone ctrl + c ctrl + v |
 | 15 Livisme 2015 年 11 月 30 日 via iPhone 上大学的时候一定要边听歌边写码，不过毕了业以后就完全远离编程了，看都看不懂了，包括我的毕设。 |
 | 16 Linxing 2015 年 11 月 30 日 歪楼求问：那敲代码经常敲错字母也是病吗？ |
 | 17 hqs123 2015 年 11 月 30 日 用手写，偶尔 CV (ctrl+c,ctrl+v)编程。 |
 | 18 Librazy 2015 年 11 月 30 日 via Android 最近 C 写的多，也都是模块里的小函数，就单独开一个文件写这个函数，在小文件写完调通后再复制回项目里，名曰：手动单元测试 |
 | 19 womaomao 2015 年 11 月 30 日 1. 先把接口都写好，实现可以留着，必要时可以打 log 。 2. 跑一把，解决错误，那么大框架是 ok 了。 3. 按模块，把实现填好，编译调试 ok ，该模块差不多了。 4. 重复 3 ，慢慢的都出来了。 如果需要 UT ，可以尝试 2 ， 3 结合用 TDD 。 |
 | 20 monnand 2015 年 11 月 30 日 via Android 先写单元测试规定功能，因为功能没实现，所以肯定跑不过。然后实现这个功能直到单元测试都通过。中间可能会修改或者补充单元测试。记得，少写一个单元测试，就是你欠的一个债，等到之后写新版本或者改 bug 的时候你必须要带着利息还的。 |
 | 21 i1173081 2015 年 11 月 30 日 坐着写 |
 | 22 njutree 2015 年 11 月 30 日 个人觉得很功力有很大关系，平时多看别人写的好的代码，多 review 代码，水平就会有很大提升的；还有就是写代码的时候要专注，这样才不会丢三拉四，出现低级的 bug 。另外尽量多用眼睛和大脑去发现错误而不是，编译器去试错也会很大程度写代码的效率。 |
 | 23 SpicyCat 2015 年 11 月 30 日 @harry890829 编译慢的话，就需要 CI 了，不要本地跑测试。 |
| 24 SpicyCat 2015 年 11 月 30 日 刚开始写就当伪代码写，把思路理清后，把代码改成可以运行的状态，然后就是各种 CI 测试交付。 代码都是改出来的。 |
Select Language