※ 引述《vivokerker (vivokerker)》之铭言：
: ※ [本文转录自 Tech_Job 看板 #1Mo7_bds ]
: 作者: poc7667 (poc) 看板: Tech_Job
: 标题: [心得] 晶睿通讯VIVOTEK三年多工作经验
: 时间: Sat Feb 20 23:01:54 2016
: 小弟其实离开前东家 VIVOTEK 也一年左右了，
: 先后待过两个部门 R1 开发Firmware, DQA 开发自动化测试框架平台
: 说真的都离开这么久了，当初有的不爽不满，摸摸鼻子就算了！
: 但是昨天又听到前同事‘们’最近要被逼得不爽离职的辛酸泪，
: 于是来分享当年在这间公司服务的心路历程，
: 给台湾未来优秀软件青年做参考
: 此文很长，小弟先说结论
: 在 R1部门 我忘了我是一个念过六年CS的人
: 小弟背景113(学)->112(硕)，
: 在这里，我痛苦，整天上班就像是坐牢。
: 一开始曾经想努力看看是否适合这个 position，
: 后来实在被这种没日没夜，擦不干净屁股的屎缺磨光耐性，
: 尤其当你看到在上面的主管，整天在捧更上面的高高官马屁，
: 这些主管从上面拿到了任务，回头过来压榨底层同事 members
: 我也忘了从哪天开始我就下定决心摆烂装废，
: 直到后来被前主管约谈，踢到另一个 DQA 部门。
: 在 DQA部门 TD team 我重新找到 coding 的乐趣，
: 像是回到大学在写组合语言 Final Poroject 那种不会想睡觉，
: 想熬夜完成自己产品的心境，
: 总之你懂的，就是那种自动驱发你去做一件事情的动力。
: 在这里我学到很多，过得很快乐！
: 结论结束了，
: 接着陈述我自己在这间公司三年多的经验
: 进入VIVOTEK 你要有一个认知，底薪奇低无比。
: 我现在工作是以前月薪两倍多，
: 过六位数再多一点，公司经营再怎么烂，整年拿下来也有一定收入。
: 在一个开心有热诚的环境，你也不会去自暴自弃摆烂。
: 但是在 VIVOTEK，你真的黑的话，
: 当一个RD只拿个六七十万比作业员还惨，是有可能的！
: 由这两年小弟收集快‘一打’的因为吃闷亏不爽的离职前同事，
: 被黑的机率，一点也不低
: 这个部门也不过20~30个人而已吧，离职快一打也是不小的比例了。
: 进来R1这个部门，你的工作就是要出 Firmware
: Firmware 就是要去把各个系统 module 包好，
: 让整包 Firmware可以正常的运行在 Camera 上面
: 大部分 module 都是前人开发的历史共业，
: 你甚至可以看到 2004, 2006 年留下来的注解，
: 这些作者早就离职或者步步高升。
: 很多内部架构，当你实际在翻code，应该会‘一个头两个大’~_~
: 或许你心里会OS 可以 refactor 或者是打掉重练 ！
: 但是上面高官都会和善的跟你说，时程很赶，而且打掉重练也会有风险，
: 你就捏著鼻子，照着这团东西，继续改下去，得过且过吧。
: 于是乎，你整天就在跟‘这坨’东西奋斗！
: Firmware 还有一个重要的模组 - Web UI，
: 就是透过网页UI送 request 去控制Camera的状态
: 有兴趣的人可以自己想办法去买一台VVTK Camera
: 开到 Video page 检视原始码，
: 里面的 code 说有多肮脏就有多肮脏，
: 比很多大学生写的网页架构还‘颇ㄏ’
: Camera网页不外乎有css, js, html挡，
: 你常常能看到 html 里面会 embeded 一些奇怪的 script，
: 总是会在惊讶的地方发现这块code居然蹲在这个角落。
: 同样一个功能 他可能在 html 里面被 embeded js code 所影响，
: 或者后端的 js file"S" 所‘交互’控制。
: 很多时候你在查找某些功能会在哪边改到，
: 你必须去猜测伟大前辈可能用，
: 哪些方法去 access 到那个 element, XPATH, ID, ....
: 而且该功能也不一定集中在一个地方被控制，而是散落世界各地，
: 开启你的 command line ， grep 来 grep 去，你再加上你的补丁
: 反正能解掉就解掉，不能解掉就先贴个 workaround 丢给后面一个人慢慢补。
: 你可能解掉了某个 bug,
: 但是你忘了你修改的这个破补丁，
: 让另外一边功能也受影响了 嘿嘿！
: 别妄想什么自动化测试，没有什么 TDD test 拉，
: 你就是要凭经验去测可能受到影响功能就对了。
: 反正主管都觉得这个应该很简单啦，
: 你出错是你能力低落，怎么连写简单的网页都会有错。
: 以小弟我现在的程度来说，
: 当初在修改 video 相关的 js files，所花费的时间
: 都够我去完成我的 side project (https://lazyair.co/)
: 重写好几次都有找。
: 程式的奥妙之处就在这里，没碰过这Firmware web module屎缺之前
: 都不知道那少少几个没营养的 js 档，会让你 ooxx住套房。
: 总之做了很多事以后，你会需要 svn push 上去
: 然后偶尔莫名其妙 conflict 给你看？
: (OS: 好怀念这种上个世代的版本控管产物)
: 网页每一个js档案常常一两千行的 烂code 躺在那边给你看。
: 你要出 Firmware 就是每天都跟上述的那坨东西 fighting
: 或许有人会说，这也是一种练功，也是一种锻炼。
: 我会说‘你开心就好XD’
: 提完了主要工作内容，再来就提一下主管跟我相处的过程
: 首先，我是‘黑’人，想当然尔主管不会喜欢我。
: 以下都是梦境发生的了...
: 在我的部门下面有好几个小主管，
: 但是基本上部门是开放空间，你很容易知道某个主管在做什么事情
: 以下是发生在个人身上的经历，我尽量描述经历以及我的感受。
: 记得某个网页的 JS 我曾经留下一个 bug,
: 那个时候被 QA, RD, PM team highlight
: 在梦境中，我只记得OOXX主管拉我到后面去，数落我一番之外，
: 还要我保证往后不能出现这个网页 Bug
: 当下我非常的火，几乎要跟他吵起来。
: 我念CS念这么久，如果我可以保证某个东西不出 Bug 那我应该是可以得图灵奖了。
: 当然主管的意思是，这一块功能我要捏紧LP，以后不要乱出包。
: 但是要我发誓保证不会出 Bug ，但是即使在梦境我也做不到这种‘合理’的要求。
: 突然又梦到，有一次走到QA大楼开会，
: 忘了XXOO主管跟我交代了什么，要想办法把某次的责任撇到QA上面去。
: 当下心里是觉得他蛮无聊的，但是后来我到了QA，回想这件事情，会觉得蛮过分的！
: 一直到最后，
: 我被OOXX主管跟更大的主管，一起约到一个会议室。
: 他们告诫我说因为小弟绩效极差，又得罪了QA部门，
: QA跟高层反映我这个人很有问题！
: 高层决定把我调到QA进行自动化软件开发。
: 虽然我不太懂为什么‘得罪QA还要被调到QA’ 这种逻辑
: 但是当下可以离开这个地方，我心情是轻松的。
: 在人事异动过程中，HR大头也有跟我聊过，
: 问我知不知道为什么被踢过去。
: 我跟他说，据我所知是因为得罪了QA高层，
: 后来HR大头笑笑跟我说，他不知道有这件事情
: 他只跟我说那个OOXX主管，
: 私下跟HR反映要把我调离单位，Push的动作已经大概半年了....
: OS: 想起公司要每人挂在嘴上的 Slogan ‘诚信、关怀、创新、当责’心头乌鸦一阵飞过...
: 当然，因为我很‘黑’，也出过很多包，
: 或许这些我遇到的屎事都是可以预期的，都是我应得的。
: 接下来我简单讲几个我同事的例子
: 他们大都是 113 114 112 电机资讯背景的，所以至少都有基本程度吧?
: 某个平常表现不错的R同事要转换职场，正值发奖金的时节，
: 结果正常都要拿1~2个月以上的奖金，他只拿到了 4~6K (隐藏实际数字)
: 他去跟大大大头反应，该大大大头跟他说是公司政策。
: 不过奇怪诶，我们QA这边也刚好有人要走，怎么他就是拿正常的奖金?
: 某Y先生，在我眼中挺认真负责，
: 只是他们那一组的风气就是早上晚点到，
: 中午出去吃饭可能也晚点回来
: 但是他是那种‘周末’也会为了自己案子来加班的同仁，
: 也有入围敬业员工名单
: 但是也因为可能得罪了方丈，
: 年终也是惨兮兮
: (我想Y先生以后来是夹好软蛋，乖乖准时上下班吧)
: 某个J先生，受不了整天无脑的屎缺工作，
: 成天都在FB跟我抱怨他的主管在做一些ooxx的行为，只会用嘴巴写扣乱画大饼。
: 该主管讲的idea 跟做法，都笑破下面members的LP。
: 据说，该主管还被隔壁部门调过来RD呛过‘到底想不想做事’，
: 该呛人的RD我有短暂共事过，很有能力跟热诚，不过人也走了 心灰意冷啦。
: 想必该主管技术能力跟做官的技术，应该是成反比。
: 总之搞的J先生 整天怨天尤人，最后甚至自暴自弃，靠着酒精麻痹心
: 研替时间一到J先生就飞去米国，
: 目前已经录取美国Google了。
: 可见我相信J先生应该不是太废，而是他工作真的有点无脑又屎缺。
: 某Z先生，根本就没有实际交接过某Firmware模组，
: 结果可能凉凉的主管们声称已经交接完毕，
: 要他马上开始接手该module开始擦屁股
: 一遇到问题就是CC highlight 给很多人，
: 发挥写Email专长的影响力与当责精神
: 某G先生，以前坐在我对面那块区域，
: 到晚期的时候他的主管每天下午就会跟OX骂街一样，
: 当他当到整个部门约50坪的空间大家都清楚听得到。
: 某阳光男孩，
: 刚来的时候脸上都是自信阳光笑容，
: 每天都被他的主管夹软蛋，骂得跟狗一样，
: 明明在我们眼中他就是接上最赛的烂缺，
: 有人要接就阿密陀佛了，
: 该主管还是把他常常当狗一样电，年薪拿的比QA少。
: 脸上完全看不见笑容，你可以感受到一种哀伤跟自卑。
: (再来要提到R1跟QA这边我所了解的事情)
: 就我经验 R1常常要花很多时间 flighting spaghetti code
: 特别是网页的部分。
: 同时，QA部门也极力想要实现网页自动化测试，
: 降低公司人力测试成本，
: 提升软件品质，自动化测试框架 based on Selenium,
: 不过地狱的地方在这，每一台不同系列的Firmware网页架构都长的不同，
: 同一个功能的 DOM element 所属XPATH 也不尽相同。
: 几十种上百种的不同网页架构差异，是要怎么自动化测试？每一版本写一套 4Ni？
: 这边QA跟R1提过，要确实导入自动化节省公司测试成本提高品质
: 网页重要DOM element 一定都要有统一的 id value,
: 这样子做自动化测试我们比较好写 test case去测试。
: 结果据我所知，也是被ＯＯＸＸ主管以种种理由挡下，推托，完全当责。
: 最后这种一堆乱七八糟的网页档，
: 整坨就丢在QA部门脸上射后不理
: (反正屎不是他们要擦的，他们当然不care)
: 这样的做法，对R1部门来说很爽。
: 相对的QA很多case只能耗费超级大量的人力去加班测试。
: 设想，如果今天有个自动化测试框架，
: RD一开发好，自动 deployment 上去就知道哪里有bug，
: 不用RD, QA手动去测，不是也很爽吗？
: 很多 critical test 很regular，本来就适合自动化去测试，
: 这一关有做好至少可以挡掉很多低级的critical bug
: 可怜的R1 members，到现在还是要跟奴工一样进行手动测试。
: 或许OOXX主管们只想到它们自己！
: 能够快出产品赶上 deadline 就好，
: 没有考虑过身为奴工，把屎把尿的你们，有多么心酸。
: 也许他们也不曾考虑其他部门，
: 不考虑整体公司利益，把自己的狗粮顾好就好。
: 凭良心讲，产品的品质黑洞，
: 有些时候也是被一堆 不makesense的SPEC 所拖累。
: 举例来说，网页上某个input地方可以接受任意字符没有任何限制，听起来很棒棒。
: 不过，在Firmware处理上，这种东西Bug就是来了又去去了又来。
: 既然这道菜煮不好，你这间餐厅就不要做这道菜，做烂菜让客人点到反而更不爽。
: 像是今天开一间餐厅，
: 跟客户说你有一百道菜提供，客户当然好。
: 你跟客户说你有一千道菜提供，客户当然觉得更好。
: 但是很多时候很多菜，客户不吃根本就不会死，
: 把核心有价值菜色做得好才是‘价值’所在
: 把那些多余的菜，做得很难吃，让客户点到，小弟私心觉得会更糟糕。
: 小弟私心建议网页太多余功能想办法拿掉吧，RD，QA都花太多资源在这上面瞎耗T_T
: 总结一下对这个部门的评价，
: 这个部门的早期功臣，大多都高升了，
: 或许他们心中存在那种公司都是靠他们才撑得起来的幻想。
: 每次开会习惯性地贬低R2(这个不赚钱的部门，没用啦) ，
: 洗脸QA(一群ooxx 只会测一些无脑bug)，
: 老大自以为心态就是如此。
: 对于一些开发流程，以及旧有的黑洞，
: 就是鸵鸟心态，上面的人很怕出包很怕死。
: 反正一坨code能用就将就著用，不要被出包被上面highlight就好了
: 你如果对软件开发还有热诚，不是喜欢包装拍马屁的人，我不建议你来。
: =============================
: 再来谈谈我在DQA的日子，
: 这里的日子真的很快乐，重新找到写软件的乐趣，
: 拿的薪水也比我当RD时期多很多。
: 我在DQA做的是‘自动化框架开发’，加入的team是 TD team
: 当时算是草创时期，即时你现在进去也还算是很早的阶段。
: 在这边你的任务就是，利用任何高效的方式去测出产品可能的问题，尽量节省人力测试。
: 但是相对地，在这边很弹性，你闻不到官僚的恶心气息。
: 你觉得市场上有个技术很酷很炫，拿来开发可以节省人力，你就去学。
: 部门也会补助你去买 code school, udemy 相关课程，甚至让你出去花钱受训。
: 接下来我要讲我在DQA的日子，在提到DQA环境之前我想先说插一段故事。
: (以下指的是Firmware SI RD)
: 我相信大部分的人可能会觉得RD的职称比DQA好听多，听起来也比较好找下份工作。
: 在我观察，R1 RD 美其名叫做 RD，实则把屎把尿，解一些莫名其妙的盖营养 bug ，
: 这些 bug fix出来了对于coding实力的增长也微乎其微。
: 可以上去 redmine 上面看完一轮 bug，
: 大概就知道 RD 都花时间在解决的哪些‘盖营养鸡排’的Bug.
: 而出 Firmware 流程基本上follow VVTK 十年前硬干的build firmware toolchain，
: 惨的是在VVTK FW自创开发框架上，
: 想新增一个功能，必须知道是在哪一个档案定义，去该档案修改对应的参数。
: 这些类似的东西散落各地，大部分有规则，但也有很多例外。
: 你会花很多时间在学习这框架，有些东西也没有原因跟道理，
: 前人就是这样开发，你就是背起来记起来。
: 有时候你会惊呼，Jack这实在太神奇了，谁知道这里藏着这鬼trick。
: 但是离开了 Vivotek ，哪间公司承认你这自干自high的开发框架价值。
: 在 open source 盛行的今日，
: 市场上有一拖拉库很好的开发框架让你学到很好的软件方法与精神
: 以小弟深根的 Ruby on Rails 来说，
: 在探索学习RoR，本身就在学习无数前人的软件方法精华及 good practices。
: 在 DQA TD team 我花了很多时间深根在 Python, Ruby on Rails
: 在这些 knowledge 基础上去开发了自动化测试的框架。
: 在开发上我们也走Scrum, 也玩Sprint,
: 用trello, slack 让沟通更有效率
: 在这边我熟练深耕了下面技能，也让我有了即战力找寻往后的工作。
: - Python, Twisted framework, Robot framework
: - Selenium
: - Ruby on Rails
: - Database: MongoDB, PostgreSQL, ElasticSearch, MySQL, Redis
: - JS: Angular.js, React.js
: - Load balance: horizontal scalable infrastructure design
: - Network security
: - Git flow development
: - Auto developemnt methodology: capistrano
: 在DQA是我自我实力成长最快速的期间
: 实在是内心由衷感谢 VIVOTEK P处长, W经理, J主管,
: 以及所有曾经一起共事过的同仁
: 因为他们给予这样的开发环境与空间，
: 才能够让我有一些成果贡献给前公司 VIVOTEK
: 他们是我生命中的贵人。
: 以上梦境提供有兴趣朋友参考，我尽量如实的客观陈述我遇过的鸟事
: ‘当压榨屎缺成为事实，革命起底就是我的义务’
: 当然VIVOTEK也有很多很优秀的部门，官僚风气尚可，
: 你还是有机会找到属于你的舒适圈
: 我极推 QA TD team，
: 这里只写code，不做嘴砲
: 没有历史共业包袱，弹性自由发挥空间大。
: 任何你在市场上看到的神兵利器新技术，
: 只要对自动化验证有帮助，尽管用，开发的方向都很有弹性。
: 特别如果你是RD的话，在这里，你不会有机会整天接电话，
: 光应付电话就饱三餐的生活，
: 你真的可以很专心很专心地完成你手上的产品。
: R2也听说有不少好评，不过我不熟就不便过多着墨
: 总之路是自己选的，特别是给研替的小朋友看
: 今天你不想当兵，就是不想在军中浪费生命。
: 倘若你之后的工作跟当兵没两样，还要绑三年，我相信这不是你想要的。
: ‘诚信、关怀、创新、当责’在公司的某些地方，也许只是笑话口号
: 更何况，在某些部门你‘注定’需要做屎缺。
: - 做得差，薪水比作业员还低
: - 做得极好，你薪水也好不到哪里去，就我经验顶多破百一些吧？
: 希望大家能够找到自己喜欢的工作，
: 毕竟工作占据了我们生命大部分的时间，
: 当你在工作上做自己有热诚的事物，真的是一件很快乐的事情！
最近知道这家公司好像有一些被收购的消息，找到这篇文章。
原po好像原本是在RD部门然后被换去QA部门。
后来结论是QA部门比较能够尽情的发挥。
公司一些内斗的事情就不谈了，那个局外人不是很了解，
不过到是可以讨论一下RD和DQA部门，一个是发展产品，一个是写自动化测试。
老实讲，我待过这个多间公司，还没遇过有另外开个部门在处理自动化测试，万事起头难。
就如原po说的，很多东西没标准化，要自动化测试确实困难。慢慢会渐入佳境吧@@
我认为RD有分成两个，
一种是专门维护现有产品，一个是开发新功能。
原po原本的RD缺应该是前者，就是维护和新增一些小功能。
这类的缺本来就不太可能有大变动，他对上的是客户，关系到的是品牌的形象。
一个不断用维护的方式建立的架构，也许不好看，但稳定度应该是越来越高。
没人敢保证写出来的东西没bug，如果新架构用下去，bug从100条上升到300条，很多更是奇奇怪怪的问题，现在是要花多少时间解 ?
但是如果是旧的code在维护，除非是新bug，不然稍为有经验的人，就会开始用退版的方式去测，两版code diff一下，问题很快就找到了。
DQA写出来的东西，本来就无关品牌，当然爱怎么写就可以怎么写。
站在老板的立场，真的很难把已经用几十年的东西，重新打掉重练。那个才成长两三年的code，就不用拿出来说了。
比较有可能的是新旧两版code同时进行，但那成本就很高了