在读过了邹老师的《移山之道》之后，
在这里写一下自己目前为止的疑问和感想。
不过，这本书中大多数都是以故事的形式来告诉我的一些道理，
所以我的疑问不多，大多都是感想。
身为团队的TEST我主要阅读了本书第15章的内容。
本章一开始就纠正我以前对TEST的误区：
（1）测试在项目的最后进行就可以了。
项目后期发现了问题的根源往往是项目早期的一些决定和设计，测试人员从项目开始就要积极介入，从源头防止问题的发生。
（2）测试就得根据规格说明书（spec）来测，所以是很机械的。
测试人员有责任从用户角度出发（可以不符合spec要求）测试软件。
（3）测试人员当然也写代码，但是质量不一定要很高。
测试是最后一道防线，不能有疏忽。
（4）测试的时候尽量用Debug版本，便于发现Bug。
用Release版本在软件开发后期很有价值，特别是在运行效能和压力测试的时候。
这个的有些观点我以前确实有，这一段话让我重新认识了测试这个观念。
当然，测试文档的目的是要解决问题、测试用例归类、错误报告格式等等内容页给我了很大的帮助。
但给我感触最深的是“萝卜和白菜”的故事。
故事内容简单直说，团队里有两个人，萝卜是“萝卜快了不洗泥”的类型；白菜是“慢工出细活”的类型。
任务最后白菜绩效不错，没什么问题单领导B没感觉他做了什么；
而萝卜第一个完成，修复缺陷最多，掌握最复杂的模块，离开他不行，工作得也晚，领导B任务他是超级明星有突出贡献。
假若领导B说的算，那么萝卜得到奖励，白菜就离开了团队。
故事最后，几个人的谈话并没有给我们一个明确的结论。
这个故事也没给出最后的结局。
但这个故事仍给我这个“白菜”式编程的人很大的感触。
我是不是会成为后一个结局中的那个白菜？
最后我感觉，确实，团队的领导者文化决定了团队的风格。（尽管我认为团队本身决定团队风格才是更合理的）
那当前我们该怎么办是个十分现实的问题。
目前的我，如果我遇到这个情况，我也许会选择“基因突变”变成萝卜。 = =||~
尽管我可能不是一个“纯种的萝卜”，第一个完成。
但至少不会让自己没存在感。
因为“我们写商业软件，是要赚钱养家”，如果自己都下岗了，“那拿钱来养啥”，我建议在公司里挂上“以老板为本”的几个大字。
不过真的这样就好了吗？
其实我认为无论是白菜还是萝卜都有着自己的优点和缺点。（这有点废话）
“萝卜”会带来危害，“白菜”也会以其他形式带来危害。
每个人有自己不同的风格，而真正需要迎合的不是某个人的喜好，某个人的风格，
而是要迎合能为团队带来最大利益的风格、团队的风格。
这只是身为学生身份的我目前的想法，期待几年后的身为其他身份的我的留言。
PS：
15.8.3 298页 “压力测试：” 中“乘客能活着下车”、“乘务员也能活着下车”的期望未免太低了吧~~
现在歌词里都不让有“死”字了，在这个和谐的社会里，我只是建议，还是把这个期望改的靠谱一点吧。 ^ ^
49
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
