辩证的看待makeitright,thenefficientthenbeautiful

这个应该是敏捷开发中 一再提倡的一个原则。

和它一样的还有著名的unix的keep it simple and stupid.

他们本质上都是提倡编程上科学的用脑&＃xff0c;比如kiss原则背后的原因就是让程序的设计可以很容易的被程序员驾驭&＃xff0c;如果程序写的庞大而且杂乱&＃xff0c;那么人难以驾驭&＃xff0c;就会导致单位时间内可以做的事情低效低质量。

写这个blog也是处于最近我写程序越发低效。

类似的事情在高三复习的时候也遇见过&＃xff0c;最开始的时候只是看了一个章节的内容&＃xff0c;然后做一个章节的题&＃xff0c;对于知识连通性上的掌握不是很好&＃xff0c;所以在一本书学完回头开始进入综合复习的时候&＃xff0c;就会出现每个题目要想很多&＃xff0c;因为知道的多可以想的也很多&＃xff0c;这个时候是比较难受的&＃xff0c;出于高三的压力也去咨询了老师&＃xff0c;老师也给我点出了这个原委&＃xff0c;解决之道就是深入理解&＃xff0c;熟练强化。

深入理解可以抓住事情的本质&＃xff0c;尽管有万变但是不离其宗&＃xff0c;所需掌握的实际知识量非常少&＃xff0c;经过练习之后从熟练迈向融会贯通。做题速度质量上来了&＃xff0c;心理感受到大脑负载都好了很多&＃xff0c;人也就进入良性循环&＃xff0c;在大工作量面前良性循环是决定整体表现的关键。而深入理解融会贯通带给我们的就是面对同样问题的时候&＃xff0c;大脑负载的降低&＃xff0c;这样效率和质量都会上升&＃xff0c;kiss原则是从程序设计和表现上说这个问题&＃xff0c;而深入理解融会贯通是在个人修炼上说这个问题。

最近出现的情况我认为一样的&＃xff0c;刚开始进入大型项目的时候负责的东西&＃xff0c;懂得东西都少&＃xff0c;对自己的期望值也不大&＃xff0c;所以写程序想的不多&＃xff0c;想精益求精都不知道精益求精究竟是个什么样子&＃xff0c;自然写起来就很快&＃xff0c;除掉bug&＃xff0c;由于当时负责的东西不是重要的东西&＃xff0c;快了慢了都没什么影响。

后来一方面读的优秀代码多了&＃xff0c;感叹之余也在要求自己向这个水平努力&＃xff0c;另外也开始接触项目比较重要的部分&＃xff0c;于是需要考虑的东西一下子增加了很多&＃xff0c;有时候真的觉得自己写程序像个娘们&＃xff0c;瞻前顾后&＃xff0c;反复确认&＃xff0c;但是高质量程序不都是这样产生的么。另外回头用到上各项目自己写的代码&＃xff0c;感觉非常ugly&＃xff0c;当时我已经尽力在把结构效率提高了&＃xff0c;看来自己这方面是比较有进步的。

所以认为自己在这方面可以结合高三的深刻理解融会贯通和kiss&＃xff0c;敏捷开发的原则。一方面对于设计&＃xff0c;实现和硬件认识上不停的加深理解&＃xff0c;一方面在工作上有意识的增加思考量&＃xff0c;可以把正确和高效并在一起&＃xff0c;甚至也考虑良好的设计&＃xff0c;熟练了之后就会一气呵成&＃xff0c;多么愉快。

另外一方面也合理的把复杂度分离&＃xff0c;降低问题的复杂度&＃xff0c;一次做自己能力%120的东西&＃xff0c;既增长了自身也合理的工作。

还有一些想法就是认为在实现过后写详细的文档非常有好处&＃xff0c;

一来是teamwork的一个非常好的习惯&＃xff0c;合作的人可以更加容易工作&＃xff0c;相关的人可以了解你这一块东西的实现方式。

二来就是升华自己对于问题的认识&＃xff0c;加深理解&＃xff0c;理清思路&＃xff0c;可以在文档中刻意的挖掘本质&＃xff0c;力求之后遇到类似的问题可以举一反三。

三来可以很好的锻炼自己写作表达水平。