Re: [問題] 請推薦「防老化」的遊戲～

85 

繼上集, 朋友被指導教授要求給博後論文草稿和實驗程式碼之後, 朋友除了使用推文有建議的拖,慢,等戰術讓博後拿不到, 78博後對我朋友出了新招,

75 

那葛分AB池的雲端發票抽獎啦 程式碼拉出來看 誰寫的查一查 就這麼簡單 然後拖到現在幾個禮拜惹

41 

自己寫了一個較有技術價值的專案(是自己主動寫的，非經主管指示)並已經用在公司 內部環境，但發現同事反組譯了自己的程式碼，參考了很多關鍵程式碼片段以 及設計的方式，寫了一個功能一模一樣的程式，還刻意變造讓人以為不是抄襲來的， 比如將if else對調，稍作一些沒意義的修改，各位發現之後會怎麼做? 跟主管講呢?還是當作沒這回事.....

32 

繼上集, 朋友被指導教授要求給博後論文草稿和實驗程式碼之後, 朋友除了使用推文有建議的拖,慢,等戰術讓博後拿不到, 78博後對我朋友出了新招,

30 

以下是根據本魯碼農自己的經驗，絕大部份參考Clean Code這本書，我自己是將這本書奉為 圭臬，不過我也知道很多人反對書裡的一些看法，所以聽聽就好 首先一個最大的原則就是程式碼必須好懂，因為它同時是寫給機器跟人看的，好懂是可擴充 性跟可維護性的必要，是程式碼無比重要的基石 推文有人說程式碼沒有註解的話十年後的自己會無法理解，實際上根據我自己的經驗如果我

29 

上週在重構某段程式碼時，其中一位同事在 code review 中建議把某個註解刪掉，另一 個同事看到這個評論時，在下面留了言說他認為不應該刪掉，於是我們就拉了一個小討論 ，聊在程式碼中寫註解這件事。 因為這個經驗，我回去重翻史丹佛電腦科學教授 John Ousterhout 寫的《A Philosophy of Software Design》一書，並整理了筆記。該教授的觀點是認為程式碼寫註解有很多好

24 

覺得最近很多文章都有些不求甚解的問題，來寫點論述。 1. 重構不是什麼了不起的事情 2. 變更程式碼，重寫舊的程式碼成自己爽的樣子，不一定是重構。 3. 重構是一種相對安全的工具型開發方法論， 但仍然有不少風險跟誘惑。

 6 

寫程式的基本功是寫測試 再好的程式碼如果沒有寫測試保護，就有機會在上線才知道程式碼被改壞掉。 平常有在寫測試的人，寫的程式碼也好讀很多，因為把程式碼寫太難會很難寫測試 --

 X 

氣 : 公司也沒人想要當壞人 code review也沒人出聲 而且大家都知道 上市公司每個都喜歡 : 有學歷的人當門面 反正真正主力有人會扛 XDDDD : 每次改到他們經手過的code都很痛苦 若是要幫忙擦屁股根本擦不完阿 因為一直拉.... : 自己寶貴的時間也都被吃掉了

兩種狀況： 1.想要程式碼換論文掛名，又不想多做其他維護與修改。 2.怕程式碼給別人維護，你就不能論文掛名了。 1的狀況： 人家的論文主要貢獻，是你的搜尋系統嗎？還是新資料？