一 一 style/unit test/ type hint 完全都是團隊必備 (這裡就顯現你我觀念上的根本差距)
如果我是 team manager 我一定會要求這個團隊文化，你寫的扣永遠不是你自己看自己修改，本來就要有一個 team standard. 再說 Style/Unit test/Type hint 這種問題完全可以靠 IDE tools 來解決，團隊存在夠久以後本來就應該要有一份 STYLE config file that can apply to your IDE, commit code 之前跑一遍 static analysis 就可以通通抓出各種style問題，你越習慣這個模式，寫扣時就越容易養成習慣呈現出這種 team style.
Type hint 也是，你是online review不是 IDE review, 把各種type寫清楚才能幫助online review. Unit test 也是有tool 可以幫助你，通知你哪些地方該有 Unit test~ 我是不懂 Python 但 Mobile 這邊的IDE 工具超多，老鳥要求菜鳥安裝該有的 tool並且跑一遍整體流程，馬上就可以讓大家習慣這流程，並且同時產出 team standard.
所以以上都不會是沒效率的問題，G社最沒效率的問題在於，每個人都自視甚高不肯降低自我達到團隊要求，太簡單的工作不想做，太無聊的流程不想跑 (但這些流程會減少很多 team debt)，一群 spoiled SWE.... XD
而且還有 project 亂開開完不理的文化⋯
做完了管他有沒有人用
如果我是 team manager 我一定會要求這個團隊文化，你寫的扣永遠不是你自己看自己修改，本來就要有一個 team standard. 再說 Style/Unit test/Type hint 這種問題完全可以靠 IDE tools 來解決，團隊存在夠久以後本來就應該要有一份 STYLE config file that can apply to your IDE, commit code 之前跑一遍 static analysis 就可以通通抓出各種style問題，你越習慣這個模式，寫扣時就越容易養成習慣呈現出這種 team style.
所以以上都不會是沒效率的問題，G社最沒效率的問題在於，每個人都自視甚高不肯降低自我達到團隊要求，太簡單的工作不想做，太無聊的流程不想跑 (但這些流程會減少很多 team debt)，一群 spoiled SWE.... XD
我舉個例，我覺得 code inheritance 要有 layers, 但只能有三層，超過三層就他媽的太複雜！
我認為該有 team style standard 但不是複雜到讓人不爽，公司不應該是 flat struct 要有 hierarchy 但又不能深到我要解決一件事要轉五層 => 我只適合中小型公司 LOL
為什麼不把準則全部轉成 IDE config files 發給每一個工程師.... 一 一
我想看他會怎麼靠腰G社😂🤣🤣