初入一個專案時，通常會先了解整個行政作業流程，SOP，比如說案件怎麼跑
再來我就會從頭至尾，跑完某個案子
接著是將所有情境的案子都測試一次，觀察程式碼與庫種種行為...
這樣對我來說...很快就會上手

所謂的優化似乎也有點籠統，看是效能、功能或是程式碼美化XD?

因我主攻是Web App，針對此塊來說，最重要的就是使用者感受，所以我們會提供線上問卷，大家對使用上有什麼訴求、覺得哪裡很慢等等，因為他們是最直接且長時間感受的，利用收集來的資料去優化效能、精進功能等

其實，您的問題確實不太好回答。
也不能說您問的不好。而是本身這個問題。
理論上是大多數人的痛處。

畢竟，所謂的優化程式碼。一般都是經驗的傳承。
也就是你採雷了才能知道。

其實我個人的經驗。再碰第一次別人的代碼之前。
會先大略看一下，這專案的架構為何、分了幾個區域、
有無元件的使用對應、有無物件的使用對應、有無視圖的使用對應....

之後選擇其認定的範圍查看。
一般來講，會先由啟動位置來查看對應的載入。啟動位置指的是路由性的、或是 index 或是 main、start....
等等一開始的地方。並從中去看預設需要載入的中央控制....等等。

這是IT生涯中經常會遇到的情形，借用聖嚴法師名言：面對他/接受他/處理他/放下他，這真的是可以成為您人生受用的建議～～至於下方的擴充解釋是個人見解，希望也能幫到您！

1. 面對他：先確認目標，優化代碼讓效率能提升太攏統，目前程式執行時間是幾秒？客戶／主管要求要幾秒才達標？

2. 接受他：確認有拿到所有的原始碼，畢竟有人已離職了嘛，乖乖從頭開始Ｋ程式碼，先大略的看就好，Python有個稱號是"膠水語言"，所以先確認有沒有呼叫外部執行檔？外部執行檔和執行速度有關就再追相關原始碼公司裡有沒有？再來是了解整體程式的架構，找出影響效能最大的的那一段程式碼

3. 處理他：仔細一行行的看這一段程式碼，了解程式效能的瓶頸所在，找方法改善他，如果真的認為沒有優化空間，試試CPython或其他語言

4. 放下他：不管最後您的嘗試是否成功，記取經驗並作傳承或分享，然後快去作其他的事吧！！！

把乘除法改成位元運算，這樣的回答會太淺嗎？畢竟弱弱的我功力也不高！

指機械臂系統，讓機台處理每次任務的速度能提升
這個才是重點。
你應該注意2個問題。
1、 機械臂 的 執行最短路徑。
2、 機械臂 的 執行速度。
否則就算 你的代碼再怎麼優化。
客戶還是會說慢。

說到 python.
我曾看過一位大神這樣寫。以下是舉例，不是實際程式。
CAST(A,(TRIM((CONVERT(INT,B)+"AAA")))
一行就寫完。沒有註解。夠優化了。
後面接的人就傻眼了。
我自己也曾遇到要翻寫自己2年前寫的程式。
然後我自己也傻眼了。
1、程式優化過。
2、沒註解。

優化代碼 的 重點 要在於 自己和其他人都能看懂、易維護。
因為我們不是程式設計天才。

優化程式碼對我來說大致分三種

1. 易讀性的優化
2. 效率上的優化
3. 可靠性的優化

• 先慢慢trace祖先的留給你的code，當你覺得有些地方看不懂的時候，或許易讀性優化的時刻出現了，可以幫他加上註解或是重構成更清楚的架構
• 至於效率的部分，這就要看你的程式用途在哪了，如果資料量體很大時，那可能就要坐在馬桶上想想看有沒有更好的算法
• 可靠性最簡單的辦法就是幫每個function寫個測試，看有沒有哪個面向沒考慮到的

我通常都以易讀性為重，畢竟我們寫出來的東西終究還是人在看的

最簡單的就是看懂以後加上註解
一堆人自以為自己的 code 很 clean 不用註解

事實上是當業務一複雜，文檔不齊全，又沒註解，又面對各種自以為創意的code
對維護的人來說真的是地獄