记得刚入行的时候，信手就写。 几千行代码。
现在举步维艰，感觉各种情况考虑。几十行代码。
做技术越做感觉 脑筋不够用。
This topic created in 3489 days ago, the information mentioned may be changed or developed.
 |
akiraApr 16, 2017
1
代码强健度不一样
|
 |
2
有经验后，写代码， 考虑的东西越来越多， 可能刚开始就考虑到性能问题。
其实有些东西可以以后 改进，进行重构，不需要 一次性过。 所以要 松弛有度， 有的地方严格，速度慢些 有的地方，就快些 更快，更高，更强吧 |
4 |
3
额，这样说明其实你知道的也许还不够多。
|
 |
lyhtsmApr 16, 2017 via Android
4
过阵子习惯套路了就又快起来了，我们公司有些老头子工程师就是这样…
|
 |
KhliebApr 16, 2017 via Android
5
找到窍门以后，感觉就会柳暗花明
|
 |
ImmortalApr 16, 2017
6
这也是进步的表现 但也不要走入误区 把自己绕进去
|
 |
NonClockworkChenApr 16, 2017
7
先写,再优化吧,没必要一步到位
|
 |
zgqqApr 16, 2017
8
我现在些代码也是很纠结
|
 |
21gramsApr 16, 2017
9
这是正常的，一天也就写个几十行代码。
|
 |
ntdllApr 16, 2017
13
作为入职没多久的新员工，目前的状态是知道的并不多，但是属于编程五分钟，扯淡两小时的情况。聊天聊着聊着 突然想到怎么写了，就敲键盘。敲不动了，继续聊天。直到下班。
|
 |
kanegApr 16, 2017 via iPhone
14
初生牛犊不怕虎。时间长了，经过磕磕碰碰，该踩的雷都踩一遍，就会深思熟虑，避免走弯路
|
 |
phrackApr 16, 2017
15
我觉得可能是想多了。
我有时也会遇到这个情况，要是进来的参数不正确我是不是要处理下，要是内存不够了我要不要释放一下，然而一旦遇到这种情况我就提醒自己，管 tmd ，先把业务逻辑撸完了再说， bug 本来就是用来修的。 |
 |
16
每天写几十行，其他的都是抄的。
|
 |
llb123Apr 16, 2017
17
鲁棒性高
|
 |
sagaxuApr 16, 2017 via Android
18
平均每天几十行 ，包括抄的在内，哈哈
|
 |
em70Apr 16, 2017 via Android
19
只有 100 用户的时候不要考虑一亿用户的问题
|
 |
bigpigeonApr 16, 2017
20
自从用 python 以来每天的代码量是越来越少，多则几十行，少则几行
|
 |
acrosApr 16, 2017
22
有一段时间好像是这样，感觉怎么写都不妥，好像写的 bug 数量比字节数还多····
大概就是从不知道自己不知道，到了知道自己不知道的程度。 |
 |
ddouApr 16, 2017
23
经历丰富后, 首先是不会再急着动手写代码了,会考虑比较多的选项,不同的场景. 这些想清楚后,就是下笔如有神了, 刷刷的, 拦都拦不住, 哈哈😄
|
 |
lococoApr 16, 2017
24
几行代码解决几千行的问题，多好，难道这还要自嘲？
|
|
KhliebApr 16, 2017 via Android
25
楼主需要一把金钥匙🔑
|
 |
27
应该都是这样吧，刚开始会什么写什么，想起什么写什么，但是遇到很多问题以后就记下了，下次再写东西就会花更多时间在如何事先避免这些问题上，比如什么性能、扩展性、结构等等，码代码的效率会有所低下，但是代码质量会往上提升，以前你可能时间都花在修 bug 上，现在花在优化代码上。加上确实懂的多想的多了就会懒了。编程五分钟，扯淡两小时，比如你看我现在就在这扯了一大段。
|
 |
linjianruApr 17, 2017
28
确实如此。不过逐渐也会豁然开朗进入下一阶段。
|
 |
ys0290Apr 17, 2017 via iPhone
29
这只是一个把书读厚的阶段
|
 |
douglas1997Apr 17, 2017 via iPhone
30
Make it work and then make it fast.
|
 |
smdxApr 17, 2017 via iPhone
31
极限编程号称敏捷开发，适用于企业级高复杂度，本来 3 个月得像项目一个星期出一个版本，之后在这个版本上不断迭代，形成最终版本 ，据说这种行项目更加成功
|
|
smdxApr 17, 2017 via iPhone
32
这种类型项目更加成功
|
 |
twoyuanApr 17, 2017
33
也有可能是知道的不多而想的太多 😂
|
|
smdxApr 17, 2017 via Android
34
@twoyuan 应该是不知道编程得真理，发散性思维想各种情况，其实你发散想得东西，早就在语言各种异常定义中安排好了得东西，你没发现程序任何异常，程序语言本身自己是知道得，因为已经定义好了，凡是不符合类库接口契约得都记录为异常
|
|
smdxApr 17, 2017 via Android
35
不是说不要发散性思维，发散性主要集中在业务逻辑缺陷方面，这是语言异常不能发现得
|
 |
kaishi123Apr 17, 2017
36
华罗庚说读书要先由厚到薄，再由薄到厚。跟楼主的感慨差不多一个意思吧。
|
 |
initialdpApr 17, 2017
37
大家都别装了， lz 只是老了。
|
 |
jatesunApr 17, 2017
38
一行顶百行，码农这个行业，以一当百很正常的事情
|
 |
RomanticlizhiApr 17, 2017
39
我觉得除开我抄的，一天也是几十行，哈哈哈哈。。。
|
 |
PharielApr 17, 2017 via Android
40
正常的 慢慢就信手拈来了
|
 |
JamesRuanApr 17, 2017
42
不应该看单每天增加的代码，而应该看每天删除的代码。
正常情况下每天增加的比删除的也就多那么几十行，很少超过 100 行。但是删除的也算上的话，正常情况 100-200 行是比较常见的。 |
 |
blackleeApr 17, 2017
43
Done is better than perfect.
按照楼主说的，以前很快，现在很慢，这种情况，基本不是因为想太多，而是因为想太少了。 我个人的独自项目，自己给自己提 issue ，自己在 issue 里更新当前的想法和问题解决思路。你可以看右侧的 issue 内更新数。另外的 activity 界面我就不贴了，经常先连着 3-4 个 comment ，然后再接着一堆的 commit 。  ) |
 |
wizardozApr 17, 2017
45
代码太精炼未必是好事。
|
 |
eyp82Apr 17, 2017
46
我觉得初期不需要考虑太多 corner cases, 只需要集中精力把主线流程实现出来. 然后通过高覆盖率的单元测试, 集成测试等去发现 corner cases 并增加处理.
一开始就纠结于各种异常情况, 反而偏离了重心, 导致很难建立起流畅的思路解决问题. |
 |
quickmaApr 17, 2017
47
没有银弹
|
 |
rozboApr 17, 2017
48
随着技术的增长，写几千行代码的这种工作自然要交给下面的人去做，自己只负责写出核心的几十行就可以了。
难道这不是资源的合理分配吗？ |
 |
garrychApr 17, 2017
49
非也！这只能说明你知道的还不够多。
知道多了写代码慢很正常，但是知道的足够多的时候，写代码就快了 |
 |
carlonelongApr 17, 2017
50
不要过度设计啦
|
 |
subpoApr 17, 2017
51
三重境界
看山是山，看山不是山，看山还是山 |
 |
bk201Apr 17, 2017
53
我这么觉得我新手时候才会考虑东考虑西，然后 1 天下来基本没写什么。后来基本上是先功能出来再优化。
|
 |
bluefalconjunApr 17, 2017
54
只做架构设计... 只画流程图 结构图... review 代码, 一天 comment 大概 10 个以内的 cl...
已经到了基本不写代码, 只有移植, 修改部分调用. |
 |
55
先梳理流程，封装业务模块，善于使用工具模块，分离关注点，就会发现需要关注的东西越来越少。
|
 |
moka20477Apr 17, 2017
56
过度设计
|
 |
lovejoyApr 17, 2017
57
我现在写代码都会考虑高并发会怎样，但是感觉想多了。
|
 |
10yearsApr 17, 2017
58
等到下个阶段就好了.
|
 |
monburanApr 17, 2017
59
原来写代码也不考虑性能，也不考虑效率，单线程上来就是干。
现在知道多线程了又去考虑消息队列，还要考虑代码写的规不规范，写注释了吗，别人能看懂吗。。。 |
 |
zacardApr 17, 2017
60
出的 bug 约少
|
 |
sammoApr 17, 2017
62
如果把工作分为“想”的部分和“写”的部分，一般先规划好了写起来很快的，边写边想 and 没写就已经想好了怎么写 还是不一样的
|
 |
antowaApr 18, 2017
64
考虑东西多了就会这样
|
 |
visonmeApr 20, 2017
65
随着知识的积累，这种情况也是很正常，所以越到后面开发的时间会越来越少，而思考的时间会越来越多。
|
Select Language