解决一个问题时，可能会想到几种方法。考虑到代码量，运行速度，可读性等，怎么选择合适的方法？
我目前属于菜鸟水平，我得理解是在能运行的前提下，优先保证可读性，然后是代码量，最后考虑性能
不同的情况侧重会不一样，希望能结合情景分析下
新年第一答怒赠潜力股。
代码量不用考虑，基本上注重可读性的人都写不出又臭又长的代码，除非代码设计思路有问题，但这是另外一回事，非朝夕之功可以成就。
性能这种事情不是靠注意就够了的，和性能相关有以下几点建议：
知道你在做什么，尽量不要写你自己都吃不准的代码；
如果你必须要写，比如 copy 来的代码，你要知道如何测量它的性能（如果和性能相关的话）；
不要急着过早优化代码的性能，性能有没有问题需要有客观的可靠的测量来决定；
性能问题往往也伴随着平台或运行环境的变化，尽量写测试（对关键业务逻辑）并且尽量在更多的平台环境下测试，会帮助你定位性能问题。
说到底，最重要的就是可读性，可读性事关代码质量和维护成本。性能优化次之，并且不要靠猜测，要靠客观度量来发现和定位性能问题。代码量无需考虑，有可读性就基本有了代码长度的保障。
最后我想说可读性并不是字面上的意思那么简单，实际中想做好代码可读性还是很有些难度的，这方面建议多读一些经典好书先铺垫下，比如重构，编写可读代码的艺术等等。
前端js的运行期性能优化主要集中在对DOM操作的优化上，因为这是性能开销最大的部分。
在传统的，以内容展示为主的站点中，优先考虑可读、简洁、易用、易维护，这也是jquery得以发展壮大的重要原因，哪怕它的性能比纯粹的DOM操作慢了不少。
但在移动端网站或者是混合应用中的HTML部分里，一方面由于浏览器的性能远比不上桌面端，另一方面得益于W3C标准的良好推广，开发者越来越多地倾向于直接使用纯粹的javascript DOM操作，但这并不意味着可读性的权重就放在了性能的后头，只不过是开发者不用再为兼容性写更多的测试代码了而已。
个人的感觉是，好的代码往往不是那些性能最好的代码，而是那些最容易被人理解，最容易维护的代码。
我觉得要是一个人能够理解并权衡：可读性，代码量，性能的话，就不能说是菜鸟了。
这个还得看经验，多看看github上的源码，看看大牛写的代码，你会发现原来代码还可以这样写。。。
也可以看看 <<高性能javascript>> <<javascript设计模式>> 这些书