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

看板Soft_Job作者 (Davis)時間10年前 (2014/05/17 19:55), 編輯推噓10(10推 0噓 27→)
留言37則, 10人參與, 最新討論串2/27 (看更多)
我不覺得自己算前輩， 不過有幾個地方你可以自己思考一下就知道原因了， 1.相依性管理 以前大家確實都用ant或其他方式， 所有的專案都有各自lib造成管控困難， 你或許想用maven或gradle之類的工具協助， 要馬你的主管支持你進行改變， 不然就是你的能力強到"讓"別人認可， 否則為何要因為你提了什麼意見， 就要求大家跟著你學習或者是改變現行的模式， 之前有一些新手在板上討論code standard或coding style的問題， 其實也是相同的道理。 2.EL的問題 如果你的專案有用到struts1、struts2、springMVC等等之類的， 有框架自己的標籤就用框架的， 不要再混雜EL、JSTL等等有的沒的， 當然你自己會你看得懂沒問題， 但請你思考接手以及之後維護或者是多人開發的環境， 如果今天原本的spring專案大家都用XML配置， 突然有人用annotation的配置， 難道不覺得這樣很亂嗎? applicationcontext裡面配置的bean不是全部的bean， 或許你自己很上進覺得有新東西可以學馬上google， 但如果每個案子每個使用的套件大家都各自這樣搞， 每個人當然都可以說得出一番理論， 你有覺得這樣比較好嗎? 3.個人小建議 你所謂的彈性、方便、進步， 只是因為你會了新東西想用， 你自己習慣了而已， 不能要求別人跟你一起習慣， 如果今天你工作了三年， 來了一個新人會ROR或PHP， 說我們原本的開發速度太慢了巴拉巴拉， 全面換掉大家重頭學起PHP或Ruby， 你會覺得自己的團隊有彈性、開發更方便、更進步了嗎? 最後， 如果你看完以上三點還是不懂的話， 直接跟你講最關鍵的， 有能力，你就找更好的，你想要的環境， 不然就是，等有一天，老闆或主管來問你， 請你給意見的時候， 你再來給建議， 不然別人只是覺得你在耍猴戲而已， 相信我，你到每一家公司都是這樣， 就算你現在去都用了最新的東西， 幾年後也不可能一直跟著市場上更新， 難道JAVA 1.8出了好多新的更好用的東西， 專案就要全面汰換嗎? 難道jQuery1.9出來後， 專案用的jQuery1.8.3就要換掉嗎? 我相信以你的智慧， 用膝蓋想就知道答案了。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 61.231.26.222 ※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1400327738.A.1F8.html
推
05/17 19:58, , 1F
推 尤其第2點 雖然某些東西也許有好處 但是加入一個projec
05/17 19:58, 1F
→
05/17 19:59, , 2F
t請先照那個project一致的作法(ex:coding style...) 有要
05/17 19:59, 2F
→
05/17 19:59, , 3F
改變的不是不可以 請取得大家一致的共識 並評估影響
05/17 19:59, 3F
推
05/17 20:05, , 4F
我明白你的意思,要推動改革的關鍵在執行者累積的信譽
05/17 20:05, 4F
→
05/17 20:06, , 5F
還有大家的想法與共識
05/17 20:06, 5F
推
05/17 20:07, , 6F
丟給上面決定 可以就可以 不行就算了
05/17 20:07, 6F
→
05/17 20:07, , 7F
那請問大家,要怎麼讓組織上層意識到現行做法有些問題?
05/17 20:07, 7F
→
05/17 20:08, , 8F
有在寫程式的前輩不支持, 更上層的平常不寫程式
05/17 20:08, 8F
→
05/17 20:09, , 9F
請問現行系統有掛掉嗎？還是開發時程慢到你們每天加班
05/17 20:09, 9F
→
05/17 20:10, , 10F
加不完，都沒有的話，請問你要給他們看的問題是什麼？
05/17 20:10, 10F
→
05/17 20:10, , 11F
這樣意思是只能耐心等到重大有感問題出現才能趁機提議嗎
05/17 20:10, 11F
→
05/17 20:11, , 12F
現在是不大的問題都要稍微加點班,以後專案膨脹怎麼辦?
05/17 20:11, 12F
→
05/17 20:12, , 13F
處理問題要防微杜漸, 我是這樣想的
05/17 20:12, 13F
→
05/17 20:13, , 14F
就像土法煉鋼可以做破鐵器,不是無產值,但長遠不是好方法
05/17 20:13, 14F
推
05/17 20:33, , 15F
你要在小型專案先嘗試~先教大家幫助大家學習~
05/17 20:33, 15F
→
05/17 20:34, , 16F
習慣使用後才會接受
05/17 20:34, 16F
推
05/17 20:39, , 17F
重點是原原po要怎樣讓別人知道你的方式是好得
05/17 20:39, 17F
→
05/17 20:40, , 18F
然後轉換需要多少成本能評估嗎？
05/17 20:40, 18F
→
05/17 20:40, , 19F
導入任何東西都是要成本的，如果造成專案延誤該怎辦
05/17 20:40, 19F
→
05/17 20:41, , 20F
能夠給出確實的sop並且教會大家嗎？
05/17 20:41, 20F
推
05/17 20:41, , 21F
等到大家慢慢發現好處後~ex專案提早完成or提早下班
05/17 20:41, 21F
推
05/17 20:43, , 22F
有實質的利益才能使人有動力
05/17 20:43, 22F
→
05/17 20:44, , 23F
還有你要確保不會影響時程
05/17 20:44, 23F
推
05/17 20:50, , 24F
原原PO總是說自己懂別人的觀點.但是真得懂?還是假裝懂?
05/17 20:50, 24F
→
05/17 20:52, , 25F
建議原原PO把改變可能產生的問題、時間成本、風險、好處..
05/17 20:52, 25F
→
05/17 20:54, , 26F
都考慮詳盡,再往上呈報.記住,是改變可能帶來的所有影響
05/17 20:54, 26F
→
05/17 20:55, , 27F
而不是片面所改這樣的好處是什麼,我相信改變不一定只有好處
05/17 20:55, 27F
→
05/17 20:56, , 28F
一定會帶來其他影響,如果你能把這些影響,都考慮周全,且有
05/17 20:56, 28F
→
05/17 20:57, , 29F
妥善的應對方法,再來說.土法煉鋼破機器.新方法一定好機器吧
05/17 20:57, 29F
→
05/17 21:00, , 30F
我以前要推新東西時,也會一併想其他影響的解決方法.供參考
05/17 21:00, 30F
推
05/18 07:12, , 31F
真的 職場上就是這樣 做人永遠比做事重要
05/18 07:12, 31F
推
05/18 08:14, , 32F
[改變]會有陣痛期 這段期間會有些狀況發生 若主導者沒有足夠
05/18 08:14, 32F
→
05/18 08:15, , 33F
的充份評估以及下定決心幹到底的話 中途失敗會很難看 會黑掉
05/18 08:15, 33F
→
05/18 08:15, , 34F
主管要有自己的定見 可不能被其他人你一句我一句的牽著走啊~
05/18 08:15, 34F
→
05/18 16:14, , 35F
我只想問 像JQUERY就好...因為升級沒有用而不升級 那未來3年
05/18 16:14, 35F
→
05/18 16:15, , 36F
後還是繼續"3年前"的舊版? 何必把事情擠在同時間點做呢= =
05/18 16:15, 36F
→
05/18 16:16, , 37F
還是乾脆跟傳產一樣 反正沒被洮汰就再戰10年 這樣XD?
05/18 16:16, 37F
‣ 更多 d1288999 的文章
文章代碼(AID): #1JTquw7u (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文：
完整討論串 (本文為第 2 之 27 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共27篇)
‣ 更多 d1288999 的文章
文章代碼(AID): #1JTquw7u (Soft_Job)