作者howwin (破财了囧rz)
看板Soft_Job
标题Re: [讨论] 在网站平台变大後还会为求效能变更架构吗
时间Thu Oct 12 11:32:30 2017
在台湾的软体公司一向很缺测试，(以下说的都是自动化测试)
但好的测试(我偏向BDD而非TDD)其实可以节省後面很多时间
事实上架构永远都不会够好，以前想multi-thread, multi-process
後来改distributed，现在又变成serverless，太多的架构会跟着改变
更别说每个人观点或每种技术的优缺都不太一样
甚至现在看以前的架构也非常可能觉得不够好！
所以别天真的想说会有一个完美的架构，搞好change control才是
有好的测试其实让你在改动架构或甚至任何改动的时候，可以让你放心去做
当然许多新创在做MVP的时候没做测试是可以接受的，
毕竟如果产品活不下来，技术债是不用还的，测试当然必要性也很低
然而在确定产品可以存活下来一段时间的时候，
最好把该做的测试补上，我指的并非coverage要非常高(>90%)
而是一些核心的功能、API测试先补起来，然後再慢慢把coverage提高
所以现在能建议的就是，尽可能的说服你老板说现在每次的改动其实风险很高
所以看能不能每周(或每一段时间)让你分一些时间去做好测试
至少先把主要功能做起来，让你之後改动风险小一些
我了解在新功能优先的情况下，要说服很困难，
但你可以网站有多少流量、为公司带来多少$$等因素，
来说明如果现在一些风险的控制不做的话，可能会损失多少钱
(如果他觉得这样是因为你的bug造成的，那我想这公司也不用待了？)
※ 引述《zeldo (瓜拉度)》之铭言：
: 在开发网页平台时，除了基本的维护、debug外，还有每次交办下来的新功能以及
: 新需求，有些地方在每次新功能的加入、删除下，时间一长，慢慢也会出现些架构
: 上问题。特别是在公司求快、求好、可以短时间展示的政令下，更是如此。
: 在面对数次的修正之後，还是会有些隐忧存在其中，只是不知道什麽时候会跑出来
: ，对於这样的状况，会为求效能而去翻新平台的架构吗？
: 这其实也是小弟我在现在工作上面临的状况，很多地方在需求变更前修後改的情况
: 下，造成不少没作用的code跟function，而且在那时为需求而设计的架构也被东挪
: 西挪，配合使用在其他的功能下，虽说平台的运作上都正常，可那些遗留下来的东
: 西却很碍眼，并且也引起些问题。
: 的确这也与自己当初开发时对於功能弹性没有完善有关，可很希望能好好补救。但
: 现在也还是有许许多多的新功能急着要开发，使得这就有如叠叠乐一般越叠越高。
: 上头也表示现在以完成需求为主，等稳定後再慢慢修，而且会担心如果作大幅度的
: 翻修，会影响到现有的功能...
: 请问在网页平台变大後，还会为求效能去变更架构吗？
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 192.77.239.48
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1507779154.A.E6A.html
1F：推 visa9527: 改架构自动化测试也是要重写 10/12 14:19
2F：→ remmurds: BDD要推得动涉及的是整个组织结构的问题 不晓得台湾哪 10/12 18:47
3F：→ remmurds: 间公司办得到… 10/12 18:47
4F：推 prag222: 什麽自动化测试 先问问看老板有没有概念 有没有意愿 10/12 21:05
5F：→ maxqq: 自动化的架构师，真的挺重要的，但台湾一堆用嘴写 code 10/12 23:23
6F：→ maxqq: 自然看不上什麽自动化 10/12 23:23
7F：→ maxqq: 自动化还要学，又赚不到钱，用嘴写，事情就解决了 10/12 23:24
8F：→ maxqq: 还需要自动化干嘛? 10/12 23:24
9F：推 yyc1217: 也不能这样讲 写测试时间至少占三 四成以上 如果系统 10/13 01:41
10F：→ yyc1217: 不够大 不写反而比较方便 10/13 01:41
11F：→ yyc1217: 国外很多工具与概念都是为了解决超大架构的问题 台湾能达 10/13 01:42
12F：→ yyc1217: 到规模的公司没那麽多 10/13 01:42
13F：→ yyc1217: 有达到规模的公司员工比较多 能顾虑到的点当然也会比较多 10/13 01:43
14F：→ yyc1217: 小公司没必要为了赶流行 硬要追上新技术 但是要时时留心 10/13 01:44
15F：推 ripple0129: 不用到超大架构吧，只要是有持续更新的系统，测试带 10/13 03:48
16F：→ ripple0129: 来的好处是显而易见的。除非是写完就放置play的啦， 10/13 03:48
17F：→ ripple0129: 不然测试在你後面发现改东坏西的修复成本，大多是能co 10/13 03:48
18F：→ ripple0129: ver过来的。 10/13 03:48
19F：推 maxqq: 不认同只有大公司需要，台湾小公司人来来去去 10/13 08:19
20F：→ maxqq: 一堆连文件都不在乎，只是想把烂频果丢给下一个人 10/13 08:19
21F：→ maxqq: 然後每天幻想，整天以为找个工程师就能拥有全世界 10/13 08:20
22F：→ maxqq: 一个自动化与文件，我现在自己一个人维护与开发，节省超多 10/13 08:20
23F：→ maxqq: debug 时间，认真说，时间久了你写这麽多种语言 10/13 08:21
24F：→ maxqq: 也忘记你到底写了什麽，跟别人写的一样 10/13 08:21
25F：→ maxqq: 写好写满，有些时候才能前进的更快 10/13 08:22
26F：→ howwin: 写测试跟弄测试架构的确很花时间，但对一个活得下来的软体 10/13 10:28
27F：→ howwin: 事实上维护(包括改旧的code)的时间会比开发来得多 10/13 10:29
28F：→ howwin: 这时候测试就会明显帮你省下许多时间 10/13 10:30
29F：→ howwin: 要推BDD, CI/CD, DevOps都是组织的问题，但我遇过的工程 10/13 10:32
30F：→ howwin: 师们，其实都很乐意这种学习，反而是上头常常不了解 10/13 10:33
31F：→ howwin: 所以并不会大力支持，久了大家自然就又回到开发主导 10/13 10:34
32F：推 sharku: 自动化测试非常重要 10/14 10:53
33F：推 lovebridget: 搞得越烂越没人能接 越不会被取代阿 10/15 11:40
34F：→ lovebridget: 然後新人来问再摆老狗干不教 位子坐稳稳 10/15 11:40