[環境] 嘴砲型的強者...

看板Soft_Job作者 (gibberish)時間9年前 (2015/04/16 23:52), 9年前編輯推噓43(44推 1噓 121→)
留言166則, 47人參與, 最新討論串1/9 (看更多)
工作也有六七年了，幾份工作都遇過類似的人， 這樣的人有種特質，想問問大家的意見。 嘴巴上很厲害，常常沒聽完別人說話， 就急著接話，接一些英文之類的，讓大家突然錯愕， 然後接不下去，或者是怕自己不懂被發現。 XX部落客，XX聚會，都參加很多， 所見也很廣，可是明明團隊是在開發APP， 他一直拿SPRING架構出來說嘴，一開始覺得肅然起敬， 可是後來自己研讀一下覺得這不是對網頁幫助較大嗎? 或者是在app裏頭，用了DAO的設計模式 (這不是資料庫才需要這樣嗎@@) 當然，所見廣泛是很好，可是跟這樣的人討論事情， 常常會岔題，到最後總是不在重點上。 我的類型是，寫code邏輯還不錯(同事有認可啦) 主管交代工作就是追求速度完成，比較不會去 參加一些讀書會，或者是看一些新設計方式，重構等等文章。 所以開會要論述的時候感覺比較少可以拿出來嘴砲的， 我這類型的人也不少，主管反而愛用我們這樣的， 因為交代事情可以在短時間內完成。 嘴砲型的人有趣的地方是，嘴巴很會說， 開會總讓人感覺他思考了很多面向，什麼新技術新工具都去試過， 可是開發速度總是很慢，寫code邏輯也不見得就清晰。 真正遇過讓全TEAM的人都敬佩的強者， 也沒有說常常去看一些設計模式什麼， 因為就像是金庸裡的"九陽神功"，"獨孤劍法"這類型的功夫， 主要是融會貫通，設計模式是別人的建議， 自己考慮夠縝密，經驗夠豐富，也不需要老是套用別人的設計模式， 然後去抨擊同事說"你這樣用不對啦~" 我想問一下大家，要成為真強者， 真的需要一直去把這些新觀念文章研讀到可以拿出來唬人嗎? 聽聽各位的看法? 成為強者之路...感到迷惘~ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.224.193.248 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1429199571.A.0B9.html
推
04/16 23:55, , 1F
要搭配實力很有用 沒實力要進度時馬上就破功了
04/16 23:55, 1F
推
04/16 23:55, , 2F
逛書局看到的書，很多都寫嘴砲的這種才會有發展
04/16 23:55, 2F
→
04/16 23:56, , 3F
spring的確有android 版本的
04/16 23:56, 3F
→
04/16 23:56, , 4F
dao也是很常見不是？ ormLite 跟greenDao 都有dao啊
04/16 23:56, 4F
→
04/16 23:57, , 5F
設計模式不需要刻意去用它,它幫你解決一些問題而已
04/16 23:57, 5F
→
04/16 23:57, , 6F
或是讓你維護起來更為方便,寫程式更不容易出錯
04/16 23:57, 6F
→
04/17 00:01, , 7F
不過spring 不太適合在android運作,他會影響效能
04/17 00:01, 7F
→
04/17 00:02, , 8F
到底你還是多看書吧！spring也有mobile的應用，另外不是
04/17 00:02, 8F
→
04/17 00:02, , 9F
準時完工就叫好，那找大學生也能做，要你六七年經驗要幹
04/17 00:02, 9F
→
04/17 00:02, , 10F
嘛？
04/17 00:02, 10F
我當然也知道spring可以用在android上，我要討論的不是這個， 但是老闆要的就是準時交件，這時該怎麼取捨? 大學生能準時完工又有品質? 難怪我遇到一些朋友都說:阿不是大學生也會寫APP 你這樣的說法也實在是外行吧...
→
04/17 00:06, , 11F
dagger/butterKnife/androidannotations都是設計給
04/17 00:06, 11F
→
04/17 00:06, , 12F
android專用的,請問你有瞭解過這些嗎？
04/17 00:06, 12F
→
04/17 00:07, , 13F
好的架構可以讓teamwork 更為順利,因為code更清晰簡便
04/17 00:07, 13F
這又是我另一個問題，我待過的公司，也不乏有名的大公司， 你說的這個是很理想化，可是真正做到的有幾家公司呢? 如果要真的照嚴謹軟體開發流程，會拉長開發時間， 一般公司可以這樣燒錢嗎? 當案子真的趕的時候， 就是憑經驗硬幹，我想請問你了解這些了，是否真的有嚴謹的去用呢? 我待過的公司(三大電信商之一)誇張到連SVN都沒用， 版本控管只有丟上某台server，按照日期資料夾備份而已 我相信這是很常見的情形阿，所以看了那麼多書，那麼多工具與觀念， 那真正實際用到的有多少? 可以真正幫助到開發又有多少? 如果有人的公司是真的完全照書上的開發流程， 很希望可以聽到這樣的分享~
推
04/17 00:08, , 14F
跪求Sample讓我抄T_T
04/17 00:08, 14F
→
04/17 00:09, , 15F
你可以試著用用看一些框架,熟了你更容易開發跟除錯
04/17 00:09, 15F
→
04/17 00:09, , 16F
他也許沒實作能力 但不表示那些設計模式無用
04/17 00:09, 16F
→
04/17 00:10, , 17F
不是快就好,沒設計程式越寫越雜亂
04/17 00:10, 17F
→
04/17 00:10, , 18F
半杯水心態 了解那些觀念對你的設計有幫助
04/17 00:10, 18F
推
04/17 00:15, , 19F
左邊跟右邊 你比較一下,請問哪個好維護跟開發快？
04/17 00:15, 19F
→
04/17 00:15, , 20F
04/17 00:15, 20F
推
04/17 00:18, , 21F
又老又大的公司的確有包袱, 但是你自己試過design pattern
04/17 00:18, 21F
→
04/17 00:18, , 22F
之後, 就會了解用不用差在哪
04/17 00:18, 22F
糟糕，好像變成我在反設計模式了，不是這個意思啦， 我自己也很認真在研究設計模式，我知道那是前人智慧結晶。 比較像是Deltaguita提出的那個例子，如果今天又出了新工具， 雖然可以比較好維護，比較好閱讀，可是多數人都已經習慣了一般方式， 知道了這個方法又如何? 我的前公司連要推行換到GIT都很困難了， 而且就算知道這些工具，基本觀念還是最重要的，記憶體控管， 線程安全才是經驗價值所在吧? ※ 編輯: abysmal (36.224.193.248), 04/17/2015 00:24:22
→
04/17 00:19, , 23F
寫程式也沒說非要套什麼模式不可
04/17 00:19, 23F
→
04/17 00:20, , 24F
至少你多懂一些, 可以少一些try & error 的成本
04/17 00:20, 24F
→
04/17 00:22, , 25F
一些平常的武功是需要套拳路的 看起來很沒用 但實際上打架
04/17 00:22, 25F
推
04/17 00:23, , 26F
要體會他的好處需要一些經驗, 如果永遠寫code都是一本道的人
04/17 00:23, 26F
→
04/17 00:23, , 27F
時你的身體就會自己動起來(練刺槍術的功能同)...
04/17 00:23, 27F
推
04/17 00:23, , 28F
我聽前輩說這些都是 PM 跟SA的料
04/17 00:23, 28F
→
04/17 00:23, , 29F
當然不會知道所謂的高內聚/ 低耦合/ 抽界面做什麼用
04/17 00:23, 29F
→
04/17 00:24, , 30F
我覺得你打心底排斥設計樣式跟框架
04/17 00:24, 30F
這句話何來? 我很努力在框架上研究，設計模式也常用， 我並不是像多數大學生只會一條龍式的寫法好嗎? ※ 編輯: abysmal (36.224.193.248), 04/17/2015 00:28:00
→
04/17 00:26, , 31F
我舉的東西是絕對知名而且超級好學的
04/17 00:26, 31F
→
04/17 00:26, , 32F
連這都看不懂,說真的......
04/17 00:26, 32F
推
04/17 00:28, , 33F
因為不懂就說別人打嘴砲嗎...
04/17 00:28, 33F
又在說別人不懂...反正一定要這樣酸來酸去，我懂:P ※ 編輯: abysmal (36.224.193.248), 04/17/2015 00:28:56
推
04/17 00:29, , 34F
大公司的確要遷就舊有的流程, 沒辦法推這些
04/17 00:29, 34F
還有 92 則推文
還有 3 段內文
推
04/17 12:34, , 127F
"自己..夠..不需要...別人的"<< 聰明人從別人的經驗學習
04/17 12:34, 127F
→
04/17 12:54, , 128F
感覺原PO只是不想從弱者那裡獲取經驗...
04/17 12:54, 128F
推
04/17 13:14, , 129F
對付嘴炮型強者還不簡單, 就一句:[你講完可以走了吧?]把他
04/17 13:14, 129F
→
04/17 13:15, , 130F
打發掉不就得了?
04/17 13:15, 130F
→
04/17 13:16, , 131F
他只是在發抱怨文而已
04/17 13:16, 131F
→
04/17 14:19, , 132F
不是什麼都得套設計模式..這個叫被程式玩,不是玩程式
04/17 14:19, 132F
→
04/17 14:41, , 133F
標準討拍XD
04/17 14:41, 133F
推
04/17 14:59, , 134F
你只是還沒看過真正的強者才會有這種迷惘啦
04/17 14:59, 134F
→
04/17 14:59, , 135F
基本上設計模式是拿來溝通的，不是拿來把人弄糊塗的。
04/17 14:59, 135F
→
04/17 15:00, , 136F
另外真正的強者在學新東西而要引入團隊的時候是非常謹慎的
04/17 15:00, 136F
→
04/17 15:00, , 137F
如果為了新東西反而影響交件時程，這肯定是有問題的。
04/17 15:00, 137F
→
04/17 16:00, , 138F
你同事不是也有把 code 寫出來嗎 各自有追求 何必上網抨擊
04/17 16:00, 138F
→
04/17 18:24, , 139F
既然樓主受到主管重用，何須來這邊問問題呢？
04/17 18:24, 139F
推
04/17 20:36, , 140F
我覺得關係好像不明顯 我覺得強的低調跟高調都各參半
04/17 20:36, 140F
→
04/17 20:36, , 141F
弱的也是
04/17 20:36, 141F
→
04/17 21:30, , 142F
高手高手，請問物件導向程式該怎麼寫
04/17 21:30, 142F
→
04/17 21:30, , 143F
我這個功能該怎麼設計比較好呢
04/17 21:30, 143F
→
04/17 21:30, , 144F
高手:寫的有彈性好擴充阿
04/17 21:30, 144F
→
04/17 21:31, , 145F
又或是:你這邊可以用XX pattern，這邊用XXX
04/17 21:31, 145F
→
04/17 21:31, , 146F
就算你不知道那個pattern是啥，也可以去查，就不用高
04/17 21:31, 146F
→
04/17 21:31, , 147F
手寫一個sample給你看了
04/17 21:31, 147F
推
04/17 21:44, , 148F
你的工作是重複解已知的問題，所以可以一招用六年
04/17 21:44, 148F
→
04/17 21:45, , 149F
遇到開創性的工作解未知的問題，廣泛的接觸就可以發揮
04/17 21:45, 149F
→
04/17 21:45, , 150F
所以也沒有對錯吧，看場合而定
04/17 21:45, 150F
推
04/17 22:33, , 151F
寫code邏輯不清晰有一種是你看不懂唷
04/17 22:33, 151F
→
04/18 01:12, , 152F
真強者就有辦法電嘴炮型的, 電不了表示也沒差多少,不用爭
04/18 01:12, 152F
推
04/18 09:58, , 153F
原po似乎工作經驗不多?或待的公司不夠多?
04/18 09:58, 153F
噓
04/19 09:35, , 154F
怎大家都模糊焦點...我覺得嘴砲型實作GG就酸回去就好
04/19 09:35, 154F
→
04/19 09:35, , 155F
，而且也不一定嘴砲無用，有時候聽完嘴砲自己也會有
04/19 09:35, 155F
→
04/19 09:35, , 156F
更好的solution
04/19 09:35, 156F
→
04/19 10:44, , 157F
與別人相較下的功能/開發速度比率,與其它當代產品的完
04/19 10:44, 157F
→
04/19 10:46, , 158F
整度比較,功能數/bug數的比較,比較像功力強不強的指標.
04/19 10:46, 158F
→
04/19 10:49, , 159F
嘴炮型的人比較容易牽著別人走,但時間一久強不強也是
04/19 10:49, 159F
→
04/19 10:49, , 160F
看得出來的...
04/19 10:49, 160F
→
04/19 12:51, , 161F
推@sayya2311大的指標
04/19 12:51, 161F
推
04/21 01:08, , 162F
超受不了 遇到問題叫你自己Google 別問他的主管
04/21 01:08, 162F
→
04/22 03:00, , 163F
但遇到連Google也不會也要問人(或主管)的人這也不用hire
04/22 03:00, 163F
推
04/23 00:25, , 164F
推原po~深有同感
04/23 00:25, 164F
推
02/20 11:35, , 165F
如果是管理層,這其實是必須的,執行的人跟找方向的人本
02/20 11:35, 165F
→
02/20 11:35, , 166F
本來就有自己各自的工作
02/20 11:35, 166F
‣ 更多 abysmal 的文章
文章代碼(AID): #1LBzhJ2v (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文 (最舊先)：
完整討論串 (本文為第 1 之 9 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共9篇)
‣ 更多 abysmal 的文章
文章代碼(AID): #1LBzhJ2v (Soft_Job)