不经意之间已经接触代码一年多了，回头看向大一那时候的自己，什么都不懂，但也能过得很开心。今天就写点东西，给未来的自己一个回忆。
编程伊始
大一下开始接触Java，到现在整整一年了。中间虽然不是一直在学Java，但是还是很亲切。那个时候真的是无头苍蝇一样，没有方向，没有好的学习方法，到处碰壁。
泡在图书馆，照着书上的例子一个一个的敲，到各种视频网站上看人家的编程经典视频。时间总是那么的短，每天都不够用似得。然而收获却总达不到自己的预期。付出与收获并没有成正比，看看那个时候的自己，真的是傻傻的坚持着。
然而现在想想，仿佛答案并不是很复杂。从一开始，“路”就错了。在一条错误的路上越努力，离成功就有可能越远。不顾一切的努力没有错，但是前提是适合自己，在思考中努力。
我的反思就是，“在思考中编程，而不是埋头苦干”。书本，教学视频，无非是一些辅助。根本不是真正的重点。而且，在初期看些视频啊，书本什么的确实很有成效。按照别人的方法，一点点的“临摹”，确实，当时的代码确实是运行成功了，得到了想要的结果。然后就以为自己可以了。然而，却忘记了最重要的原则，脱离了外界，我能独立的完成吗？别人实现的思路真的弄明白了吗？我想，当时的我压根没有思考过这个问题吧。不然也不可能荒废了那么宝贵的时间。
但是，过去了，就真的是过去了。是更改不了的事实，唯一能做的就是尽量的去弥补。
编程之道
这里是说给自己的一番话，如果你恰巧看到了这些，而且也比较的适合你，那么我很荣幸！
“需求”分析
这里用了“需求”这个词语，属于断章取义。然而意思没有变，在我们编程之前，不知道有多少人真正的思考过，我们正面临着什么样的问题。真的分析的透彻了吗？
我见过很多人，包括我自己。拿到一个问题，立马就着手coding了。但是做着做着就迷茫了。或者返工，更有甚者，就那么放弃了。那么我们今天不妨想一想，
- 我们真的弄明白问题了吗？
- 我们要完成一个怎样的功能？
- 我们要以怎样的方式来解决这个问题？
- 我们的这个方式的可行性有多大？
·
·
·真正的弄清楚问题，不是我们认为的那么简单。
注释的艺术
注释，有多少人真正会注释？就连我自己，我都汗颜，因为我不怎么会注释。而且我也相信，大多数人和我一样，并不会注释！作“注释”可以算得上一个非技术性，非智力性的活动。
我们不妨先自己反思一下，注释是干什么的？
难道仅仅是为了让别人看到这个注释完成的功能吗？
我想说的是，是的。注释很大的一方面就是为了让别人了解代码的功能，这也是注释存在的根本的意义！然而我们很多人没有想到的是，注释不仅仅是这样的。
注释的原则：代码逻辑是怎样展开的，而不简单是代码做了什么
我想我们大部分人，都是停留在后者吧。是时候反思一下了。
注释的规范：这一点我不敢说多咯，因为规范这种东西，真的说不好。我一直认为，根本没有什么万能的规范，适合的才是最好的。对于团队而言，亦是如此！
空格的魅力
空格键，键盘上面积最大的一个键位。我们也许都会认为，它无关紧要，很平凡，很普通！ 但是我想说的是，它很伟大。我们大部分人都没有认识到，空格给我们带来的美感。
可能，在一个平台上，这一点体现的并不是很明显。比如我用的是Windows，你用的也是Windows，所以你拷贝完我的代码，在你那显示的依旧很完美。很正常。但是加入你的是Linux，我的是Windows，别人的是Unix呢？代码还会显示的很一致吗？
答案并不是。这一切的一切都是因为一个tab键，这个让人又爱又恨的键位。不通过平台的tab键处理方案的不一致性导致了这一问题的出现，较好的解决方法就是放弃使用tab键，而是改用空格键。
相信，如果你遇到过跨平台文件编辑时让人痛苦的排版问题。特别当你是一个喜欢用tab键的Python程序员的时候，痛苦会加倍上升吧。
起名字的艺术
你也许听到别人说过，关于coding的时候命名的规范。然而每次当你需要命名一些变量，方法（函数）的时候，却又总是忘记来应用。
还记得大一的时候学习C语言，看到一串串的i,j,k,p,o,m,n···光是想想，就让人心烦，这些变量的取名是没问题，但是这一大串的无意义的名字，唯一带给我们的就是繁重的记忆负担。削弱了我们对代码逻辑的理解能力。
我的建议：不管是对变量，方法，函数，类···，命名的时候先思考一下，斟酌之后再敲下你的命名。这对代码维护会很有帮助的。
早前，看过一段话，大致如下：
设想一下，当你走过你的代码的被照亮的森林时，你在身后留下了面包屑。相信我，当你需要找到回去的路时，森林将充满可黑暗，朦胧和不详的预感。其意蕴，自己体会一下吧。相信有过经历的人，会刻骨铭心吧。
重构之道
重构Refactor.一个看似晦涩难懂的词语，但是其作用却是何等的巨大。
重构的目标就是消除重复代码，降低耦合，便于维护。
但是你会重构吗？重构不是简单的把一段段的代码块揉到一个方法里面，有些时候。看似重复的代码也是不能整合成一个的。说起来很苍白，但是真的是很有韵味。
下次，编码的时候，尽量把你的代码做的规范一下，该删的删，该合并的合并，尽量以一种匠心来编写你的代码。当然了，这种能力不是说说就会有的，关键在于锻炼。
测试之路
我自己的专业就是软件开发与测试，貌似矛盾的二义性的专业。做程序员的都明白，开发部和测试部基本上属于仇敌类型的两个部门。仔细的想一想，关键就在于代码的测试上。
一段健壮的代码，经得起千锤百炼；对于目前的我们，完成一个小功能（方法，函数）的时候立刻，现在，马上做测试。而不要拖延，否则虐心的只能是自己。
调试的艺术
说起调试，我就得批评一下我自己了。因为懒，所以懒得打断点，懒得查堆栈。总是使用：
- System.out.println()
- Log.i()
- printf
- console.log()
·
·
·
其实这种方式并没有我们想象的那么好，尤其是代码量特别巨大的时候。调试只能让我们心焦气燥。我们要学会使用Debug，这将是我今后努力的方向！
学好Debug，遇到再多Bug也不怕。
写在最后
作为一个尚未入职的学生，写下这段苍白的语段，留念而已。希望将来的我，回过头来在看到这篇文章的时候，能感到一丝丝的欣慰。
青春嘛，留下点回忆，总归是好的。
愿经年之后，此心依旧！
---- 致 未来的自己。