Re: [討論] 在網站平台變大後還會為求效能變更架構嗎

看板Soft_Job作者 (破財了囧rz)時間6年前 (2017/10/12 11:32), 編輯推噓7(7推 0噓 27→)
留言34則, 9人參與, 6年前最新討論串2/2 (看更多)
在台灣的軟體公司一向很缺測試，(以下說的都是自動化測試) 但好的測試(我偏向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://www.ptt.cc/bbs/Soft_Job/M.1507779154.A.E6A.html
推
10/12 14:19, 6年前 , 1F
改架構自動化測試也是要重寫
10/12 14:19, 1F
→
10/12 18:47, 6年前 , 2F
BDD要推得動涉及的是整個組織結構的問題 不曉得台灣哪
10/12 18:47, 2F
→
10/12 18:47, 6年前 , 3F
間公司辦得到…
10/12 18:47, 3F
推
10/12 21:05, 6年前 , 4F
什麼自動化測試 先問問看老闆有沒有概念 有沒有意願
10/12 21:05, 4F
→
10/12 23:23, 6年前 , 5F
自動化的架構師，真的挺重要的，但台灣一堆用嘴寫 code
10/12 23:23, 5F
→
10/12 23:23, 6年前 , 6F
自然看不上什麼自動化
10/12 23:23, 6F
→
10/12 23:24, 6年前 , 7F
自動化還要學，又賺不到錢，用嘴寫，事情就解決了
10/12 23:24, 7F
→
10/12 23:24, 6年前 , 8F
還需要自動化幹嘛?
10/12 23:24, 8F
推
10/13 01:41, 6年前 , 9F
也不能這樣講 寫測試時間至少佔三 四成以上 如果系統
10/13 01:41, 9F
→
10/13 01:41, 6年前 , 10F
不夠大 不寫反而比較方便
10/13 01:41, 10F
→
10/13 01:42, 6年前 , 11F
國外很多工具與概念都是為了解決超大架構的問題 台灣能達
10/13 01:42, 11F
→
10/13 01:42, 6年前 , 12F
到規模的公司沒那麼多
10/13 01:42, 12F
→
10/13 01:43, 6年前 , 13F
有達到規模的公司員工比較多 能顧慮到的點當然也會比較多
10/13 01:43, 13F
→
10/13 01:44, 6年前 , 14F
小公司沒必要為了趕流行 硬要追上新技術 但是要時時留心
10/13 01:44, 14F
推
10/13 03:48, 6年前 , 15F
不用到超大架構吧，只要是有持續更新的系統，測試帶
10/13 03:48, 15F
→
10/13 03:48, 6年前 , 16F
來的好處是顯而易見的。除非是寫完就放置play的啦，
10/13 03:48, 16F
→
10/13 03:48, 6年前 , 17F
不然測試在你後面發現改東壞西的修復成本，大多是能co
10/13 03:48, 17F
→
10/13 03:48, 6年前 , 18F
ver過來的。
10/13 03:48, 18F
推
10/13 08:19, 6年前 , 19F
不認同只有大公司需要，台灣小公司人來來去去
10/13 08:19, 19F
→
10/13 08:19, 6年前 , 20F
一堆連文件都不在乎，只是想把爛頻果丟給下一個人
10/13 08:19, 20F
→
10/13 08:20, 6年前 , 21F
然後每天幻想，整天以為找個工程師就能擁有全世界
10/13 08:20, 21F
→
10/13 08:20, 6年前 , 22F
一個自動化與文件，我現在自己一個人維護與開發，節省超多
10/13 08:20, 22F
→
10/13 08:21, 6年前 , 23F
debug 時間，認真說，時間久了你寫這麼多種語言
10/13 08:21, 23F
→
10/13 08:21, 6年前 , 24F
也忘記你到底寫了什麼，跟別人寫的一樣
10/13 08:21, 24F
→
10/13 08:22, 6年前 , 25F
寫好寫滿，有些時候才能前進的更快
10/13 08:22, 25F
→
10/13 10:28, 6年前 , 26F
寫測試跟弄測試架構的確很花時間，但對一個活得下來的軟體
10/13 10:28, 26F
→
10/13 10:29, 6年前 , 27F
事實上維護(包括改舊的code)的時間會比開發來得多
10/13 10:29, 27F
→
10/13 10:30, 6年前 , 28F
這時候測試就會明顯幫你省下許多時間
10/13 10:30, 28F
→
10/13 10:32, 6年前 , 29F
要推BDD, CI/CD, DevOps都是組織的問題，但我遇過的工程
10/13 10:32, 29F
→
10/13 10:33, 6年前 , 30F
師們，其實都很樂意這種學習，反而是上頭常常不了解
10/13 10:33, 30F
→
10/13 10:34, 6年前 , 31F
所以並不會大力支持，久了大家自然就又回到開發主導
10/13 10:34, 31F
推
10/14 10:53, 6年前 , 32F
自動化測試非常重要
10/14 10:53, 32F
推
10/15 11:40, 6年前 , 33F
搞得越爛越沒人能接 越不會被取代阿
10/15 11:40, 33F
→
10/15 11:40, 6年前 , 34F
然後新人來問再擺老狗幹不教 位子坐穩穩
10/15 11:40, 34F
‣ 更多 howwin 的文章
文章代碼(AID): #1Ptk9Ivg (Soft_Job)
‣ 更多 howwin 的文章
文章代碼(AID): #1Ptk9Ivg (Soft_Job)