转载请保留原文链接：/zzx023/article/details/83068228
基本上到这里作为一个cocoscreator以及微信小游戏的开发者，我相信都可以完成了入门阶段的学习了。
不过比起cocosAP、微信APII、js、编辑器操作等方面的入门，我更希望再开发的过程中大家能够学习到并拥有思维上的一些进步。
现在我们就来总结一下：
1.掌握正确的学习方法
1官方文档以及示例
官方文档：/creator/manual/zh/
官方API：/creator/api/zh/
官方示例：/cocos-creator/example-cases
官方视频教程：/creator/manual/zh/video-tutorial/
如何引擎或者SDK，想要了解或者掌握的话，过一遍官方文档和示例使必不可少的，目前creator的文档还是比较全面的，甚至有些时候一遍还不够，需要两遍、三遍……
这一点对于不管是还没入门的同学还是已经入门的同学来说都是相当重要的事情。
官方文档的重要性就和电器的使用说明书一样。使用前没有仔细阅读说明书的话，那就很可能会出现两种情况：
不知道该使用什么样的方式去实现一个需求。
举个例子，我经常在论坛上面看到一些帖子，问题都是“怎么使用子域实现微信排行榜？”，“怎么把坐标从世界坐标系中转换到节点坐标系？”等等。其实这些在官方文档中都有详细的说明，为什么不花个5~10分钟好好的看一下官方文档？
凭着自身的一些开发经验，在没有全面了解官方文档以及示例的情况下，对一些需求直接上手进行开发。这种情况下，要么就是写到一半发现有些问题解决不了，要不就是很粗暴的实现了需求，但是耗时巨大且不容易维护扩展。
举个很简单的例子，之前有个同学之前是用2dx的，没有使用过creator，项目要求他去写了一个类似排行榜的UI，他就凭着以前使用2dx以及js的经验实现了一个功能。我看了一下，运行中基本上功能没问题，不过他的每一个cell都是通过new组件或者子节点，然后add上去实现的，整段代码又臭又长。当他后面发现prefab这个东西的时候才恍然大悟，妈蛋，这段代码几行就能写完……
这些都是血的教训，所以在我之前的章节中，我都引用官方的文档给大家进行参考。
2社区论坛
论坛是个好地方，当遇到一些疑难杂症，想了半天也没有头绪，同时官方文档可能也没有涉及到这部分的问题时。上论坛看一看，搜索一边看看有没有同学也有相似的问题，看看别人的解决方案。
整个论坛还是比较活跃的，踩过的坑基本都可以看到解决方案或是替代方案。
3百度“师父”
论坛毕竟有些时候问题答案这些都比较分散，而通过百度、Google你可以找到前人已经总结好的一些经验以及方法，通常这些都会有一定的系统。
总而言之：
培养自己的自学能力。切忌做无脑“卡卡西”——无脑复制粘贴。
只有印象深刻的问题，在解决之后才能有较大的收获。不要碰到问题就轻言放弃，碰到一个小小的问题不试着去解决反而无脑论坛求解决，这其实也是另一种“懒”程序员的表现。
2.掌握常用的调试方法以及分析方法
log，断点，堆栈信息，heap snapshot，抓包……有很多常用的调试以及分析问题的方法，这些方法一定要熟练掌握。只有这些方法才能帮助你理清一个问题的脉络，当你发现了问题真正的触发点时，其实里解决它就已经不远了。
之前就有带过一个应届毕业生，经常跑过来问我问题该怎么解决，一开始我还觉得小伙子还挺积极的，遇到问题不做“闷葫芦”，后面一听问题气死我了。
“哥，我的那个输入不知道为什么没作用啊，我照着之前咱们XXX项目的代码写的，怎么会有问题啊？我换了好几个地方去调用，都没作用”。
模仿代码没有错，我们很多时候入门都是从模仿开始。不过他的调试方法明显有问题，没有log，没有断点，没有看上下文或者引擎的代码去进行理解，单纯的只是试图寄希望于“换个调用位置”或者“换个实现方式”。这种处理问题的方法是很低效的，其实当时只需要他能够了解一下上下文代码，然后在一些地方打上断点调试一些就不难发现，问题很简单，插件没有导入到引擎中并且初始化……
3.CodeReview
Cocos在creator之后，真正的转变为了一个游戏引擎。我们不需要过渡的关注到框架这些东西，直接往上面堆功能，堆gameplay就可以了。
这让我们整个开发变得快速，方便。
但是不要被这种快速，方便搞晕自己的方向。
写完的代码，实现好的功能，一定要进行CodeReview
一方面Review后可以加深对于代码的理解以及知识点。
另一方面Review后你可以发现自己代码的一些短板，根据这个短板，多思考，试着重构一下代码。慢慢的坚持下去，你会发现你的代码越来越有质量，越来越好维护。
不识庐山真面目，只缘身在此山中，换个角度看之前的代码就可以发现一些可以优化的地方。
比如我现在回过头来看前面这些代码，感觉写的好垃圾…………
4.从需求出发
一段好的代码，不以代码量来评估，也不以复杂程度来评估，不会因为你用了特别高深的技术而加分，也不会因为使用了一些特别简单的方法而减分。从需求出发，一切都是为了解决问题，同时也要高于需求。
我喜欢用一句话来形容一段好的代码：不多也不少。
好了，啰嗦了这么多，最后附上项目的源码，以供交流：
链接:/ayarami/examples-game-FishingCat
最近做了一些优化调整，主要是降低耦合，让代码更符合creator组件化的思想。所以源码和教程中的代码会有一些出入，还请见谅
