p**********e 发帖数: 316 | 1 想抛砖引玉,讨论一个话题
本人当码工也很久了,还在最底层,自己先鄙视一下先
本人完成任务时稍有点洁癖,方方面面基本都考虑到,所以bugs一般很少很少,然而在
一般的公司里,是没有所谓的按performance来review的,时间长了,因为你做的东西
不声不响,在很多人眼里你就是一个有亦无了, 想请教本版的前辈和晚辈,如何作合
理的控制能够产生一下bugs,又不过分。我想到的一些方面:
1) 不要指出BA的缺陷,要求什么做什么, 程序里面适当考虑到这些,留有余地, 这
样子来来往往就多了些
2) 很多能够出小错的地方不处理,比如一个data field, 如果不允许有null, 那么
加一个not null的constraint 就可以避免这类问题(或者问题发生了,马上就能知道
, 也不算什么问题了), 那么就有意的不设置这个constraint,出了问题,看看是
data的问题,就告诉user是data的问题,这样子来讲,问题解决了,又赚到了credits.
..
请不要问我怎么做到少产生bugs,我感觉是害人害己。 有多少程序是rocket science,
如果计算出一点错误,rocket就飞不上去了,我很希望看到这样子。 |
w********m 发帖数: 1137 | 2 2的话, 多用try catch。出错的时候,打出一堆log。
catch后,再改,这样就显示工作量了。 |
k****i 发帖数: 101 | 3 靠,人才,不在米国混真会屈才的。
:想抛砖引玉,讨论一个话题
: |
s*********y 发帖数: 6151 | 4 在工作中还是要灵活处理 不能任性让自己做无用功 完美主义常常会害了你
|
s*********y 发帖数: 6151 | 5 典型美国人的蠢逻辑 fast = smart 美国人心里没有慢工出细活这种古典财富
手快比精致重要
以上是我个人体会 |
p**********e 发帖数: 316 | 6 谢谢各位的回答,用try catch的那位,可能没有明白我说的意思,少用try catch也行
,但那也会害自己, 出了问题也要花时间解决, 这是印度人经常干的
完美主义,有点那个意思, 现在看看怎么能够不完美, 又无大碍
我是指在项目完成之后,再能够折腾一下, 这在有的公司是不允许的,出现的bug太多
,就得卷铺盖了, 但很多都是靠前面完成的东西做support,混日子
比如我前不久用了Merck的一个API, 那就叫一个烂,Merck, 名头还是挺响的吧,尽管
不是IT公司,但IT部门恐怕不小
【在 s*********y 的大作中提到】 : 在工作中还是要灵活处理 不能任性让自己做无用功 完美主义常常会害了你 :
|
a*****g 发帖数: 19398 | 7 都不用你折腾,自然会产生的。
【在 p**********e 的大作中提到】 : 想抛砖引玉,讨论一个话题 : 本人当码工也很久了,还在最底层,自己先鄙视一下先 : 本人完成任务时稍有点洁癖,方方面面基本都考虑到,所以bugs一般很少很少,然而在 : 一般的公司里,是没有所谓的按performance来review的,时间长了,因为你做的东西 : 不声不响,在很多人眼里你就是一个有亦无了, 想请教本版的前辈和晚辈,如何作合 : 理的控制能够产生一下bugs,又不过分。我想到的一些方面: : 1) 不要指出BA的缺陷,要求什么做什么, 程序里面适当考虑到这些,留有余地, 这 : 样子来来往往就多了些 : 2) 很多能够出小错的地方不处理,比如一个data field, 如果不允许有null, 那么 : 加一个not null的constraint 就可以避免这类问题(或者问题发生了,马上就能知道
|
d****n 发帖数: 1637 | 8 这个最逗
【在 w********m 的大作中提到】 : 2的话, 多用try catch。出错的时候,打出一堆log。 : catch后,再改,这样就显示工作量了。
|
m*****n 发帖数: 3575 | 9 为什么米国人会这么想?
资源充裕所以不怕浪费?
【在 s*********y 的大作中提到】 : 典型美国人的蠢逻辑 fast = smart 美国人心里没有慢工出细活这种古典财富 : 手快比精致重要 : 以上是我个人体会
|
s*********y 发帖数: 6151 | 10 民族性格 殖民主义 大农村 大机器工业 糙快猛习惯了 天生不注重细节
【在 m*****n 的大作中提到】 : 为什么米国人会这么想? : 资源充裕所以不怕浪费? : :
|
|
|
c******n 发帖数: 16666 | 11 做需求分析的时候 别想太多 想太远 满足最基本需求就行了 这条和你说的1差不多
以后发现有遗漏的 问题必然不在你 你迅速改改就成了加feature
适当模块化 别太抽象 如果有大的变动 名正言顺refactoring
【在 p**********e 的大作中提到】 : 想抛砖引玉,讨论一个话题 : 本人当码工也很久了,还在最底层,自己先鄙视一下先 : 本人完成任务时稍有点洁癖,方方面面基本都考虑到,所以bugs一般很少很少,然而在 : 一般的公司里,是没有所谓的按performance来review的,时间长了,因为你做的东西 : 不声不响,在很多人眼里你就是一个有亦无了, 想请教本版的前辈和晚辈,如何作合 : 理的控制能够产生一下bugs,又不过分。我想到的一些方面: : 1) 不要指出BA的缺陷,要求什么做什么, 程序里面适当考虑到这些,留有余地, 这 : 样子来来往往就多了些 : 2) 很多能够出小错的地方不处理,比如一个data field, 如果不允许有null, 那么 : 加一个not null的constraint 就可以避免这类问题(或者问题发生了,马上就能知道
|
c******n 发帖数: 16666 | 12 还有别盯着bug,改进performance也是可以拿credit的
至于怎么拖慢performance 这简直太容易了吧
此外,有些时候自己造轮子 有些时候用别人的轮子 然后别人轮子更新了 或者潮流变了
按着人release note整个列表 下次开会一说 又有活干了
当然现实中我这些都没试过 总是被各种p事忙得到处转
另一方面平时多刷刷reddit hackernews什么的 积累了一定的buzzwords我就去找人聊
天了
可能还是看做的类型吧 如果是ERP这种估计几年都不转一个弯的
但我这边做web app这种周转挺快的
我忽悠一阵一般有活就给我 没活人下次有机会也容易想到我 他们拿着我的忽悠材料
也容易出去忽悠别人不是? |
w*****g 发帖数: 1415 | |
p**********e 发帖数: 316 | 14 是这样子, 谢谢
【在 c******n 的大作中提到】 : 做需求分析的时候 别想太多 想太远 满足最基本需求就行了 这条和你说的1差不多 : 以后发现有遗漏的 问题必然不在你 你迅速改改就成了加feature : 适当模块化 别太抽象 如果有大的变动 名正言顺refactoring
|
p**********e 发帖数: 316 | 15 performance稍有保留,很多情况下也没人care, 除非真的发生了
但是也不用再performance上多花功夫,也是无用功
小问题越多,可能越有credit
别人出问题越多,如果确实是你能解决或者老板只相信你能解决,你越有价值
变了
【在 c******n 的大作中提到】 : 还有别盯着bug,改进performance也是可以拿credit的 : 至于怎么拖慢performance 这简直太容易了吧 : 此外,有些时候自己造轮子 有些时候用别人的轮子 然后别人轮子更新了 或者潮流变了 : 按着人release note整个列表 下次开会一说 又有活干了 : 当然现实中我这些都没试过 总是被各种p事忙得到处转 : 另一方面平时多刷刷reddit hackernews什么的 积累了一定的buzzwords我就去找人聊 : 天了 : 可能还是看做的类型吧 如果是ERP这种估计几年都不转一个弯的 : 但我这边做web app这种周转挺快的 : 我忽悠一阵一般有活就给我 没活人下次有机会也容易想到我 他们拿着我的忽悠材料
|
N*****r 发帖数: 94 | 16 这个问题的确挺重要的
我来说几点吧
第一, 要混淆逻辑, 绝对不能在程序里把业务逻辑写的太明白了,你写太明白了,别
人一看就看懂了,然后就不需要你了, 因此大量的诸如 a b c d last first one
two threee 之类的变量名是要用的, 写 case 的地方可以写成七层嵌套的 if, 最终
还要来个 break , 然后 goto
第二, 要降低运行速度, 就是前面人说的想法埋性能炸弹,争取一开始的性能非常差
,勉强能用, 然后如果有人提出批评, 就说working on it, optimization takes
time, 然后隔三差五的发布个新版, claim 用了什么新技术,速度提高了50%。内存节
约....(一开始在程序里放个不优化的递归算个斐波那契之类的,又耗内存又降速度,
非常好用,别被人看出来,想提高性能每次把要算的项数减一,大概就能提高50%性能)
第三,要经常讲自己的工作,重要性啊,用了什么新技术啊,做了多少技术储备啊,留
了多少API接口给未来的人工智能应用啊。。。什么高大上就怎么来
第四,people's skill, i have helped XXX on this this this ,, he didnt
noticed this this this .... 老板英明 啥的
先这四点,回头补充
【在 p**********e 的大作中提到】 : 想抛砖引玉,讨论一个话题 : 本人当码工也很久了,还在最底层,自己先鄙视一下先 : 本人完成任务时稍有点洁癖,方方面面基本都考虑到,所以bugs一般很少很少,然而在 : 一般的公司里,是没有所谓的按performance来review的,时间长了,因为你做的东西 : 不声不响,在很多人眼里你就是一个有亦无了, 想请教本版的前辈和晚辈,如何作合 : 理的控制能够产生一下bugs,又不过分。我想到的一些方面: : 1) 不要指出BA的缺陷,要求什么做什么, 程序里面适当考虑到这些,留有余地, 这 : 样子来来往往就多了些 : 2) 很多能够出小错的地方不处理,比如一个data field, 如果不允许有null, 那么 : 加一个not null的constraint 就可以避免这类问题(或者问题发生了,马上就能知道
|
N*****r 发帖数: 94 | 17 有一点特别重要
能用c++ 尽量用 c++ 什么 generic template 算符重载 让人看着觉得头疼的东西全部
用上,就是争取程序在能跑的同时没有人看的懂
java这点上对程序员极度不友好,就算有混淆, 反编译之后的代码照样很干净,是个
人就能看个差不多 |
m*****n 发帖数: 3575 | 18 how about python?
【在 N*****r 的大作中提到】 : 有一点特别重要 : 能用c++ 尽量用 c++ 什么 generic template 算符重载 让人看着觉得头疼的东西全部 : 用上,就是争取程序在能跑的同时没有人看的懂 : java这点上对程序员极度不友好,就算有混淆, 反编译之后的代码照样很干净,是个 : 人就能看个差不多
|
n*********2 发帖数: 357 | 19 > python也可以写得很难懂
同意这个。 下面这个就是一个例子。 版上那个大侠看看这个程序是干啥的?
不过写这玩意很伤神。 |
t****b 发帖数: 2484 | 20 我就问一句,楼主和楼上各位公司连版本控制和code review都没有吗?
哪段代码出了bug直接找对应的人修,这还能产生 credit? |
|
|
c******n 发帖数: 16666 | 21 所以我强调如果要这么做的话
1. 需求分析别走太深 (这其实本身就个大坑)
2. 追新
这2个将来要改都不是bug,是feature,即便是开issue,也是要tag成feature request
【在 t****b 的大作中提到】 : 我就问一句,楼主和楼上各位公司连版本控制和code review都没有吗? : 哪段代码出了bug直接找对应的人修,这还能产生 credit?
|
w********m 发帖数: 1137 | 22 考评要看 增删改的代码数。
一次性optimal, bug free很吃亏呀
【在 t****b 的大作中提到】 : 我就问一句,楼主和楼上各位公司连版本控制和code review都没有吗? : 哪段代码出了bug直接找对应的人修,这还能产生 credit?
|
t****b 发帖数: 2484 | 23 peer review的时候别人都说楼主加个feature加不利索 反反复复一直改 代码数多也不
行啊
【在 w********m 的大作中提到】 : 考评要看 增删改的代码数。 : 一次性optimal, bug free很吃亏呀
|
p**********e 发帖数: 316 | 24 这个有点歪题了, 我们谈论与具体用什么语言关系不大。
【在 m*****n 的大作中提到】 : how about python?
|
p**********e 发帖数: 316 | 25 第一,取决于组的状况, 比如大家都是高手的话,玩的花招也不太起作用,确实接手
过印度人的东西,不是看不懂,而是让你不想看, 比如一个很长 if statement
第二, 我的理解是不能做的太完善,这样子也会拖拖拉拉一阵子, 但要把握好度,
比如我老板,知道了也可能不说你,我们有一部分包给印度公司,他就私下说过一个东
西,拖了太长时间,不太make sense, 但他也没有直接讲,很注意礼貌的。但如何将一
个问题具体拆解, 适当的汇报进度,确实有很大的学问, 可以继续展开讨论
第三第四,很好, 希望能接着讨论, 怎么说些废话,也很重要, 让别人意识到你的存
在!
大家尽量少带着个人的情绪和主观来看问题,或者说的详细点, 一份工作好与坏,自
己干的开心与否, 与自己的能力,与人相处的能力,公司的大环境, 所在的组, 老
板的为人和领导风格都有极大的关系的
,
【在 N*****r 的大作中提到】 : 这个问题的确挺重要的 : 我来说几点吧 : 第一, 要混淆逻辑, 绝对不能在程序里把业务逻辑写的太明白了,你写太明白了,别 : 人一看就看懂了,然后就不需要你了, 因此大量的诸如 a b c d last first one : two threee 之类的变量名是要用的, 写 case 的地方可以写成七层嵌套的 if, 最终 : 还要来个 break , 然后 goto : 第二, 要降低运行速度, 就是前面人说的想法埋性能炸弹,争取一开始的性能非常差 : ,勉强能用, 然后如果有人提出批评, 就说working on it, optimization takes : time, 然后隔三差五的发布个新版, claim 用了什么新技术,速度提高了50%。内存节 : 约....(一开始在程序里放个不优化的递归算个斐波那契之类的,又耗内存又降速度,
|
p**********e 发帖数: 316 | 26 如果别人的水平不差,可能也会搞懂
如果有烂人接手你的工作,他会不停的烦你, 出了问题,还说不定赖扣在你头上
这种技术可能在某些情况下也可play一下
【在 n*********2 的大作中提到】 : > python也可以写得很难懂 : 同意这个。 下面这个就是一个例子。 版上那个大侠看看这个程序是干啥的? : 不过写这玩意很伤神。
|