标签：手写 简单的 慢慢 用户 开始 业务 地方 鼓励 比较
很多刚刚入行的同事，他们能有自己的想法，我鼓励他们用自己的想法去实现，但是我对他们最低要求是实现功能同时，能够保证代码的阅读性，能够保证代码的一定质量。和所有人一样，首先你能够实现产品的功能，如果你不能实现也没关系（偶尔一两次），必须要讲清楚不能实现的原因，我鼓励他们加入自己动脑去思考，而不是成为一个麻木的复制粘贴的码农。希望他们能够从一开始就养成爱思考的，会写代码的程序员。下面说说一下，看了他们代码，觉得不足的地方吧。
对于刚刚入行的人来说，他们很容易的就会犯这个错误，因为有些时候，复制对于实现一个类似的功能来说，可能更快。尤其是进度比较赶的时候。你说项目赶，然后你去复制了代码，去让自己的代码重复，我觉得这样做反而更不好。首先不说远的，就当你要改一下你复制这段代码，你都要改变那几个地方。等下又忘记了，就会给系统留下Bug。
平时在开发环境下， 由于数据量少，一个请求看起来都不是很慢，但是很多时候到了真正的开发环境下，系统真正的开始用起来了，数据量不断增长，慢慢的整个系统都会变得很卡，最终这个系统就烂掉了，所以大家写代码的时候，一定要前瞻性，考虑到今后三五年的变化，就算现在做不到，至少意识要有。
可能很多人都是看了很多关于代码整洁之道的书，代码整洁，其实要保证的就是命名规则良好，命名尽量都用英文。平时也要养成自己的习惯，哪些要怎么弄，怎么做。就比如简单的查询一个列表，应该是从路由，到方法名，都是可以体现出这是和列表相关的，对应列表，我比较喜欢用，QueryUsers 查看详细，GetUserDetail。就是类似于这样。很多时候，可能都在纠结如何命名，有一个好的办法就是，多看高手写的代码，特别关注下，别人怎么命名的，然后学习他的。
有些时候，理解不够，就马上动手写代码，最后就是一场空。所以各位切记不要急着写代码，必须了解清楚的需求，并且在写在做的时候，应该要考虑未来几年内的变化。
不去模拟实际的业务场景，啥事都来问我，写代码时候，始终牢记一点，技术是给人带来方便，减少人的负担的。所以实现某个功能的时候，需要去想想实际的业务场景是什么。
由于时间关系，暂时就总结这么多了。上面的都是我个人觉得很重要的。简单两个字，就是“思考”。
标签：手写 简单的 慢慢 用户 开始 业务 地方 鼓励 比较
原文地址：http://www.cnblogs.com/gdouzz/p/7253561.html
