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)
来源:https://www.cnblogs.com/minguo/p/10884954.html