代碼: https://github.com/jackroos/word_frequency

how you collaborate: working separately? pair programming? VS Live Share? other style?

首先我們一起討論了代碼結構，如何用python實現來更快的進行詞頻統計。然後是分工合作，隊友負責python實現，我負責代碼復審、單元測試、回歸測試，同時我們采用了結對編程的方式對代碼的瓶頸一起進行了分析和優化。

how do you discuss design guideline, coding convention and reach agreement?

我們在設計代碼的模塊的時候，遵循每個模塊的功能相對獨立的原則，代碼風格都用pycharm, 4個空格縮進，函數名能盡量看出功能等等。因此，根據這個規則，我們一起設計了各個模塊的功能和接口

• freq_dict.py : 所有freq類的父類，實現topk 以及文件遞歸路徑等功能
• charater_freq_dict.py: 實現字母頻率統計
• word_freq_dict.py: 詞頻統計，指稱stop word
• phrase_freq_dict.py: 短語頻率統計，支持stop word和動詞原形變化
• preprocessing.py: 對讀入文件各種parse到我們想要的格式，比如word list，過濾stop-word等等

how did the two of you aim high and try to deliver the optimal result with your own time constraints? is this the best your could do? what prevent you from doing your best?

在項目開始之前，要充分的討論，然後各自發揮強項，感覺效率還是很高的，另外從中我感覺自己從隊友的設計什麽的學到了挺多的。代碼因為是python所以很多地方不是很好優化，我們主要從多進程來優化，如果有更多的時間，可能有進一步的優化，但我感覺優化的空間不大。

list 3 strengths and 1 weak area of your partner

對python很熟悉，接口模塊設計的比較清晰，思路很清楚；寫代碼比較粗心

how do you use profile tools to find the performance bottleneck and improve speed? show some screenshots of your analysis

在一開始的時候我們就打算采用多進程來並行處理多個文件，在代碼寫好之後，用cProfile和gprofdot進行性能測試分析，我們發現處理多個文件的時候，代碼似乎並沒有並行起來:


我們發現時間主要花在進程等待獲取鎖上面，python多進程會把共享的變量object_lists每個都復制一份，這樣每次復制一份parse後的sentence list會花費很多時間，因此我們把parse_raw_text_to_sentences移到函數內，在函數內計算sentence list, 參數復制的是 text_path_list, 快了很多。
修改之前：

    def _get_freq_dict_for_text(self, index):

        cnt = Counter()
        object_list = self.object_lists[index]

修改之後:

    def _get_freq_dict_for_text(self, index):

        cnt = Counter()
        object_list = parse_raw_text_to_sentences(self.text_path_list[index])

時間提升了一半:

單元測試/回歸測試

見github

軟件工程之詞頻統計