常常是我也希望可以趕快完工納涼，但是就是會看廢片。明明想東西就很快，但是很容易被中斷。
尤其是當我出現：他到底在寫三小。的時候，必定要花很多多餘時間才能銜接回原本的思路

也沒什麼不好，只是我高中大學都用錯誤的方法學習，硬要聽課結果以為自己有集中上的障礙
自修準備的考試反而都有不錯的成績

不，改程式那邊，我覺得大家都是

其實我不太能catch到你說的例子。
修別人的程式碼比起自己寫，資訊量應該更大？
因為你還要理解別人的思考邏輯，然後再融合自己的寫法，才能改好程式碼。

_silent_night
我也不知道該怎麼講 修別人程式碼照理來說是相對簡單的(雖然對我來說是比較久)
你講的比較像是"重構" 重構是理解對方全部在寫什麼之後 找出對方寫不好的地方 重新優化過一遍
我講的單純只是debug或追加功能 你只要針對有問題的那幾行去修正/針對追加功能撰寫就好

我對於你的例子反而是顛倒的想法，都是前者資訊量會比後者多耶

跟gino貼貼

tim14789: 你提醒我可能不是資訊量的問題 可能是思考模式的問題

tim14789: 我一開始是想指
小說可能一集的量動畫要演幾個小時 可是用讀的可能不用一個小時就讀完了
上課老師會為了加深同學的印象而重複舉例，然而有人可能第一個例子就理解了

別人程式碼這個我就不好舉例了 因為我遇到的情況是他們寫的都沒啥重點
通常他們寫的功能讓我來寫只要一半或更少的行數

長+沒重點就算了 參數看不出來在幹嘛也不下註解 真的龜覽趴火

這樣看起來像是不擅長團隊合作、協調。

我覺得跟 _silent_night: 說的差不多，因為如果只是你單方面的改動程式碼而不去跟他們做協調，你改幾次他們就也還是寫幾次讓你龜覽趴火幾次，應該是要跟他們討論一下你要調整的程式碼為什麼要這樣，有什麼差別，至少後面再編寫的時候你才不會又在那邊自幹

事後才跟他們教學其實效果不大，因為實際上程式碼的更動他們並沒有參與過，只會覺得阿你就改好了，如果是協調上的調整至少他們在寫的時候還會把問題點考慮進去

_silent_night tim14789
以我們公司的狀況不太能做到你們說的現場協調
1我們沒有code review的習慣
2每個人都有各自分內的工作
基本上都是把專案拆成好幾個part在合作
等到我有機會接手別人的code，通常對方也在忙別的事了

基本上一個人會踩的雷，一定也有其他人會踩，我習慣統計好每個人的錯誤，如果是個案就直接講，如果不是就撿起來當教材

有的東西是，他現在懂，但他當初寫的時候還不懂，然後那份code流到我手上，那種我也是除了該該叫什麼都做不到

還有就是，我只是同事身份，我不想冒險去踩雷跟別人說“我覺得你哪邊寫得不好”
所以我習慣開地圖炮（x
所以我通常先跟主管說我想講課 讓主管發個免死金牌在假裝自己很不想做這個苦差事（實際上我也不想做但不做不行

難處在我們公司沒有訂sop，很多東西我也是一邊摸索才一邊確認怎樣寫才比較好，每個人都有各自的想法，我私下講對方只會覺得“沒差吧”