如果在審PR的時候直接發一個comment說

這個lib 這個function根本不夠好用,我想第二天就是一場工程師之間的大戰
我們應該有一些事實可以說明問題

例如以下幾點, 看到這種問題實務上直接退就好了
並且為了可維護性的考慮, 真的是槍底在腦袋上都一定要讓對方改

1. 不符合語言的命名規則/團隊的命名規則
   通常JS用Camel-Case, Python用SnakeCase
   當然團隊可以自行制定, 如果在PR裡面發生這種錯誤
   除了發生了再拉出來鞭, 最好的方式是在團隊內推動全員裝lint + autofix
2. 用了不當的縮寫
   不要輕易地放過團隊沒有共識的縮寫, 因為十個人通常會有十八種縮寫方式
   我曾經在一段MR中看到標註這個字眼從annotation到ann到anno
   長此以往程式碼,有人可能會主張在這個MR中很明顯ann, anno這兩種縮寫很明顯都該是annotation
   但是如果拉到一個團隊寫的程式碼來看,每個人都有可能用不一樣的字眼表達,長此以往程式碼會非常可怕
3. 命名混淆
   還是拿標註這個字眼做例子, annotation這個命名沒有問題
   但是會發生標註的標籤這個狀況, 例如這個正方形的標註標籤為汽車
   此時就會有label這個naming, 然後就會發現有些邏輯的label指涉的是標註
   有些label指涉的是標註的標籤, 這種狀況很容易發生在團隊的新同事
   或是之前沒有碰過某段商業邏輯的同事身上, 最好的方法是發生的當下立刻協調出共識並見諸於文件
4. Performance Issue
   這種comment常見的在於不當的IO取用, 或是SQL Query,並且是Comment最容易被標註為Won't fix的問題
   我的經驗是,我常常跟Reviewer說下一個版本或下下一個版本修正
   但是真正修正的時候往往是發生問題的當下
   如果真的很急迫,至少見諸於issue上,知會團隊,並且下一個SPrint以高優先度修正
   畢竟在開發週期中修正,急迫程度遠遠比不上遇到問題上hotfix
   有足夠的時間好整以暇地去考慮解方根side effect

剩下這些問題影響深遠,MR收到應該點出來跟同事好好溝通

1. 缺乏抽象化: 舉個例子

def parse_label_coordinate_as_x_y_axis_pair(coordindates):
    x_y_pair_coordinate = []
    for i in range(0, len(coordindates), 2):
        x_y_pair_coordinate.append(l[i:i + n])
    return x_y_pair_coordinate

可以發現for迴圈開始那一段, 可以被表述成chunk_by_2
整個就應該被修改成

def chunk_list_by_n(list, n):
    for i in range(0, len(l), n):
        yield l[i:i + n]

def parse_label_coordinate_as_x_y_axis_pair(coordindates):
    x_y_pair_coordinate = []
    for i in range(0, len(coordindates), 2):
        x_y_pair_coordinate.append(l[i:i + n])
    return list(chunk_list_by_n(coordindates, 2))

在進一步應該請對方將chunk抽出去, 畢竟是一個很基本的功能
2. 過度抽象化/錯誤的抽象化

def update_report(df: DataFrame):
    google_sheet.update(REPORT_SHEET_ID, TAB_NAME, df)

這段code的問題在於沒有任何輔助說明的功能
即便在主程式直接寫這一段code我也能輕易明白這段在更新Google Sheet的報表
而且如果我看不懂, 那麼抽象成update_report也依然看不懂