作为IC, 可以对不喜欢的task说不么？

直接找老板说吧= =。。。

firefall17 发表于 2019-1-30 14:23
我在工作上也有类似的情况。如果只让你做测试的话，基本上就是甩锅。 因为一旦有bug,首先就是测试没做好。t ...

谢谢，其实我们有planning的会议，应该是把所有task拿出来一起讨论然后分配的，理论上在讨论过程中每个人都可以发表意见。tech lead有私心，所以老板不来参加会议的时候我们planning就是扯淡，根本不讨论正事，然后整个sprint结束时他就可以按自己的喜好随便安排。我也是担心直接说不不职业，看来的确是这样。那我争取在他们扯淡时把话题拉回来吧。

谢谢楼上各位前辈和小伙伴，楼主就是担心是不是自己太挑剔，看来不是，的确是被人欺负的。楼主再想想斗争的策略

本文被提升为今日话题：凡是在置顶有效期内参与讨论，提供言之有物、切中主题的高质量回复，最低奖励20大米，干货越多奖励越多。

也请大家踊跃参与，看到好回答，请加分、请顶上去。对认真码字、热心分享的同学表示感谢，今后大家也会看到更多精彩分享。

说明：给别人加分不会扣除你的积分。


提示：今日另外一个话题：https://www.1point3acres.com/bbs/thread-475242-1-1.html

lz你好，我在现在的公司也是负责开发、测试、部署，我只说说我自己对于测试这方面的想法。我的工作流程是：先做好单元测试， 并用travis ci自动编译部署， 这样以后每次新的commit一来如果不通过test的话那就会fail， 等到单元测试做好了， 再做集成测试。我是这么做的：如果是repo A需要和repo B communicate， 那么在自动部署repo A的时候， 把repo B的内容拉下来并运行。 因为travis ci实际上每次是启动一个新的虚拟环境，类似于python中的virtual environment， 在repo A的travis ci文件中先pip install repo B的url， 然后run repo B service。 B的service起来之后，你就可以对A进行测试了。
进行到项目后期如果有很多个repo需要一起测试， 那么这时候最好的工具的就是docker 以及docker compose了， docker用起来非常方便，你不用担心每次配置各种环境， dockerfile写好之后基本就是一劳永逸。 启动所有的服务后， 你就可以用postman发送请求并看看是否返回预期的结果了。 关键是有错误一定要早发现，不然服务一多发现起来非常麻烦。
我现在的项目大概有12个repo， 每新加一个就执行相同的workflow， 目前来说执行的还算顺利， 希望对你有帮助。

这个我觉得是不应该出现的，test正常情况下都是谁写对应的function，自己写test，毕竟自己对自己的代码最熟悉。
另外tests本身就是impact低的活，看起来你有被穿小鞋的嫌疑

前一段也遇到这个情况，跟楼主一摸一样，开发的人连单元测试都不写， 然后我来写end-end 测试.... 后来抱怨了一下，现在让我做data 相关的项目，就好多了。测试本来就是吃力不讨好impact 还小的工作，测出毛病还会被说是不是你写的测试代码的问题. 跟老板谈一谈吧，实在不行跳槽。

拒绝，同时话要说的漂亮，诸如“新的framework每个人都应该尝试一下，这对team和个人都是有好处的，楼主不想把那么好的机会一个人独占。”

首先你得了解为什么不喜欢这个task，是你对技术的不了解还是因为外部因素造成。
这样才能学会尝试改变，学会改变自己，或者改变流程。
工作中很讲究owneeship，敢于揽别人不敢揽得活才能慢慢进步