大家已經都在使用新語法？

這裡的大家是指全部的 developer 扣掉一兩個同事嗎？

如果今天有一個常用的功能，大家已經都已經在使用新語法了，但就是有一兩個同事還在使用舊語法，但因為功能較大，如果要改用新語法會花很多時間做修改，

這裡是指有一個功能較大的常用的功能, 所以需花很多時間去用新語法改寫嗎？

我其實會建議：
如果真的全部門只有一個或兩個人在用舊語法，很顯然大家都覺的新語法好，找老闆來決定一下，下一道聖旨，直接改就好.

或是想一下為什麼要改寫，改寫有什麼好處以及壞處，如果有個非改不可的理由，那其實就可以很容易說服那一位同事了。

先問看看同事願不願意修改
若不願意，要問他原因

我個人認為不必操心
除非他會干涉到你的作業
否則不要去要求會較好

也可以跟同事討論新語法的好處
使同事動心想改變

您的想法：

1. 寫法漂亮
2. 統一編撰
3. 程式簡潔
4. 維護效率

已知缺點：
功能繁多＞＞＞＞＞＞如果能化繁為簡做出一個主題功能，並能讓同事感受上述好處，舉例事情更快完成早早回家打烊與之後的系統問題加班說掰掰！另外就是你也說了改寫就是麻煩，這是一般常態人性問題外人人想法都不同，更有可能是你改變了引發了對方原來的生存方式呢？以下文章可以參考外可以聽聽大人學Podcast，或許可以解決您的問題！

如何說服隊友達到目標，你的提案如何讓對方買單
說服別人關鍵不在說什麼，而是說話方式

主要看公司利益及你夠不夠力來看待這件事。

所謂的團隊合作。認真來說一定都不會去看程式碼。
程式碼沒BUG。怎麼寫都不關你的事。

當然，或許你會說可能會因為日後維護。巴啦巴啦的...
那就在公司提出來討論。
而不是在這邊討論。

短的答案是「由主管決定」

長的答案是：這是「管理」問題而不是「技術」問題
也就是結果的做法和「技術難易度」無關

團隊都已經使用 git 在合作開發了
每個人的「差異點」應該多不勝數，例如
1.code style
2.程式語言
3.IDE (種類、版本)
4.commit 習慣
5.OS (種類、版本)

而是否要強制這些項目的一致性
都是由主管決定

就我個人的經驗
只有全新成立的團隊比較有機會定義這些規則
老團隊大概只要schedule趕得出來就千幸萬幸了