[討論] 寫程式的經驗如何培養?

看板Soft_Job作者 (一隻歐拉貓)時間12年前 (2013/10/29 05:02), 編輯推噓8(8推 0噓 50→)
留言58則, 17人參與, 最新討論串1/7 (看更多)
寫這篇主要是抱怨，每個人就業的成長過程各有不一， 最近帶新人的時候感覺非常挫折，很多我覺得是直覺的 東西，要新人接受的時候，往往受到挑戰，在不想浪費 唇舌的情況下乾脆懶得教了，但是這種新人我也不敢讓他 碰核心原件。 我想要問一下一些寫程式的概念，如果工作中學不到， 有甚麼快速的途徑可以學，因為新人總覺得自己念了 博士，很了不起，寫程式這種簡單的東西，哪有那麼難... 1. 物件的概念，簡單來說就是物件自圓奇說的觀念和 故事，例如一個汽車的物件是不會長出只有汽車自己 存在的時候不能解釋的東西，像是車頂有個不知所謂角架， 這時候只有開汽車就不知道這角架用來幹嘛，如果要如此 設計，就要能夠自圓其說解釋這是一個機槍座，可以 裝哪些種類的機槍，但是新人只是丟了一行comment 寫請看機槍手(UI level)如何使用此角架，但老實說我看 前後文看不懂的時候，這個comment造成我額外負擔必須要 去讀更多的程式 2. 整齊格式的重要性，簡單來說就是一致的coding style， 新人似乎也不在乎這些東西為何重要，但是對老人來說， 這個影響一秒鐘看4行和一分鐘看2行的速度差別，但是對於無法 一秒四行的新人似乎無法理解這有多重要，甚至在hard tab的問 題也能爭吵不休，我已經解釋了每個人的tab width設定不一樣， coverity這類web-based viewer 也會看到不一樣，但是新人 還是堅持只要把tab width設成跟他一樣就好了。這個花了兩個老人 對他勸說了將近30分鐘，但也無法說動他把之前的code用sed 全改成空白鍵 3. 程式命名的藝術，很多人的程式寫得很好，根本不用comment 大家就能看懂，但是有新人就是不知為何發明一些需要解碼的 名稱，還宣稱這很好用很方便 4. Global 滿天飛，尤其在現在重視reentery的時代，global 就算無法避免也希望用singleton替代，但是講了半天又舉例， 最後還是不理你 其實說到最後新人並不是不願意學，而是對於沒有工作經驗的人 ，這些東西就等於沒有道理，講了也不會記得，話說我剛入行 就是前輩說甚麼就照做，把code寫得跟老人一樣，讓他們以為是自 己寫的，但是現在的新人自己想法很多，也不知道怎麼教... -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 198.182.56.5 ※ 編輯: moonshade 來自: 198.182.56.5 (10/29 05:04) ※ 編輯: moonshade 來自: 198.182.56.5 (10/29 05:05)
→
10/29 06:43, , 1F
可以說coding framework/style/readability打考績也會考慮
10/29 06:43, 1F
→
10/29 06:46, , 2F
表示老鳥都很重視，所以也請你重視，花不了你多少時間
10/29 06:46, 2F
→
10/29 06:50, , 3F
他會這麼說就是覺得這應該不重要，不想浪費時間在上面。
10/29 06:50, 3F
推
10/29 07:20, , 4F
我比較好奇的是這個新人到底是怎麼被錄取的...XD
10/29 07:20, 4F
推
10/29 08:04, , 5F
態度有問題，基本上菜就是要服從，除非主管或老闆挺菜鳥
10/29 08:04, 5F
→
10/29 08:04, , 6F
改革，越高學歷的其實有些越難帶，自視甚高
10/29 08:04, 6F
→
10/29 08:09, , 7F
開除他？
10/29 08:09, 7F
→
10/29 08:38, , 8F
我覺得3.要體諒一下,不是每個人英文都好,keyword很難取XD
10/29 08:38, 8F
→
10/29 08:43, , 9F
菜就是要服從 XD? 是來寫程式還是當兵?
10/29 08:43, 9F
→
10/29 09:01, , 10F
名稱也不是很好取的. 不過溝通一下就好,強制要求
10/29 09:01, 10F
→
10/29 09:01, , 11F
人家會認為,為什麼你的比較好? 為什麼不能用我的,你一定
10/29 09:01, 11F
→
10/29 09:02, , 12F
是對的嗎? 不過,老人也不一定是對的,口氣別太差.
10/29 09:02, 12F
→
10/29 09:03, , 13F
至於coding style,每個人都有自己的風格,要求一致,難~~~
10/29 09:03, 13F
→
10/29 09:04, , 14F
講多了,只會造成同事間的不和諧. 不過,稍微提一下,是個不錯
10/29 09:04, 14F
→
10/29 09:05, , 15F
法,用建議的口氣. 會比較好.
10/29 09:05, 15F
→
10/29 09:06, , 16F
如果不想改,其實老人要有能力看奇奇怪怪的code ,就認了
10/29 09:06, 16F
→
10/29 09:16, , 17F
style公司要定自己的規範阿 否則當然各寫各的
10/29 09:16, 17F
推
10/29 10:31, , 18F
Style就是要統一規定下去,也有一堆工具幫忙.設定好CI工具
10/29 10:31, 18F
推
10/29 10:31, , 19F
@bndan 一間公司本來就要一個規範，前人都認同那套規則，
10/29 10:31, 19F
→
10/29 10:31, , 20F
結果一個新人來搞破壞?就算那個規則不好，要嘛就是讓老
10/29 10:31, 20F
→
10/29 10:31, , 21F
闆或上面認同，然後進行改革，要嘛就認菜自行離開，是環
10/29 10:31, 21F
→
10/29 10:31, , 22F
境要來屈就你，還是你來屈就大環境?再者你現在改規則，
10/29 10:31, 22F
→
10/29 10:31, , 23F
光重構又要花多少時間??菜還不服指導本來就該死
10/29 10:31, 23F
→
10/29 10:32, , 24F
不符合規範的程式就不准Checkin,然後這種狀況就會沒了
10/29 10:32, 24F
→
10/29 10:33, , 25F
很多程式style是設計用來減少bug發生以及debug時間的
10/29 10:33, 25F
推
10/29 10:40, , 26F
看到這篇所以我就不想待軟體公司
10/29 10:40, 26F
→
10/29 10:42, , 27F
有不配合的新手(我沒說他不對)有倚老賣老的老手
10/29 10:42, 27F
→
10/29 10:42, , 28F
(老手也沒錯)
10/29 10:42, 28F
→
10/29 10:44, , 29F
人沒錯那就是環境問題 鬼島軟體公司....?
10/29 10:44, 29F
推
10/29 10:59, , 30F
我覺得是程式員對自己的要求不高。無法體會你的期待。
10/29 10:59, 30F
→
10/29 11:00, , 31F
我覺得程式寫得可以動是目前多數程式員與公司的最低標準
10/29 11:00, 31F
→
10/29 11:00, , 32F
但若自己對自己的要求高，就會懂得多去涉獵design patte
10/29 11:00, 32F
→
10/29 11:01, , 33F
物件導向、可再利用、易讀性等品質要求。
10/29 11:01, 33F
→
10/29 11:03, , 34F
我的經驗是新進人員，低子不一定不夠，開讀書會探討案例
10/29 11:03, 34F
→
10/29 11:04, , 35F
或定期code review，分享程式碼的優缺。這樣的方式比較
10/29 11:04, 35F
→
10/29 11:04, , 36F
以循循善誘的方式引導出"程式碼品質"的概念.
10/29 11:04, 36F
→
10/29 11:06, , 37F
另外其實啊，程式員多半認為自己是高知識分子，所以多半
10/29 11:06, 37F
→
10/29 11:06, , 38F
有文人相輕的心態。若你的"級數"沒高到一定程度，沒在專
10/29 11:06, 38F
→
10/29 11:07, , 39F
業上完全壓倒新人。用直接說的方式對方也不一定會採納.
10/29 11:07, 39F
推
10/29 11:08, , 40F
規範問題，除非是要開發新專案，上面認同改變，一間公司
10/29 11:08, 40F
→
10/29 11:08, , 41F
的系統，不同模組寫法完全不同，這樣的系統好嗎?尤其一
10/29 11:08, 41F
→
10/29 11:08, , 42F
個新人又不是主管缺，無法配合別人，難道要大家來配合這
10/29 11:08, 42F
→
10/29 11:08, , 43F
位新人嗎?
10/29 11:08, 43F
→
10/29 11:13, , 44F
同意樓上是規範問題。有高階主管的支持其實就follow就對
10/29 11:13, 44F
→
10/29 11:49, , 45F
公司規定的coding style最好有軟體可以直接整理！(誤)
10/29 11:49, 45F
→
10/29 12:09, , 46F
公司會提供軟體，但是有歷史的product通常會敬謝不敏Orz
10/29 12:09, 46F
→
10/29 12:09, , 47F
我們之前也想推，但是大家覺得没意義所以就沒動
10/29 12:09, 47F
→
10/29 23:03, , 48F
@K大 規範要合理 不然跟軍營一樣進去被老鳥打幾拳這種"傳統"
10/29 23:03, 48F
→
10/29 23:04, , 49F
也要遵守? 無知的默守成規這種鳥事 不該出現在軟體界好嗎?
10/29 23:04, 49F
→
10/29 23:05, , 50F
code style好 就是可以解釋的出來.講難聽的我現在寫的也是尊
10/29 23:05, 50F
→
10/29 23:06, , 51F
造我公司的規則...但這套規則因為"對我"來說合理 所以我甚至
10/29 23:06, 51F
→
10/29 23:07, , 52F
直接融入我私人的CODE內.更別說去反抗他了 好的就是好的 沒
10/29 23:07, 52F
→
10/29 23:08, , 53F
辦說服=對方無理? 如果是這樣 那只能說強摘果實不會甜 (攤手
10/29 23:08, 53F
→
10/29 23:19, , 54F
最後一段深有同感~
10/29 23:19, 54F
→
10/30 00:07, , 55F
我倒是遇到老鳥的code跟文中說的菜鳥code一樣
10/30 00:07, 55F
推
10/30 00:52, , 56F
說到我心聲...
10/30 00:52, 56F
→
10/31 06:54, , 57F
對我而言，改coding style開始時也很掙扎，後來就習慣了
10/31 06:54, 57F
→
10/31 06:55, , 58F
不願學或不會學的，會像我一樣被淘汱
10/31 06:55, 58F
‣ 更多 moonshade 的文章
文章代碼(AID): #1IRj3fvU (Soft_Job)
討論串 (同標題文章)
以下文章回應了本文 (最舊先)：
完整討論串 (本文為第 1 之 7 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共7篇)
‣ 更多 moonshade 的文章
文章代碼(AID): #1IRj3fvU (Soft_Job)