作者查詢 / luciferii
作者 luciferii 在 PTT [ Soft_Job ] 看板的留言(推文), 共1930則
限定看板：Soft_Job
看板排序：
全部SuperHeroes3463book2758Soft_Job1930movie1641logic899ShuangHe889Translation760EAseries750SongShan736Fantasy714translator701WarringState674Shu-Lin594StarWars501Comic410SF396GUNDAM317TBBT300MRT256Detective239W-Philosophy220AC_In218DoctorWho214Gossiping208C_Chat184StarTrek141SD126TRPG123Ancient116Inference113model113Scifi_Drama113Tech_Job73NetSecurity72BoardGame71PokemonGO57kachaball46Heroes41nobunyaga32CSSE28Keelung27Seiya26XiangSheng25Japandrama17HsinTien16SAN-YanYi14Military12bookhouse11CultureShock11gallantry11L_LifeInfo11AC_Sale10Zombie9TFSHS66th3078P_Management6Suckcomic6Toy6Cloud5fashion5PCSH91_3055criminology4e-coupon4Eng-Class4PCman4RealPlaying4emprisenovel3Food3JapanHistory3KoreanPop3SAN3Tokusatsu3NCTU_TALK2Sangokumusou2soho2StupidClown2Sucknovels2Teacher2AboutBoards1AfterPhD1AllTogether1ask1Atheism1Christianity1Daan1Emergency1Fortune1HarryPotter1HatePolitics1joke1L_TalkandCha1Marketing1NIHONGO1NTU-EM931NTU-Fantasy1P2PSoftWare1Palmar_Drama1Salary1Shooter-game1Taipei1<< 收起看板(99)
26F推: 別用簡訊了吧，考慮 Google Authenticator 之類OTP08/14 21:57
27F→: 除非你客戶只有傳統手機08/14 21:57
28F推: 這個是Wi-Fi涵蓋率可能還比Cellular廣的時代08/14 22:01
35F推: 反了吧，手機掉了，簡訊要等補發SIM卡才能再用，如果換08/17 17:28
36F→: 門號更麻煩，要去所有設定過的地方重改。08/17 17:28
37F→: Authenticator之類拿到新手機，跟服務商重註冊就可以用08/17 17:29
39F推: 我目前用到的幾家國外原廠網頁都改用驗證器了，也一堆08/17 21:17
40F→: 客戶要求在不改code的狀況下引入驗證器機制，畢竟OTP08/17 21:17
41F→: 要求用驗證器最快，即使不用公用驗證器也是自己刻app驗08/17 21:18
42F→: 證，特別是網購業。08/17 21:19
43F推: SMS驗證已經被駭客打到爛了...08/17 21:23
44F推: Twitter 就是因為簡訊驗證虧損太多，所以今年限用了。08/17 21:27
48F推: 2016就說簡訊不安全了，金管這兩年也要下令搞FIDO2，08/18 15:13
49F→: 上面例子全都是網站應用。08/18 15:13
50F→: 驗證器app頂多是還沒裝，使用難度根本跟簡訊一樣或更08/18 15:16
51F→: 簡單。例如直接跳按紐提示按OK就好，連輸入都不用。08/18 15:17
52F推: 商用網站很少只支援簡訊OTP了，沒有APP OTP至少也有08/18 15:26
53F→: 通訊軟體 OTP，不管怎樣，長期下來遲早都會被逼去用。08/18 15:27
54F推: 會登入後台會收簡訊重敲密碼的人，能力上就會驗證器08/18 15:34
25F推: 這樣鬥來鬥去的文化就是讓學到教訓的A/原PO另謀他就，08/04 23:57
26F→: 團隊剩下都會是死皮賴臉依然故我的B，還得等到他再出包08/04 23:58
27F→: 才能找藉口攆走……前提是他還願意認錯乖乖被開除。08/04 23:59
8F推: 你可以照樣進公司無薪作業啊，你們公司沒禁止吧08/04 02:42
38F推: 事實是B應該不只測一次，誰code只測一次就交出去?07/29 23:24
47F推: 對老闆來說，原PO/MA的問題在於需求不清，A的問題在於07/30 01:25
48F→: ticket close，但這些都可以靠改制度去補強。但B的作為07/30 01:25
49F→: 是地雷，制度上要防（UT不作，或fail還故意放過）要花07/30 01:26
50F→: 成本太大，不如找理由剷掉地雷。07/30 01:27
51F→: A/原PO/MA的狀況在所有開發人員身上都可能發生，但B作07/30 01:27
52F→: 法是純粹的惡意。07/30 01:28
53F→: 即使只是嘴砲，對自己參與的專案落井下石，也別期待他07/30 01:28
54F→: 未來會願意扛什麼責任，只會扯後腿幸災樂禍。07/30 01:29
55F推: 擴大點說，敢聲稱「自己的code不用測試，反正有QA」的07/30 01:32
56F→: 主張，都最好不要跟他們合作，這是准雷包。07/30 01:33
57F推: 他們惡整出包時很難抓出來，就像B不自爆很難知道他惡整07/30 01:38
60F推: 然後B把自己會爆的程式放行開出去，後來的人請爬文07/30 07:27
274F推: 同上，我本來以為B不承認可以免責，但後來原PO有補述：07/31 22:52
275F→: code原流程是 A->B->QA。07/31 22:52
276F→: 出問題時 A->B->A'->B'->QA。07/31 22:52
277F→: A'是QA去幫忙A，還是無法復現後，A和主管再改的版本。07/31 22:52
278F→: A/A'在自己環境不會爆，但B和B'在自己環境是100%爆掉。07/31 22:52
279F→: 所以不是QA過了B不敢擋，而是B明知QA驗不出來，07/31 22:52
280F→: 故意summit自己知道100%會爆的東西過。07/31 22:52
281F→: 看起來很難追查，但是事後找到原因，就查到B的環境07/31 22:52
282F→: 是可以完全復現問題的。07/31 22:53
283F→: 即使B不自爆，他還是會被追問B/B'的測試結果。07/31 22:53
284F→: 所以最後B主管幫B想的解套法是：說他根本沒測，認輕罪07/31 22:53
285F→: 只是高高層顯然還是心知肚明。07/31 22:53
286F→: 畢竟你敢放話，代表你不覺得自己有錯，以後還會再幹。07/31 22:54
287F推: 整件事我覺得諷刺的是，如果他們流程完整一點，B測試07/31 23:02
288F→: 前把環境恢復成標準環境，反而會測出不出問題，等到客07/31 23:03
289F→: 戶爆了才一路追回是需求不清。07/31 23:03
329F推: B真正會被討論這麼久不是因為他沒複測，而是有複測完08/03 03:36
330F→: 其實沒過，而且沒過的不只A code還包含自己的 B featu08/03 03:37
331F→: 在確定過不了的狀況下故意開出去。08/03 03:37
15F推: 你可能要回去看下原文，原po 是 application owner，07/28 17:22
16F→: B才是feature owner。B知道自己的feature有問題，是07/28 17:22
17F→: A的code造成的。A改過code後，他還是硬開出去，結果07/28 17:22
18F→: 是B的feature 讓客戶爆炸。07/28 17:22
19F→: 最後他說我的code部分是假設A code 沒問題寫的，我的07/28 17:22
20F→: 部分沒問題。但 feature有沒有問題？我沒再複測（至少07/28 17:24
21F→: 表面上說沒有）。這樣當然會被懲處，B是 feature owner07/28 17:24
22F→: 啊。A的code是改過再回來的，並不是跟前一次相同code。07/28 17:24
27F→: B如果可以不用測，那專案裏大家都各自開發各自的就好，07/28 17:25
28F→: 同理，就算你不是用同事的code，而是引用任一個公開函07/28 17:25
29F→: 式庫。當函式庫更版時，你可以說「我假定函式庫都是正07/28 17:25
30F→: 確的，只要我的call function code正確，我不須要重新07/28 17:26
31F→: 測試。」嗎？07/28 17:26
32F→: 不管A/B關係多惡劣，B是feature owner，至少你要保證你07/28 17:26
33F→: 交出去的東西在你local是run正常的。你都run不正常或沒07/28 17:26
34F→: run就交，本來不是你的鍋也變你的鍋。07/28 17:27
58F推: 原PO有和A改過一版重送，不管有沒有修到Bug，B說他沒測07/28 18:34
59F→: 有新 code 送過來，B是feature owner 不管怎樣都有義務07/28 18:35
60F→: 要重測，因為你freatue的成果會受這段code影響。07/28 18:36
61F→: bug被關掉你可以不測那bug，但至少要測完你自己的07/28 18:38
62F→: feature在新版是不是正常吧。07/28 18:38
63F→: B先說他知道feature有問題，但硬送；後來改口說他根本07/28 18:39
64F→: 沒重測，不管哪種說法都有問題，輕重程度不同而已。07/28 18:39
65F→: 說極端一點，就算A台面上說他改版只改了註解，B還是有07/28 18:41
66F→: 義務要測。07/28 18:41
67F推: 你自己feature output有問題了，即使你認定是A害的而且07/28 18:47
68F→: 他擺爛，B就要想辦法，因為「B是RD不是QA」啊，不是回07/28 18:49
69F→: 退就好，feature owner負責feature成敗，一如原 PO是07/28 18:49
70F→: application owner負責整個專案成敗一樣。07/28 18:49
110F推: B故意commit也是他自己承認的，不是人家栽贓給他07/28 21:04
111F推: 後來找問題當然不需要B，直接去爆掉的客戶環境更準確07/28 21:09
112F推: 原PO描述的權責應該很清楚，整個 application 的owner07/28 21:14
113F→: 是他，這個appliction裏有很多 feature，其中一個fea07/28 21:15
114F→: 的owner是另個部門的B。B的feature需要call的kernal07/28 21:16
115F→: 或 function owner是A。只是職位上原PO跟A是同部門。07/28 21:17
116F→: A code 自己UT沒問題，但B 整合完自己UT有問題，怪A07/28 21:17
117F→: 那就是A/B要合作找問題，A找不出問題直接影響的是B07/28 21:18
159F推: 原PO就說Bug關閉和B要驗測要當成兩件事分開究責，bug07/29 09:57
160F→: 關閉但是 A code 更新的，B就是要驗測。B現在是明知自07/29 09:58
161F→: 己code會跟著一起爆炸，不管他有沒有真的測過，他的責07/29 09:59
162F→: 任就沒盡到了。07/29 09:59
163F推: B 不該 commit 的最大理由就是他自己code沒法正常跑。07/29 10:03
164F→: 後來也是確認了B惡搞，只是惡搞程度從嚴重改成輕微而已07/29 10:04
165F推: 從「故意放過」改為聲稱「故意沒測」而已。07/29 10:08
167F推: 根據他自己的說法，他第一版只測一次就爆了07/29 12:49
168F→: 第二版完全沒測就放行。07/29 12:49
169F→: 根據原PO懷疑他自己承認的實情可能是，他第一版測多次07/29 12:50
170F→: (正常工作流程)100%爆掉，第二版也是測多次(正常工作流07/29 12:50
171F→: 程)確認沒修，但刻意commit要HL A(本人說法)07/29 12:51
172F→: 不管你相信B哪種說法，他都是故意放過code了，免不了責07/29 12:51
173F→: 而且這個測試不是對A code UT，而是自己的 feature UT07/29 12:53
179F推: 同段code在B local會fail，在A/QA 環境會過啊07/29 15:34
183F→: B現在被懲處不是沒複測code，是自承feature UT沒作07/29 15:36
337F推: air:會，而且是一定會。不釐清問題狀態很難盲追問題。07/29 23:29
338F→: 你開case到所有系統原廠，對方客服預設回信就是跟你確07/29 23:29
339F→: 任環境和描述問題。07/29 23:29
1F推: 但是B最後的自我辯護不是無法repro，而是完全沒作。07/28 02:56
2F→: 然後沒測就開出去了。07/28 02:56
3F→: 如果真的測了但無法repro，其實他不需要說謊。07/28 02:57
4F推: 只測一次是B自己講的，100% repro也是B自己講的，所以07/28 03:04
5F→: 只測一次就失敗，回報後也不複測的B，還是開發完了還07/28 03:04
7F→: release出去，如果他不是故意才更恐怖吧，代表他都是閉07/28 03:05
8F→: 著眼開發。07/28 03:05
10F→: 照上篇說法，B至少要UT，所以第一次 UT 失敗開Bug。07/28 03:07
11F→: 沒完成UT當然責無旁貸。除非他說第二次UT無法repro。07/28 03:08
12F→: 但他是説第二次他沒UT。07/28 03:08
17F推: 他的UT工作跟自清或高光無關吧，本職上就是UT自己這關07/28 03:15
18F→: 的東西確認沒問題才交下一關。07/28 03:15
21F推: 流程： A code (UT) -> B(UT)(整合)(UT) -> QA07/28 03:20
22F→: 不管有沒有 Bug 都是這流程，所以B第一次回退後，A07/28 03:21
24F→: close後再送過來的東西，B還是要UT和整合完才下一步。07/28 03:22
26F→: B無責：A code -> B UT無法復現 -> QA07/28 03:23
27F→: B重責：A code -> B UT復現，故意放過-> QA07/28 03:23
28F→: B輕責：A code -> B 沒UT -> QA07/28 03:24
29F→: UT（Unit Test）整合（integration）IT(integ. Test)07/28 03:26
33F推: 但B是說他第二次完全沒作UT。07/28 03:28
34F→: 沒什麼「掛理想對方作過」，照上篇原PO提到公司流程，07/28 03:30
36F→: 每個環節都要自己作UT。07/28 03:30
40F推: B的東西要用到A，所以B的UT一定會包含到A的code07/28 03:38
41F→: 不是UT階段就是IT階段。07/28 03:38
43F推: 啊不是，不管A寫的code怎樣，B自己要交給QA的東西自己07/28 03:41
44F→: 都說沒測過，怎麼樣都說不過去吧。07/28 03:41
78F推: B一開始就自己說要故意炸客戶來HL啊，之後調查B主管才07/28 10:38
79F→: 提出追加解釋。所以原PO才說，如果B講的真話而不是氣話07/28 10:39
80F→: 那就非常嚴重。07/28 10:39
84F推: 說B不敢交，但他就真的交了，不管是因為(1)他自己說沒07/28 10:48
85F→: 測，或(2)他測了沒過還是硬交，現實就是他交了。07/28 10:49
86F→: 除非是(3)他測了，沒法復現，所以安心交了。但他自己否07/28 10:49
87F→: 認了這條路...07/28 10:49
88F推: 檢討B很重要，就像B知道輪胎有問題，還故意組裝到車上07/28 10:52
89F→: 害死人後，他不能說「輪胎又不是我作的，跟我無關。」07/28 10:53
90F→: B主管也知道不能這樣講，所以才改成「B組裝完沒再試開07/28 10:54
91F→: 過，所以他只是猜測輪胎有問題，不是故意。」07/28 10:55
110F推: 現在就是B自己說他第二次連外觀都沒看就放行了07/28 11:23
111F→: 這兩次code不一樣喔，B不管這Bug有沒有修，都要重測吧07/28 11:23
113F→: 而且B說的不是「我早知有問題」而是「我早知有問題但是07/28 11:25
115F→: 故意裝上去要看它出事。」07/28 11:25
120F→: 原廠送來第二顆輪胎了喔，不是原本那顆。07/28 11:27
122F→: 原PO和A有改過code重新commit。07/28 11:28
126F推: 正常流程也是要找出B環境的問題，萬一客戶跟B同環境呢?07/28 11:31
129F→: 後來證明也是。07/28 11:31
132F推: A和B要一起查，這沒法靠單邊找出來問題。07/28 11:33
133F→: 所以說兩邊不願意合作就要叫主管。07/28 11:33
139F推: A只寫無法復現吧，系統上通常不會白目去標是B有問題。07/28 11:40
153F推: 問題就是B自己說他確信輪子會出包，故意裝上去要HL原廠07/28 11:50
156F→: LAGG是客戶原本有，但原廠沒想到，所以這是原廠的鍋07/28 11:51
157F→: 車行剛好有LAGG的車子，但是也沒想到是這問題，只想釘07/28 11:52
158F→: 原廠，就變事故了。07/28 11:52
164F推: LAGG是客戶環境標配，不在開發案本身裏。07/28 12:01
165F→: 但應該在開發前要調查清楚。07/28 12:01
171F推: 1.是，但不是只有NAS會用。07/28 12:26
223F推: B的local沒測過就是把環境和repro證明錄下來證明就好了07/28 13:44
224F→: 只要有人環境沒測過就是要找環境或code哪有問題07/28 13:45
225F→: 你能復現就不會是你問題，現在是B除了一開始說有問題後07/28 13:46
226F→: 就不管了，也不提供驗證方法，最後也不複測。07/28 13:46
227F→: 不然就是你復現不了，那也不會有你責任。07/28 13:47
244F推: B的問題不是他的環境，是他自己own的程式爆了還放過的07/28 21:12
245F→: 作為。07/28 21:12
18F推: 看原PO描述，他們公司的UT環境是隨需求在隨時改，而且07/28 10:41
19F→: 沒有側錄機制。(這也好像是常態，除非非常重視SDLC而07/28 10:42
20F→: 且真的實作的公司)，所以出事只能靠嘴巴追責任而不是靠07/28 10:43
21F→: log追蹤開發流程。07/28 10:43
22F→: 而上篇說，B有責任UT自己交出去的東西，他自承沒作（無07/28 10:44
23F→: 論是不是說謊），這樣就一定有責任。差在真的沒作是輕07/28 10:44
24F→: 責，作了故意放過是重責。07/28 10:45
30F→: 自己fail還 commit是有事嗎？07/28 11:26
18F推: 呃，實務上應該大部分作法都是你最後這三行講的。07/28 02:49
19F→: 客戶不願意配合的話，九成九就只能羅生門卡關。07/28 02:50
20F推: 不能復現的Bug常常要靠天眼通...07/28 02:53
27F推: 原PO有說他(Owner)和A去找B，對方不配合。07/28 03:34
28F→: 這大概牽涉到內部人際關係，公司文化改不了無解。07/28 03:35
29F→: 只能每次出包每次找人砍頭了事。07/28 03:35
153F推: 這事背景越補越多XD 可以最困難的永不是技術問題而是政07/28 02:06
154F→: 治手腕。常理來我是支持原PO版本2的想法，如果我開的07/28 02:06
155F→: bug，我看到修正了不太可能忍住不複測。07/28 02:07
156F→: 如果環境複測不出來，事後就會說複測不出來，不會嘴砲07/28 02:07
157F→: 說要用客戶HL問題。07/28 02:07
158F→: 所以真相大概就是複測過真的有問題，然後丟去客戶那看07/28 02:08
159F→: 爆炸。老經驗主管得知後，再幫忙想理由避責。07/28 02:08
160F→: （這種事其實我工作上一年都要碰上幾次，作多了自然知07/28 02:09
161F→: 長官喜歡聽哪些理由來解釋靈異事件。）07/28 02:09
492F推: 其實「之後有人發現網路測試中，LAGG沒有拆掉，導致後07/26 23:47
493F→: 後面一堆測試錯亂，所以『修正』了。」這件事本身就是07/26 23:48
494F→: 警訊，但是除了Manager外大家都會覺得跟我無關。07/26 23:49
495F→: Manager/Owner又不是一線測試人，可能事後調查才知道。07/26 23:49
496F→: 就悲劇了，我是覺得表面上再理想的制度都會有執行面的07/26 23:50
497F→: 問題。07/26 23:50
498F→: 這Bug如果不放過，不管是A/B/QA再測幾年都無法復現。07/26 23:51
500F→: 也是有辦法啦，所以測試都全程側錄，我知道有單位用過07/26 23:54
501F→: 但是太耗時間和資源反而造成開發延宕。07/26 23:55
503F推: 當然，但是「理論上能想起來」實際上是很少有人想起來07/26 23:59
507F→: 所以這個業界有很多無法解釋的靈異故事，除非碰巧找到07/26 23:59
508F→: 原因大家才會「想起來」原來當時作過什麼。07/27 00:00
533F推: QA只作測項沒問題，除非這公司要QA作到自創需求和Spec07/27 07:22