Week 7 -ARTS- ear listening to the wind (2019/05 / 19-2019 / 05/25)

Algorithm

This week's topic is the algorithm and the Count (Say https://leetcode.com/problems/count-and-say/ ), valiant questions, and did not find out the law n strings to produce, check the Internet know, it is to generate the next number string by the number of characters on a string, so use recursion.

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/）

This article discussed the code from pretty simple. When writing code, we strive to make sure that the code is readable, maintainable, good development speed and keep beautiful. The key is to make all of this is to keep it simple.
What is beautiful code? This is a very subjective question, everyone has a different view, which a large part is determined by their background of life, but the foundation is simple. Regardless of the application as a whole or how complex the whole system, in which a single part of a single responsibility, and have simple contact with the rest, which would make our system maintainable, testable, and maintain the speed of development.

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

Benpian discuss reconstruction things before the code must be taken into account. Seriously consider these things will help us save a lot of time and pain before reconstruction.
Before reconstruction first count under the code and test cases. This will help you understand the strengths and weaknesses of the current code, so that we can retain the strengths and avoid mistakes.

Resist the temptation to rewrite all the code. The best reuse as much code, no matter how ugly the existing code, but it has been tested, code review too. Discard the old code, which means you discard the test took months or even years, after the test of the code, which in solutions, bug fix is we do not know.

Gradual improvement better than a big improvement. Incremental improvements to make it easier for us to assess the impact on the system, through feedback or test.

After each iterative development is completed, to ensure that by the existing test cases. Add a new test cases cover the modifications you do. Without full consideration, do not discard existing test cases. By adding to think about why this use case can help you understand the code.

In the reconstruction process, not subject to personal preferences and the impact of self. Just think coding style is not your preference on the reconstruction of those code, which is unreasonable. I feel better than their predecessors did on the reconstruction of that code, which is unreasonable.

The introduction of new technology can not be a reason for reconstruction. Unless the use of cost-benefit analysis shows that a new technology, the new framework can significantly improve the functionality of the code, maintainability, or not be reconstructed.

To err is human. Reconstruction does not necessarily guarantee better new code, or the code before being rearranged and as good as we are all human, make mistakes.

Tip

Spring assembly in bean ( https://www.cnblogs.com/minguo/p/10889967.html )