Re: [請益] 如何有效率的看code ?
如果你沒寫錯的話
一年多看幾萬行code真的不多
我也是轉職仔，原本在ic house寫C做韌體，一個人負責一個.c/.h檔。一年才進三行code。轉職後寫C++整個team大約十多人，負責的那一層有兩千萬行code。然後第一年就進快一萬行code。
我原本不會C++的，所以什麼framework，modern C++，design pattern，multithreaded 之類的都沒學過要重學。
我不知道你的工作類似哪種，如果是類似我第一種其實很簡單，IDE 上function name點進去看函數定義就好了沒那麼難。
第二種的話有文件可看那當然最好，但沒文件也是很正常。正常人不可能每新增一個class就寫一份文件，那樣開發速度太慢。而且像MVC或design pattern這種很generic的架構也沒人在寫文件的。再加上寫class diagram或sequence diagram其實很花時間。我剛轉職的時候也會寫但做上手了以後根本懶得寫。
建議你多準備一個螢幕，用雙螢幕看會比較快，如果是筆電的話還可以三螢幕。
然後選擇適合的editor，我個人是用visual studio code，ctrl加滑鼠左鍵點到function上就可以看到函數定義，用launch.json就可以用debug mode，設斷點看call stack然後單步執行。
註解的話我們公司不太寫在程式碼裡面的，都是用issue tracker和git去追蹤。比如說你想看這段code是誰寫的基於什麼理由然後又經過了怎樣的演進。你就用git查blame，就會看到這段code是哪幾張ticket改的，你再去ticket看上面應該都有商業邏輯和註解可看。有code review的公司在bitbucket上應該也有大家的討論和註解可以看。
大概是這樣，其他想到再補充
-----
Sent from JPTT on my iPhone
--
怎麼會離開豬屎屋去系統廠呢？
系統場沒有不好呀，而且我公司比較像是外商軟體公司
推比較現代的作法，很多地方開發時程都壓超緊，連測試
時間都不給了還寫文件
老實說習慣古早時代寫小工具都會留readme跟更新紀錄了
現在都習慣寫滿滿的註解 issue tracker簡單標原因就好
註解應該是很重要的 畢竟是很直覺的 用git找太費時間了
樓上倒過來了吧,成千上萬行的程式分布不同目錄檔案,你要找
註解還不確定是誰或何時寫的,註解是不是還有效. 看git log
直接知道作者時間,加上git diff可以知道變化的內容. 跟
JIRA Redmine合起來用一目了然
git log真的比較直覺
簡單來講就是要用時間補能力 不然就不要幹 離職
註解對於了解細節還是很重要，某些功能的patch修修補補都不
知道演進多少次，git log比較適合用來看演進過程，不是trace
最好是有人在看演進過程,git垃圾工具無誤,一堆錯誤觀念
不用git用啥? svn?
其實我比較喜歡perforce
git我們都拿來看出包的是誰XD
push
八成是android+高通...
謝謝分享
推git
某人對git 很悲憤XDD
crag
打錯 ctags -R *
5
拿出你的 powerpoint/word/visio 開始重建程式的架構跟流程圖， 加上自己的註解函式之間的關係搞清楚幾萬行根本沒什麼 最慢一週內就看完了 而且後面會越看越快![Re: [請益] 如何有效率的看code ?](https://i.imgur.com/WRN1Rvmb.jpg "Re: [請益] 如何有效率的看code ?")
10
就是不要看扣 有文件看文件，沒文件去問人 臉皮要厚，心要 code這種東西不是人看的，是機器看的 就算你是超級老手，直接去看幾萬行的扣也是浪費時間13
其實你的問題很模糊 先了解 你老闆要你做什 如果是maintain 表示這code是ok的 頂多run run test bench 看看input output 如果是要你跟韌體搭配 去study register table就好36
首Po轉職一年多 幾萬行龐大的code 實在不知道要怎麼看 導致工作進度落後 常delay 交不出來 每天工時12小時 假日有時還進公司自主加班 其實也不只是code 還有背景知識也不熟悉
![Re: [請益] 如何有效率的看code ?](https://yt3.ggpht.com/ytc/AMLnZu8OJyPPVMQ7ijoc9ewwrNysCZr1NWZr4Bwqeo5H_Fk=s900-c-k-c0x00ffffff-no-rj "Re: [請益] 如何有效率的看code ?")
29
Re: [心得] 好的註解是解釋為何需要這段 code上週在重構某段程式碼時，其中一位同事在 code review 中建議把某個註解刪掉，另一 個同事看到這個評論時，在下面留了言說他認為不應該刪掉，於是我們就拉了一個小討論 ，聊在程式碼中寫註解這件事。 因為這個經驗，我回去重翻史丹佛電腦科學教授 John Ousterhout 寫的《A Philosophy of Software Design》一書，並整理了筆記。該教授的觀點是認為程式碼寫註解有很多好![Re: [心得] 好的註解是解釋為何需要這段 code](https://www.explainthis.io/static/images/twitter-card.png "Re: [心得] 好的註解是解釋為何需要這段 code")
24
Re: [討論] 資工系畢業不會git很扯嗎說到這個git吼 我有經驗啦 想當初 我在台灣幹第一份工作的時候 也是不會git阿 然後R team裡面有一個台科大還是北科大資工的 都30幾歲了講話還很嗆 我說我沒用過git 他說: 蛤 你們學校沒教喔? 台清交是教甚麼的? 媽的 嗆成這樣 我就去學了git 阿就是版本控制而已啊14
Re: [討論] 用AI寫code產生的疑問其實很多新技術在早期和成熟後相比你會感覺他的應用是完全顛覆最初想法的 例如 web 仔最熟稔的 web 好了，網路泡沫時代前大家對電子商務 的觀點是在網路上的一個廣告頁，每個網站就像一間街邊店一樣，透過網址 這串虛擬地址你可以造訪網路上的任何一間店，找到你要的資訊，更容易媒合實體交易 當時的 web 就是一本電話簿的概念10
Re: [新聞] 前Google主管：人類寫程式時代已經結束: 看AI能不能寫code 就下個 copilot 玩玩看就知道了 目前支援copilot的IDE(沒列全部) 1. visual studio 2022 2. visual stduio code8
Re: [討論] 怎樣算是一個合格的junior cpp programme我提一個好像沒有人討論的點 一個合格的junior/entry-level C++ programmer應該要良好的trace code技能 這個也不是只有C++適用 而是所有語言都適用 在學校除非個人興去的關係碰過open source code 否則很難碰超過1萬行的code8
Re: [討論] 同一個程式碼段落超過一人以上在修改不一定，可能合理可能很 suck 要看規模、工作流程、有沒有人控場、默契 自己的經驗是分工做得好的地方通常會定義 ownership 「這塊 code 是拎北/拎母的，要改要先問」 積極的 owner 會對 code 要長成怎樣有明確的想法並前進3
[問卦] 要怎麼讀程式碼R？如題 最近要寫在soc上錄影、播放的程式拉 看廠商給的code 隨便一個.c檔就好幾千行 一堆全域變數 看一看就突然有一個task被創建出來 然後task之間又有一堆訊號在傳資料3
Re: [請益] 有人的公司也沒有提供API文件的嗎: : 安安 : : 小弟剛轉前端，進到一家接案公司寫網頁，工作大概9成都在接API， : 但公司內部沒有提供api規格文件讓我參考，1
Re: [請益] 類似notion的code筆記軟體?我都用 vscode + git vscode + drawio + plantuml + code runner 因為主要都打英文，所以就用平常coding的vim卡順手 要畫diagram，就直接draw.io 畫好存檔 要寫設計文件，畫uml，就直接用plantuml
Re: [討論] 用AI寫code產生的疑問借串問，有人試過能否用 AI 延伸 existing code base 嗎？ 如果是 existing code base 各種東西都包成模組或 function 例如對 elasticsearch 的操作全部都包成自訂 function 給 python 呼叫 如果讓 AI 讀 code base