左耳听风-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装配（https://www.cnblogs.com/minguo/p/10889967.html）