推 a47135: 先看大略看一次架構，再看功能，再看功能如何實踐，由小入 08/25 20:52
→ a47135: 大會很吃力 08/25 20:52
→ a47135: 這是我個人看程式碼的方式 08/25 20:53
→ keyboard56: 先知道這個系統在做什麼，每個環節都是跟業務流程相扣 08/25 20:56
推 leicheong: 先看架構理清甚麼大概會放在那, 再按Input-Process- 08/25 21:29
→ leicheong: Output的脈絡看數據在怎樣傳遞. 一般就這樣的感覺. 08/25 21:30
推 f1234518456: 先用看看這東西到底幹麻用的 從功能往下猜 08/25 21:40
推 followmeyo: 一個功能一個功能看~先了解該功能用途~再看code~ 08/25 21:56
推 mapleone: 還可以新舊code比對，可以更深刻領會程式為什麼這樣設計 08/25 22:45
→ andymai: 看他之前的架構寫得怎麼樣囉~寫得好的話~應該可以從大方 08/25 22:57
→ andymai: 向開始往下分~慢慢由大而小地看~寫不好就... 08/25 22:59
推 conanist: 先看做什麼事>功能面>流程面>最後才看CODE 08/25 23:34
→ conanist: 就算不看CODE也沒差，反正你知道後可以寫的比他好 08/25 23:34
→ GoalBased: 寫得好的code你應該看得懂 也可以從看code知道 08/26 00:05
→ GoalBased: 程式跑起來大概會怎樣 08/26 00:05
→ GoalBased: 看舊的..到不如看新的.. 08/26 00:06
推 leicheong: Btw, 已經沒在用的程式碼還拿給你就是想你學coding的 08/26 08:04
→ leicheong: 風格啊, 否則直接拿設計文件來看不是更有效率? 08/26 08:05
→ leicheong: 別說不用看code那樣的話了. 08/26 08:06
→ ppoi001: 依樣畫葫蘆，實作小改程式幾次，不用多久就會了 08/26 22:08
推 abola921: 拆解別人的作品是種感覺，拆久了再大的很快都可以拆解掉 08/26 23:05
→ abola921: 如果程式裡沒有足夠的註解，我會建議你先從加註解開始 08/26 23:05
→ abola921: 然後找到程式的Output點往回推，因為通常Output的定義 08/26 23:08
→ abola921: 都會比Input來的明確很多，從Input從下找我的經驗是不行 08/26 23:09
→ abola921: 分析出第一串流程後，就開始動手改變流程變數觀察變化 08/26 23:11
→ abola921: 最後把程式還原回原狀，包含已加的新註解都拿掉 08/26 23:13
→ abola921: 依照原程式的風格，修改需求，免得challenge到原作者 08/26 23:15
→ abola921: 天知道那個前輩是誰，說不定正是你的主管 08/26 23:16