【51CTO.com原创稿件】曾在移动、前端、后台都有涉猎的小星星，不说十八般武艺样样精通，也是熟知通晓，运用自如。而今回顾他的IT坑，将成长的经验分享给大家。从JS到Java再到PHP，面向全栈的攻城狮已经上线。
小星星·PHP
小星星的入门语言是AS，没错，就是Flash脚本语言。从偏门闯入了这浩大的IT世界，于是他会了JavaScript 、HTML、CSS、C/C++、Java、PHP等语言。Flash追求美观和谐，它总能给人一种美的享受，于是“爱美”的这种习惯一直保持，以至于后来对于其他语言的学习都会各种纠结与格式化，慢慢练就了洁癖的本领。没错，就是洁癖！
萌芽意识
初识ActionScript，是为了满足Flash场景中一个交互按钮的响应。为了加上onclick这个事件，小星星记得那时候足足花了半年的时间（自嘲下，那时候就是那么地，艰苦！），在看到提示信息出现的那一刻，整个人几乎激动到跳起来，这是多么的来之不易。自此他意识到了“对象”的概念，即真实存在的物体，或者称之为Object。
有了对象，就可以把很多重复的图层元素归并到一起，很多场景操作就好办了，具体操作方式就是在时间轴上抽象出各种组件，通过组件组织成各种场景，抽象的最大好处就是可以复用，降低场景上下文之间的耦合，这样也使作品有更好的可维护性。
自我挣扎中成长-发现瑕疵
小星星接触了JavaScript 之后，发现语法上它跟AS惊人地相似，不奇怪，后来了解到它们的核心都是ecmascript，也罢，入门JavaScript 几乎没花什么力气。在借助AS拿下JS常用的半边江山之后，发现某些功能的某些写法实在是冗余，或者说不够干脆。比如：
- var hasContent;
- if(arr.length > 0){
- hasContent = true;
- }else{
- hasContent = false;
- }
其实可以很简单的一个句子处理好： var hasContent = arr.length > 0; 当然如果要严谨一点，这里还有一个定时炸弹，即arr这个变量为null的时候会报错无法继续，所以完善点应该是：
var hasContent = arr != null && arr.length > 0;
上面这种是很简单的一个变量判断与赋值，完全可以写得很简洁。另外是变量与方法命名，有些人喜欢驼峰法命名，有些人喜欢小写字母加下划线，这些都没问题，统一的写法看起来会让人感觉很舒服，但往往有一些看起来就狠抓狂了，比如上面这个例子用他们的写法：
- var a;
- if(b.length > 0){
- a = true;
- }else{
- a = false;
- }
这种代码的可读性可以说非常地差，每看一行几乎都是用猜的，上面这个还比较容易猜，如果篇幅再大一点，那看的人就会感觉要吐血。
所以，一段代码或者一个程序，从编码角度来讲是马是骡，看它是否整洁是否好理解就一清二楚，当然健壮性也很重要，总不能它跑着跑着就异常挂了吧。于是乎，只要接纳第三方代码进入小星星的作品，他都会对代码进行整改，让它变得跟自己的原有逻辑不那么格格不入，当然作者还是署名原作者。这么下来也可以说练就了自己的一双火眼金睛，别人的代码哪里可能有问题一看就清楚，也算是自我纠结的成果吧。写好代码，为自己方便，也为他人方便。
归零与记录
跨过第一个门槛之后，编码之路会顺畅很多，基本上就不用纠结语法层面的东西。取而代之的更多的是去思考要完成一个功能该怎么去组织代码结构，怎么样做会比较高效和健壮。比如封装，比如分包，比如抽象公共接口，这些都需要有足够编码经验作为支撑。小星星个人的话，因为平时都趋于追求完美，各种觉得好的情况都会尝试，于是有了下面的这个作品，算是他个人从事Java留下的痕迹吧。
各个Java项目积累下来的工具包
是的，这时候追求跨平台，即Android有的东西都想在PC实现一遍，或者PC有的东西都想在Android实现一遍，这就是纠结，烧脑！好处是在其他编码工作上遇到一些兼容性问题会考虑得比较周全。
这里面就有个有关图像识别的东西，当初好像是因为一个依赖库版本的问题（它，默默地升级了），搞得好好的代码硬是编译不下去，各种尝试之后无丝毫进展。在一筹莫展的时候，小星星翻烂了的度娘在一个非常不起眼的角落给了条信息“xxxxx最新发布版本为v2.4.0”，心如死灰的他重新燃起了希望，马上折腾开来。果然，升级了依赖库之后一切都回归正常，这是个巨大无比的坑，绝对是！当时已是午夜，为了铭记，决定将这坑记录下来，于是结识了ddJava（译为：顶顶Java），坛主为“大猩猩”，当时这是个全新的论坛，几乎捡了个沙发，哈哈，在此感谢猩猩！
论坛发帖记录问题，同时也是个回顾的过程，这期间不无可能会发现新的问题新的解决问题的方案，从某种程度上来讲，这也是一种学习的过程。解决了问题，再回过头来看，可能会发现更好的解决方案！
编译问题解决了，又遇上了另一个问题。当时的匹配算法比较纠结，只能针对指定区域进行匹配。指定区域就是要确定坐标，做法是匹配传参时，将坐标也一起传过去。小星星这样想也就这样做了，大半夜地在调试，当完成时他跟公司大牛人物提了这事，结果对方来了句：为啥你的坐标不放在图片文件名里！匹配时直接解析文件名，这不是更方便？小星星恍然大悟，确实大神级就是不一样，他们往往能抓住问题的关键点，可以很犀利地处理好问题。这是学习的另一种方式，跟大神交流，分享自己所知，让大神指出改进优化的地方。
逆向思考
当对功能代码已经轻车熟路的时候，你会发现眼前的小问题本不是问题，但无数个小问题放一起形成的大问题却很难去逾越。这就是成长过程中的另一个坎。技能方面已经能驾驭语言的情况下，剩下要思考的更多的问题是系统性能和业务逻辑，就是自己的代码如何完美地配合去完成一个既定业务，又不影响到系统的可维护性和稳定性以及运行效率，可能方法一可行，方法二也可以，方法三也凑合。这时候就需要从思维上上升一个高度，跳出来，从顶层往下看，从需求引导自己的编码。
比如产品需要在某个列表中添加一个搜索选项，而这个选项涉及另外一个或者几个千万级大表（MySQL，是的目前来说它还是非常受欢迎的）。从语法层面，这个问题非常简单，做法是直接连表查询，条件中加入新的过滤条件，这种做法能够实现产品的需求，但带来的问题是使用系统的人会因为慢而抓狂！问题在于大表连表查询，这很消耗数据库的性能。用户需要这功能但TA不会接受由此带来的慢，所以方法一不可行。
方法二有？嗯，毋庸置疑肯定是有的！既然是大表跨表检索影响效率，那就不让它跨表。做法是将目标条件先在其所在的驱动表先过滤一遍获取目标值，再用这个中间的值去主表里过滤查询。相信这个方法也不难，但在数据量上去以后这种做法绝对会比直接连表快上好几倍。
方法三？是的，从更高阶的层面去思考。最彻底的做法是从关系表的设计出发，从根源上尽可能地避免大表的连表查询（嗯，这个还未实际尝试过，事实上它是可行的，也见过某些骨灰级的任务这么做），另外还可以借助服务器的强大的计算能力，将目标数据读入内存在内存中进行条件检索，相信这种做法对于多个大表检索的性能会有指数级的提升。
【写在最后】
步入IT遇到了无数的坑，但“较真儿”精神，让小星星逐一攻破每一道关卡，也从当初的旁门小白向全栈发展，无论是移动、PC，还是前端、后台，还是开发、运维，小星星坚持了，钻研了，每项任务都竭尽全力去寻找最优解决方案。多想、多交流，你会发现离全栈并不遥远！
如果你也愿意分享你的故事，请加51CTO开发者QQ交流群 542270018联系群主小官，期待你精彩的故事！
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
