左耳聽風-ARTS-第7周（2019/05/19-2019/05/25）

Algorithm

本週的算法題是Count and Say（https://leetcode.com/problems/count-and-say/），看了幾遍題，沒找出n與產生字符串的規律來，上網一查才知道，是經過數上一個字符串的字符數來生成下一個字符串，因此用了遞歸。

public String countAndSay(int n) {
        if (n == 1) {
            return "1";
        } else {
            String rawStr = countAndSay(n - 1);
            char[] chars = rawStr.toCharArray();

            StringBuilder sb = new StringBuilder();

            int i = 0;
            char temp = ' ';
            for (char c : chars) {
                if (temp == c) {
                    i++;
                } else {
                    if (temp != ' ') {
                        sb.append(i).append(temp);
                    }

                    temp = c;
                    i = 1;
                }
            }

            sb.append(i).append(temp);
            return sb.toString();
        }
    }

Reading

《Beauty Is in Simplicity》（https://97-things-every-x-should-know.gitbooks.io/97-things-every-programmer-should-know/content/en/thing_05/）

本篇文章討論漂亮代碼源自簡單。在寫代碼時，咱們努力作到使代碼有可讀性、可維護性，好的開發速度、並保持漂亮。而要作成這一切的關鍵是保持簡單。
什麼是漂亮代碼？這是個很是主觀的問題，每一個人都有不一樣的見解，這很大一部分是由本身的生活背景決定的，可是基礎是簡單。無論應用總體或系統總體有多複雜，其中的單個部分有單一的職責、並與其它部分有簡單的聯繫，這會使得咱們的系統具備可維護性、可測性、並保持開發的速度。

《Beauty Is in Simplicity》（https://97-things-every-x-should-know.gitbooks.io/97-things-every-programmer-should-know/content/en/thing_06/）

本篇討論重構代碼前必定要考慮的事情。重構前認真考慮這些事情會幫咱們省下大量的時間和痛苦。
重構前先盤點下代碼和測試用例。這會幫助你理解當前代碼的強處和弱點，這樣咱們能夠保留強處而避免犯錯誤。

抵制重寫全部代碼的誘惑。最好重用盡量多的代碼，無論已有代碼有多醜，但它已經被測試過、code review過。丟棄舊代碼，意味着你丟棄了花了幾個月甚至幾年測試、歷經考驗的代碼，這些代碼中的解決方案、bug fix是咱們不知道的。

漸進式的改進比一個大的改進要好。漸進式的改進使咱們更容易評估對系統的影響，經過反饋或者測試。

每次的迭代開發完成後，要保證經過已有的測試用例。添加新的測試用例覆蓋你作的修改。不通過充分的考慮，不要丟棄已有的測試用例。經過思考爲何添加這個用例能夠幫助你理解代碼。

在重構過程當中，不要受我的偏好和自個人影響。僅僅以爲編碼風格不符合你的偏好就重構那些代碼，這是不合理的。以爲比前人作的更好就重構那些代碼，這也是不合理的。

採用新技術不能是重構的理由。除非有成本效益分析顯示採用一種新技術、新框架能夠顯著提高代碼的功能、可維護性等，不然不進行重構。

人總會犯錯。重構並不必定會保證新代碼更好、或者和重構前的代碼同樣好，咱們都是人，都會犯錯誤。

Tip

Share

Spring中的bean裝配（http://www.javashuo.com/article/p-oaluiqyp-hp.html）