p*****3
发帖数: 488 | 1 想写一点点意见，但是怕被版上大牛们鄙视，怎么办？ |
s***o
发帖数: 2191 | 2 2x鄙视回去就是了。
捎带问一下 - amazon senior level的位置是不是也要问一大堆算法？amazon prime这
个组是干什么的？lz知道吗？
【在 p*****3 的大作中提到】
: 想写一点点意见，但是怕被版上大牛们鄙视，怎么办？
|
p*****3
发帖数: 488 | 3
问问gate吧
【在 s***o 的大作中提到】
: 2x鄙视回去就是了。
: 捎带问一下 - amazon senior level的位置是不是也要问一大堆算法？amazon prime这
: 个组是干什么的？lz知道吗？
|
p*****2
发帖数: 21240 | 4 绝对有用呀。我现在都不怎么写test case，可是很少出bug，不就是这么练出来的？而
且程序结构漂亮也是少bug的一个主要原因。 |
p*****3
发帖数: 488 | 5
我们这非逼着写unit test和integration test。倒不是说这两种test没有用，但是搞
的有时候test code比production code还多就麻烦了。每次改点程序，refactoring一
下还得改test code. Integration test啥的还得每次想破头去call各种api创建环境然
后再verify,也不知道值不值得。
【在 p*****2 的大作中提到】
: 绝对有用呀。我现在都不怎么写test case，可是很少出bug，不就是这么练出来的？而
: 且程序结构漂亮也是少bug的一个主要原因。
|
z****e
发帖数: 54598 | 6 这不就是大公司和小公司的区别
小公司无非那几个人，自己看懂就好了，但是大公司
上头要尽量让你的代码能被其它人接受，比如refactor
amazon已经过了startup阶段，掌舵的要把船开稳
差别就好比驾驶民航客机和战斗机的差别一样
战斗机飞行员一般被认为不适合当民航客机飞行员
因为倾向于做一些高风险的动作
【在 p*****3 的大作中提到】
:
: 我们这非逼着写unit test和integration test。倒不是说这两种test没有用，但是搞
: 的有时候test code比production code还多就麻烦了。每次改点程序，refactoring一
: 下还得改test code. Integration test啥的还得每次想破头去call各种api创建环境然
: 后再verify,也不知道值不值得。
|
p*****3
发帖数: 488 | 7
就是，一点都不爽，我有时就纳闷了，那么明显的几行code,有啥好写unit test的，这
点逻辑都整不清楚。少写几个test case还不让过code review。
我觉得值得写的就是逻辑非常复杂的函数测试输入输出，还有就是模拟distributed
system下的各种异常，看逻辑是否正确。
【在 z****e 的大作中提到】
: 这不就是大公司和小公司的区别
: 小公司无非那几个人，自己看懂就好了，但是大公司
: 上头要尽量让你的代码能被其它人接受，比如refactor
: amazon已经过了startup阶段，掌舵的要把船开稳
: 差别就好比驾驶民航客机和战斗机的差别一样
: 战斗机飞行员一般被认为不适合当民航客机飞行员
: 因为倾向于做一些高风险的动作
|
z****e
发帖数: 54598 | 8 等你做到gate的位置之后，你就知道让手下人这么做的好处了
就好比操练步兵，没几个兵愿意绕着操场一遍一遍滴跑的
它们觉得打战只要会抠扳机就行了
【在 p*****3 的大作中提到】
:
: 就是，一点都不爽，我有时就纳闷了，那么明显的几行code,有啥好写unit test的，这
: 点逻辑都整不清楚。少写几个test case还不让过code review。
: 我觉得值得写的就是逻辑非常复杂的函数测试输入输出，还有就是模拟distributed
: system下的各种异常，看逻辑是否正确。
|
w**z
发帖数: 8232 | 9 这个没有标准，看经验了。小公司自己掌握。 大公司一般有规定， 以前公司是100%
class， 90% method, 80%line 最痛苦的是 cover exception handling code.
【在 p*****3 的大作中提到】
:
: 就是，一点都不爽，我有时就纳闷了，那么明显的几行code,有啥好写unit test的，这
: 点逻辑都整不清楚。少写几个test case还不让过code review。
: 我觉得值得写的就是逻辑非常复杂的函数测试输入输出，还有就是模拟distributed
: system下的各种异常，看逻辑是否正确。
|
z****e
发帖数: 54598 | 10 aws的架构可能是你这辈子见过最好的架构
超过google，超过fb这些
可能你会觉得很复杂，但是其它大公司的系统只会远比aws更复杂
现在只把aws的架构作为soa的经典内容往教科书里搬
然后教育学生怎么倒腾cloud，还有一点netflix
其它公司cloud以后的构架一概都不说
google贡献的是搜索理论，而不是具体的系统架构的实现
fb贡献了一堆开源的，对理论帮助很小 |
|
|
L*******r
发帖数: 119 | 11 三爷，如果您之前帖子里说的过去几个月捅过的娄子是真的，而不是开玩笑的话，那我
觉得您还真是要多写点test太少。。。TDD还是有好处的，尤其是legacy system，没
unit test,上去就是个死。
不过也许你只是逗大家玩，呵呵。
【在 p*****3 的大作中提到】
:
: 就是，一点都不爽，我有时就纳闷了，那么明显的几行code,有啥好写unit test的，这
: 点逻辑都整不清楚。少写几个test case还不让过code review。
: 我觉得值得写的就是逻辑非常复杂的函数测试输入输出，还有就是模拟distributed
: system下的各种异常，看逻辑是否正确。
|
z****e
发帖数: 54598 | 12 现在一上课，铺天盖地滴aws和netflix
其它公司，比如fb，一说，哎呀，这个是social website的代表
然后呢？没有了，甚少有人把fb，google这些内部构架拿出来当教材说
但是动不动就拿aws出来当经典实践范例的很多
姐夫是一个很有天赋的构架师，这点要学习
amazon能把ibm踩在脚下，这个不是什么阿猫阿狗公司都能做到的
所以现在不少公司都喜欢去amazon挖人
因为amazon出来的人，它对那种team work有种本能的感觉
其实我看jobhunting就可以看出差别来
其它公司的人都会说，这个东西效率多高，跑多快
但是在amazon呆过的人会说，两个不同组之间通信如果没有协议，不可想象
这就是差别，我要是老板，我也去amazon挖人 |
z****e
发帖数: 54598 | 13 没有test case的legacy code看构架，构架又烂又没有各种资源包括test cases的
就是屎坑一个，快跑
【在 L*******r 的大作中提到】
: 三爷，如果您之前帖子里说的过去几个月捅过的娄子是真的，而不是开玩笑的话，那我
: 觉得您还真是要多写点test太少。。。TDD还是有好处的，尤其是legacy system，没
: unit test,上去就是个死。
: 不过也许你只是逗大家玩，呵呵。
|
p*****3
发帖数: 488 | 14
其实写的大多数是心得，要说捅篓子还不至于，顶多就是order pending那个，但那个
其实是同事错改了parent env的配置，那个bug也不是我引入的，我只是trigger了。
Query plan更多是DBA那边的问题。主要就是business logic太复杂，很多时候还得知
道其他组的impact，impact还跳了好几个hop，得知道其他组的vision，这个不是很快
能弄清楚的。
我的test case其实是写的最多的了，我觉得是性价比的问题，其实也很难说，有些5,6
年的service真该重写。
【在 L*******r 的大作中提到】
: 三爷，如果您之前帖子里说的过去几个月捅过的娄子是真的，而不是开玩笑的话，那我
: 觉得您还真是要多写点test太少。。。TDD还是有好处的，尤其是legacy system，没
: unit test,上去就是个死。
: 不过也许你只是逗大家玩，呵呵。
|
p*****3
发帖数: 488 | 15 还有本帖谢绝转载，我发在java版不喜欢转到其他版上去 |
p*****3
发帖数: 488 | 16 从效率的角度来看我觉得有这么几个stage
requirement --> design，选方案 --> code --> test
越往后分量越轻。公司面算法和coding其实可以保证产出的code的质量，至少logic
bug会少，代码容易懂。如果能一次写准甚至都不需要很高的debug的能力，这个我觉得
很重要啊。还一个是写的快，能在短时间产出高质量，bug少的代码，这点internet公
司比较需要。但是算法面试也就能做到这了，ACM选手可能都不一定知道怎么高效测试
自己的程序，特别是在legacy code上加或修改的时候好的test肯定是必要的。还有一
个就是测试环境是受到限制，什么时候做个简单unit test cover一下，啥时候在
eclipse上做个简单的integration test, 啥时候在local box上测试个啥，啥时候在
Devo上测个啥，各个阶段可以cover个啥，还是有些讲究。
有的面试可能问到design上，但是那种一上来就问什么facebook status update
design的我觉得也没啥太大意思。Design技术工具选的不对coding的在快，再漂亮都没
用。还有一个方面是OOD，就是一些common sense的design或错误考虑的design,考这些
比一上来设计一个Google search啥的实际多了。
Requirement, 这个最重要，感觉和design结合很紧密，这个错了毫无效率可言。
如果做个假设，一个人在准确了解了需求和有基本的design skill情况下直接能写出大
量无bug代码，这样可以跳过各种test cases的编写，跳过各种code review, devo测试
直接checkin到production下那效率得有多高啊。估计mitbbs只有二爷能做到了。 |
z****e
发帖数: 54598 | 17
【在 p*****3 的大作中提到】
: 从效率的角度来看我觉得有这么几个stage
: requirement --> design，选方案 --> code --> test
: 越往后分量越轻。公司面算法和coding其实可以保证产出的code的质量，至少logic
: bug会少，代码容易懂。如果能一次写准甚至都不需要很高的debug的能力，这个我觉得
: 很重要啊。还一个是写的快，能在短时间产出高质量，bug少的代码，这点internet公
: 司比较需要。但是算法面试也就能做到这了，ACM选手可能都不一定知道怎么高效测试
: 自己的程序，特别是在legacy code上加或修改的时候好的test肯定是必要的。还有一
: 个就是测试环境是受到限制，什么时候做个简单unit test cover一下，啥时候在
: eclipse上做个简单的integration test, 啥时候在local box上测试个啥，啥时候在
: Devo上测个啥，各个阶段可以cover个啥，还是有些讲究。
|
z****e
发帖数: 54598 | 18 其实这些问题就是软件工程的经典问题
做过大项目的人都知道，需求分析阶段一定要放大力气投入
否则这个地方如果出现了什么问题，后面对于项目成败是决定性的
相比之下，编码开发阶段的重要性，其实是相当低的，就比测试高一点
一个人写不出来，两个人三个人给我上，加班加点给我上
都没有问题，怕就怕，需求分析给我搞错了，设计就错了
那乖乖，你后面怎么改，都是空的，因为改下去，伤筋动骨
这就是维护成本的问题，最后项目失败的主因普遍都是维护成本高居不下
重构代码是很幸福的一件事，谁都想做，但是实际上，大多数公司不愿意你做
因为business理解不了，为什么我需要投入资源去做一个已经搞定了的东西？
他们不会承认之前做的人写的代码的烂，那样等于承认自己的无能
但是实际上大多数项目的代码，其实是很糟糕的，这个糟糕不是说算法怎样
是设计根本就是错的，没有层次感，几千行代码凑在一起一个类，wtf
聪明人看到这种代码之后，基本上就琢磨着跑路了
所以愿意去refactor代码的公司是好公司
愿意给员工时间去做各种核心编码以外的事的上司是好上司
不过这些老公司用这些破烂也有好处，给了新公司以发展的余地
新公司可以通过结构化合理的代码，以实现比老公司更为有效率的开发和维护
这样就可以在市场上占得先机，然后优胜劣汰 |
z****e
发帖数: 54598 | 19 所谓的design，核心思想就是一个
分层
模块化，尽可能降低耦合，然后提高内聚，这也是软件工程的基本概念
这就是一个oop出来的人的本能
它本能地会去实现封装，那么封装后的代码要实现分层
其实是很容易的一件事，但是其他的，不那么容易
分层实现了之后，剩下的其实就是体力活
写代码很多时候就是一体力活 |
g**e
发帖数: 6127 | 20 cant agree more。我常说，一个project里面写代码的重要性最多占25%。没有清晰的
需求分析和好的设计注定最后就是烂摊子。
【在 z****e 的大作中提到】
: 其实这些问题就是软件工程的经典问题
: 做过大项目的人都知道，需求分析阶段一定要放大力气投入
: 否则这个地方如果出现了什么问题，后面对于项目成败是决定性的
: 相比之下，编码开发阶段的重要性，其实是相当低的，就比测试高一点
: 一个人写不出来，两个人三个人给我上，加班加点给我上
: 都没有问题，怕就怕，需求分析给我搞错了，设计就错了
: 那乖乖，你后面怎么改，都是空的，因为改下去，伤筋动骨
: 这就是维护成本的问题，最后项目失败的主因普遍都是维护成本高居不下
: 重构代码是很幸福的一件事，谁都想做，但是实际上，大多数公司不愿意你做
: 因为business理解不了，为什么我需要投入资源去做一个已经搞定了的东西？
|
|
|
p*****2
发帖数: 21240 | |
g**e
发帖数: 6127 | 22 需求经常改倒是真的。不牛气，但是要让所有人都明白用户要什么，我们答应做什么，
让大家都在同一个页面上很重要。project进行过程中不断反馈和确认我们做的跟你要
的是一回事。需求分析里面还有一个重要的步骤是success measurement, 做完了没人
用也不是成功的项目。
这里面更多的是跟人打交道的过程，比写代码烦多了。
【在 p*****2 的大作中提到】
: 大家都太看中需求了。其实需求没有那么牛气。
|
p*****2
发帖数: 21240 | 23
还是看项目呀。需求经常改，动态语言的优势就出来了。很多时候都是engineer能证明
一个项目有用，然后上边才会给资源继续进行下去，这也就是所谓的engineer driven
。
【在 g**e 的大作中提到】
: 需求经常改倒是真的。不牛气，但是要让所有人都明白用户要什么，我们答应做什么，
: 让大家都在同一个页面上很重要。project进行过程中不断反馈和确认我们做的跟你要
: 的是一回事。需求分析里面还有一个重要的步骤是success measurement, 做完了没人
: 用也不是成功的项目。
: 这里面更多的是跟人打交道的过程，比写代码烦多了。
|
g*****g
发帖数: 34805 | 24 It's about defense against change. While it's relatively easy to code
without bug in first release when the design is fresh in your mind. Several
months or
years later there may come a business requirement that needs change on a
function. And it may not even be you who's doing it. Now, while the new
committer knows what he's doing and he tests the new use case carefully. He
doesn't know as well all the old use cases, it's even worse when he has to
change a few functions/classes as a whole. Unit tests and integration tests
can't cover it all, but at least minimize the impact here.
The cost of bug goes up exponentially when it's in production. If the code
is going to be used for years, it's well worth it.
【在 p*****3 的大作中提到】
: 从效率的角度来看我觉得有这么几个stage
: requirement --> design，选方案 --> code --> test
: 越往后分量越轻。公司面算法和coding其实可以保证产出的code的质量，至少logic
: bug会少，代码容易懂。如果能一次写准甚至都不需要很高的debug的能力，这个我觉得
: 很重要啊。还一个是写的快，能在短时间产出高质量，bug少的代码，这点internet公
: 司比较需要。但是算法面试也就能做到这了，ACM选手可能都不一定知道怎么高效测试
: 自己的程序，特别是在legacy code上加或修改的时候好的test肯定是必要的。还有一
: 个就是测试环境是受到限制，什么时候做个简单unit test cover一下，啥时候在
: eclipse上做个简单的integration test, 啥时候在local box上测试个啥，啥时候在
: Devo上测个啥，各个阶段可以cover个啥，还是有些讲究。
|
p*****2
发帖数: 21240 | 25
Several
He
tests
大牛怎么看SDE和SDET的关系的？你说的这个如果用SDET是不是可以解决？
【在 g*****g 的大作中提到】
: It's about defense against change. While it's relatively easy to code
: without bug in first release when the design is fresh in your mind. Several
: months or
: years later there may come a business requirement that needs change on a
: function. And it may not even be you who's doing it. Now, while the new
: committer knows what he's doing and he tests the new use case carefully. He
: doesn't know as well all the old use cases, it's even worse when he has to
: change a few functions/classes as a whole. Unit tests and integration tests
: can't cover it all, but at least minimize the impact here.
: The cost of bug goes up exponentially when it's in production. If the code
|
g*****g
发帖数: 34805 | 26 Unit tests are certainly not QA's job. And as a developer, I would write
integration tests for the main use cases at least. A good QA can help you
cover more corner cases, and integration tests that run through a few
different services from a workflow perspective. In short, you are
responsible for smaller tests, they are responsible for bigger tests.
Overall, you want to make sure any change you make won't cause a showstopper
before it goes to QA. Or you are not writing enough tests.
【在 p*****2 的大作中提到】
:
: Several
: He
: tests
: 大牛怎么看SDE和SDET的关系的？你说的这个如果用SDET是不是可以解决？
|
L*******r
发帖数: 119 | 27 赞，同意。我听过一句很好的话: "you'll be too lazy to not write tests"..
Several
He
tests
【在 g*****g 的大作中提到】
: It's about defense against change. While it's relatively easy to code
: without bug in first release when the design is fresh in your mind. Several
: months or
: years later there may come a business requirement that needs change on a
: function. And it may not even be you who's doing it. Now, while the new
: committer knows what he's doing and he tests the new use case carefully. He
: doesn't know as well all the old use cases, it's even worse when he has to
: change a few functions/classes as a whole. Unit tests and integration tests
: can't cover it all, but at least minimize the impact here.
: The cost of bug goes up exponentially when it's in production. If the code
|
r*****s
发帖数: 985 | 28 TDD对管理来说是个量化的工具，
什么完成，什么没完成，
什么破了，可以量化，
不然，
大家都是艺术家;)
【在 L*******r 的大作中提到】
: 赞，同意。我听过一句很好的话: "you'll be too lazy to not write tests"..
:
: Several
: He
: tests
|
p*****2
发帖数: 21240 | 29
showstopper
大牛认为QA和SDET是一回事吗？
【在 g*****g 的大作中提到】
: Unit tests are certainly not QA's job. And as a developer, I would write
: integration tests for the main use cases at least. A good QA can help you
: cover more corner cases, and integration tests that run through a few
: different services from a workflow perspective. In short, you are
: responsible for smaller tests, they are responsible for bigger tests.
: Overall, you want to make sure any change you make won't cause a showstopper
: before it goes to QA. Or you are not writing enough tests.
|
p*****2
发帖数: 21240 | 30
其实决定测试怎么搞的不是懒不懒的问题，是由business 的需求来决定的，不可一概
而论。
【在 L*******r 的大作中提到】
: 赞，同意。我听过一句很好的话: "you'll be too lazy to not write tests"..
:
: Several
: He
: tests
|
|
|
g*****g
发帖数: 34805 | 31 My team only hire testers who can do automation. I don't think testers that
can't do that have a bright future.
【在 p*****2 的大作中提到】
:
: 其实决定测试怎么搞的不是懒不懒的问题，是由business 的需求来决定的，不可一概
: 而论。
|
z****e
发帖数: 54598 | 32 小公司生存有压力，所以需要证明自己，以获得更多的资源
但是大公司一般没有这个压力，已经证明了自身存在的价值
剩下的就是如何把事情做好了，这个时候冒进，反而会丢掉已经取得的优势
小公司在市场上是处于一种弱势地位，所以必需要采取激进一点的策略
有时候赌一把必不可少，但是大公司在市场上处于强势，步步为营
不要犯错，最后胜利自然是大公司的，因为大公司有各种资源上的优势
需求经常改，这个其实跟语言本身相关不是那么大，用什么语言，需求乱改都会很痛苦
跟方法论有很大关系，所以现在搞agile，这个其实是information system
也就是business那边的研究课题，ba/pm什么对这一套其实比较熟悉
是传统软件工程和business相结合的领域
driven
【在 p*****2 的大作中提到】
:
: 其实决定测试怎么搞的不是懒不懒的问题，是由business 的需求来决定的，不可一概
: 而论。
|
p*****2
发帖数: 21240 | 33
我觉得跟语言关系很大。我很多时候都是有个idea，1，2天就要出prototype，很难想
像我可以用Java来完成。
【在 z****e 的大作中提到】
: 小公司生存有压力，所以需要证明自己，以获得更多的资源
: 但是大公司一般没有这个压力，已经证明了自身存在的价值
: 剩下的就是如何把事情做好了，这个时候冒进，反而会丢掉已经取得的优势
: 小公司在市场上是处于一种弱势地位，所以必需要采取激进一点的策略
: 有时候赌一把必不可少，但是大公司在市场上处于强势，步步为营
: 不要犯错，最后胜利自然是大公司的，因为大公司有各种资源上的优势
: 需求经常改，这个其实跟语言本身相关不是那么大，用什么语言，需求乱改都会很痛苦
: 跟方法论有很大关系，所以现在搞agile，这个其实是information system
: 也就是business那边的研究课题，ba/pm什么对这一套其实比较熟悉
: 是传统软件工程和business相结合的领域
|
p*****2
发帖数: 21240 | 34
that
其实能做automation是对SDET的最低要求了。
【在 g*****g 的大作中提到】
: My team only hire testers who can do automation. I don't think testers that
: can't do that have a bright future.
|
g**e
发帖数: 6127 | 35 测试另一方面也是平衡开发进度和质量的，搞高大全各种shortcut积累太多tech debt
最终会backfire。我们这QA跟dev report给不同的VP就是为了防止这种情况。当然只能
在一定程度上平衡… 赶起进度来大家都不鸟QA。另外amzn有很多组没QA，dev负责所有
。我以前的组连function test都没
【在 p*****2 的大作中提到】
:
: that
: 其实能做automation是对SDET的最低要求了。
|
L*******r
发帖数: 119 | 36 你都是用scala去prototype?为啥java不行啊。
【在 p*****2 的大作中提到】
:
: that
: 其实能做automation是对SDET的最低要求了。
|
z****e
发帖数: 54598 | 37 跟类库关系更大，只要找到合适的类库，就能帮忙做事了
还有ide这些，都可以自动化很多编码
【在 p*****2 的大作中提到】
:
: that
: 其实能做automation是对SDET的最低要求了。
|
z****e
发帖数: 54598 | 38 说说什么idea的prototype，我看看有没有办法简化
【在 p*****2 的大作中提到】
:
: that
: 其实能做automation是对SDET的最低要求了。
|
l*******g
发帖数: 82 | 39
从效率的角度来看我觉得有这么几个stagerequirement --
【在 p*****3 的大作中提到】
: 从效率的角度来看我觉得有这么几个stage
: requirement --> design，选方案 --> code --> test
: 越往后分量越轻。公司面算法和coding其实可以保证产出的code的质量，至少logic
: bug会少，代码容易懂。如果能一次写准甚至都不需要很高的debug的能力，这个我觉得
: 很重要啊。还一个是写的快，能在短时间产出高质量，bug少的代码，这点internet公
: 司比较需要。但是算法面试也就能做到这了，ACM选手可能都不一定知道怎么高效测试
: 自己的程序，特别是在legacy code上加或修改的时候好的test肯定是必要的。还有一
: 个就是测试环境是受到限制，什么时候做个简单unit test cover一下，啥时候在
: eclipse上做个简单的integration test, 啥时候在local box上测试个啥，啥时候在
: Devo上测个啥，各个阶段可以cover个啥，还是有些讲究。
|
c*******e
发帖数: 290 | 40 请问，大项目的需求分析和设计，是通过 UML 还是什么其他工具实现的？以前学个这
门课，但还没有用过。
【在 g**e 的大作中提到】
: cant agree more。我常说，一个project里面写代码的重要性最多占25%。没有清晰的
: 需求分析和好的设计注定最后就是烂摊子。
|
|
|
c********l
发帖数: 8138 | 41 之前在一个team里面，developer的头是一个白人，但PM的头是一个阿三
那个阿三经常需要改一些CSS的界面
每次改界面，不但要改code，而且还要把所有的unit test 全部review一遍
那个项目持续了大半年，青春就浪费在那个上面了
【在 p*****3 的大作中提到】
: 从效率的角度来看我觉得有这么几个stage
: requirement --> design，选方案 --> code --> test
: 越往后分量越轻。公司面算法和coding其实可以保证产出的code的质量，至少logic
: bug会少，代码容易懂。如果能一次写准甚至都不需要很高的debug的能力，这个我觉得
: 很重要啊。还一个是写的快，能在短时间产出高质量，bug少的代码，这点internet公
: 司比较需要。但是算法面试也就能做到这了，ACM选手可能都不一定知道怎么高效测试
: 自己的程序，特别是在legacy code上加或修改的时候好的test肯定是必要的。还有一
: 个就是测试环境是受到限制，什么时候做个简单unit test cover一下，啥时候在
: eclipse上做个简单的integration test, 啥时候在local box上测试个啥，啥时候在
: Devo上测个啥，各个阶段可以cover个啥，还是有些讲究。
|
b******y
发帖数: 9224 | 42
所以选对公司特重要，公司里选对组特重要。
【在 c********l 的大作中提到】
: 之前在一个team里面，developer的头是一个白人，但PM的头是一个阿三
: 那个阿三经常需要改一些CSS的界面
: 每次改界面，不但要改code，而且还要把所有的unit test 全部review一遍
: 那个项目持续了大半年，青春就浪费在那个上面了
|
z****e
发帖数: 54598 | 43 unit test用automation
尤其是python来写，这种回归测试，应该脚本化
【在 c********l 的大作中提到】
: 之前在一个team里面，developer的头是一个白人，但PM的头是一个阿三
: 那个阿三经常需要改一些CSS的界面
: 每次改界面，不但要改code，而且还要把所有的unit test 全部review一遍
: 那个项目持续了大半年，青春就浪费在那个上面了
|
