Re: [心情] 前輩拒絕導入任何其他工具....

看板Soft_Job作者zanyking (最後的六年級生)時間10年前 (2014/05/20 12:34)推噓8(8推 0噓 23→)

留言31則, 13人參與討論串26/27 (看更多)

※ 引述《leoace (leoace)》之銘言： : 引述電影寒戰的台詞: : 每一個機構，每一個部門每一個崗位都有自己的遊戲規則。不管是明是暗，第一步學會它 : ，不過好多人還沒有走到這一步就已經死了，知道為何？自以為是。 : 第二步，就是在這個遊戲裏面把線頭找出來，學會如何不去犯規，懂得如何線上球裏面玩 : ，這樣才能勉強保持性命。保住性命？你是來寫程式的，不是來演戲的，推個新技術而已不給推你把我開除嘛。是能槍斃我？工作就是這裡有我要的，那我就忍著待著追求著，沒有你不開我我自己也會走。那問題是：你如何定義你自己？你是個程式設計師，還是只是個『幫別人寫程式的』？ : 結論: 你要在無論在軟體界或在其他環境生存，一定要學會明的或暗的規則。每個環境都 : 有它的遊戲規則，搞清楚規則再玩，才是明哲保身之道。這種想法就是問題，想要明哲保身沒有錯，只是你的底線在哪裡？如果沒有底線，那這工作就不是什麼個軟體工程師，而只是個需要有人來寫程式的。我如果當個『被找來寫程式的』當得很開心，那是我個人選擇，我可不會大聲嚷嚷跟新入行的菜鳥說『這也該是你的選擇』。出來混就要還，人希望有一天做自己尊敬的工作，希望有一天不論大小能做出一番成績，那有些事情就不能妥協，然後機會成本要會算。人如果還年輕、沒有一家老小牽掛，這麼會算那些冥摺飽身的東西是幹嘛？還年輕，該考慮的東西就只有一個：這到底可以對user有多少貢獻？這些user你根本無法認同，那這工作你就不該做。這間公司只剩下還活著，那老闆不趕你你都該自己走。當繼續下去要求你冒險，那戰勝恐懼就是你保有自尊的唯一方法。 : 進公司沒多久，應該要把公司遊戲規則搞懂，有時候軟體會用這種管理方式是有它的歷史 : 因素存在的，也許一隻程式經手好幾十人，一段程式碼可能是因為專案評估錯誤造成要 : 加班努力趕出來；也有可能是相同模組賣給不同客戶但介面不同，功能需要客製化等因素 : 造成你現在看到的結果。你看到的是結果，就說這個管理不好，這個要改、架構要改... : 老鳥大概會覺得這樣的新人是自以為是 : 所以進公司第一件事情就是把請把線頭找出來，學會在這一個遊戲規則下生存，在你可以 : 掌控的資源中來進行你覺得應該要做的事情同意啊，但這種事情是互相的，你進公司向公司學習、公司僱用你用你的產出賺錢。當發現看似不合理的東西，當然要找出來到底這為何如此。因為歷史因素妥協很多時候也是不得不然。但這東西不是沒有代價、也不會沒有計算。天下什麼東西最貴？時間最貴一間公司可以為他目前所有的潛規則找出充足的理由。但只要這間公司這個部門跟外界、跟競爭對手比起來就是沒有效率，這些理由就通通都是藉口、通通都可以是屁話。要不要把自己的生命，也就是時間，繼續奉獻給這個已經沒有機會贏的東西，人當然也可以找各種理由，但，當人不相信卻還繼續去做的時候，這些理由都是藉口。即使到最後瞎貓碰上死耗子，這公司不曉得為啥起來了，這人于其中也是一點好處也沒有的。人今天可以碰運氣得到，某天就要隨機的被掠奪。 : Ruby on Rails在web application framework生產力比JSP高出30%，這樣為什麼一堆公司 : 還在用JSP開發呢? 維運成本跟資源的掌控才是大部分的公司考慮的重點。你光要換掉JSP : 後端，除非你是主管有勇氣承擔替換過程的混亂時期，不然你就提個所謂的 : "加速後臺生產力執行計劃書" 並且提出WBS(Work Breakdown Structure)，以專案 : 執行的方式來看待此事，以專案管理的做事方法來進行此事，你就是此計劃書的PM， : 因此你要做的事情要有:計畫、時程、資源分配、風險評估、預期效益、Staffing Matrix : (就是誰要負責哪件事情)、教育訓練、範圍為何等諸多任務以及其解構之後的工作細項。 : 在執行的過程中要有高度的意志力來貫徹此專案一定要成功，不然也是嘴砲而已。 ROR 比 JSP高30%，那得看你後端銜接什麼系統。你後端就是接Java EE，團隊編制超過50人，那ROR討不了什麼便宜。 : 引述電影寒戰的台詞: : 基於一個片面分析，沒經過嚴密的邏輯推算。浪費你們的寶貴時間是不是很興奮啊， : 等你坐上我的位子，你就會心裡有數。我沒看過那部電影，但這邊有嚴重的基本假設不適用的問題。以作商用開發的團隊來說，今天導入一個技術，失敗了會死人嗎？或者說，失敗是能失敗到哪裡去？時間Buffer 開大一點，找團隊中的快手下去作POC出來，幾個主要的Architect 從各自專擅的領域去review過一遍，就可以看要不要推了啊。這又不是什麼Rocket science，講難聽點，有需要做到這麼複雜的衝擊影響評估的新技術導入，台灣沒幾個領域有需要這樣搞拉。我可以想到的只有高鐵的機電整合自動控制，這種有複雜的訊號控制配上軟及時需求的，但這太不算一般商用開發的領域吧？能碰上最頭痛的就是效能跟安全性，阿一個新技術一旦知道是做什麼的，會打到哪裡能打多痛，當Architect的不能明確地提出模型senior們一起來看，這還叫Architect 嗎？有辦法的人，是會把很複雜的東西用很簡單的模型掌握，清楚地掌握概念邊界後，去提升周圍的人對問題的理解的。而不是擺老、講得不清不楚然後嚇唬新人。 : 這不是一個新人說我覺得這個很好，所以後我們就全部換成這種管理模式，這麼簡單 : 再來講維運成本: : 會JSP比RoR的人可能是好幾10倍，在人力市場上要找到可以立即上工的人機率很高， : 加上如果案子從研發轉移至維護單位，駐點也許只要學Apache以及網頁的基本設定以及 : 依照安裝手冊跟問題排除程序就可以保持良好的維運狀態，因此聘請駐點工程師的成本 : 就會降低。要是你換掉了，萬一負責開發的人離職了，可能替代的人要在人力市場上找 : 很久還不見得找到可用的人。還有一個是開發工具的成熟度，以及語言能否支援，這點Java是強到爆炸的。 : 因此有些主管會要求說程式不要寫太難，因為接你的人會看不懂也是一樣的道理程式沒有難或簡單，只有恰如其分的安排，還有製造的問題比產生的價值小得多。當需求就是要求這樣水準的架構設計時，你該做的不是讓架構設計去遷就看不懂的人，而是讓看不懂的人提升到看得懂。這重點在於，標準在那裡？你的設計真的是『恰如其分』嗎？我的經驗是這只有設計被挑戰過才能證明，這就是為什麼需要code review還有pair programming的部分原因。大家坐下來大亂鬥，你提出的點別人同意這重要，也找不到其他更好的解法，那就是這樣了。而這六七年長久觀察下來，我是覺得大部份的情況沒有所謂的『太難』，只有無謂的複雜度可以砍掉。 : 你用 git SVN想要取代舊有的專案以及軟體維護方式，也許這一套軟體在客戶端已經安裝 : 上千套，程式可能在幾十年的開發下已經在既有的管理模式運作得好好的，要改變的話 : 在初期光commit跟版本分類就需要討論很久了，替換計畫為何? Role & Responsibility? 換VCS跟產品安裝多少套沒有關係。以Git SVN來說，不論是直接切換還是混用都有人做過，也都有既有套裝方案。真正的困難在於工作模式的改變，Git 鼓勵用branch，要習慣SVN的人接納狂開Branch 測試各種不同方案的思維是最花時間的部分。 : 老鳥有很高的機率在趕案子，對老鳥來說維持現有的模式一定是風險最小，而且你忽略了 : RD的主要工作不是這個，是 "產出"，長期來看這個投資是值得的，但是需要有一個計畫 : 來完成，你確定你的主要工作(main job)是這個? 還是coding? 你的KPI有這一項嗎? : 如果你跟你同事的KPI都沒有，請問誰要來幹這件事情? : 另外有這樣的想法很好，但想法最終還是要回歸執行力，因為用嘴寫程式永遠比實作來的 : 容易。你要實力足以讓同事以及主管認可，如果沒有的話，那還是在你可以掌控的資源中 : 進行你覺得應該要做的事情。例如: 自己的程式自己管，同時也讓你同事知道你在做 : 可能改天同事突然性情大開，希望能跟你一起改造這個巨大的程式怪獸這就是個人考量了：到底這間公司值不值得你花這樣的心血陪他玩。就我來說，如果是之前那位原PO舉的例子： SVN to Git藉口一大堆，還是什麼JSP裡面可不可以用EL的要參詳個半天的，我不會。我不覺得自己的生命值得這樣浪費，而基於我希望台灣的軟體產業可以更好，我也不會認同要『年輕開發者們應該繼續把生命花在這種公司上頭是合理的』這種言論。隔了五年，好不容易網路輿論終於倒向認同『一間軟體公司一定會有VCS』。我覺得是時候該往下一個milestone推進了。殺豬公也殺得夠了吧？也許還上不了太空，但起碼沖天炮先放個兩支如何？ -- 生命起源於簡單的化學反應，靈魂是腦神經上頭的火花。掌紋沒有含意，不過是具有止滑功用的紋路。而神不存在，死去的人們只是等待細菌分解的腐肉而已。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 59.115.103.219 ※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1400560499.A.7EE.html

推

lovdkkkk

05/20 12:43, , 1^F

05/20 12:43, 1^F

推

a47135

05/20 12:43, , 2^F

05/20 12:43, 2^F

→

a47135

05/20 12:44, , 3^F

05/20 12:44, 3^F