到今天为止，历时两个月，我基本完成了来到新公司的第一个中型项目的编写工作，现已在生产环境部署。
从公司角度来看，这个项目的完成按规划将公司推到了下一个既定节点，从我个人来看，这也是我职业生涯的里程碑。为什么会这种重要呢？其实这个项目的技术深度并不能让人引以为豪，值得一提的可能就是它的广度——相信这也是大部分如我一样初中级开发者从业中经常遇到的东西———产品策划的时候想要抓的热点一个接一个，衔接的时候头发也是一掉一大把。那么必然的，在逐步向成熟产品靠拢的时候，复杂度（不尽等同于难度）也在递增，到今天，回首这两个多月，也有一些感叹和体悟，才想写下这篇文章跟大家聊一聊。
1.从意图去理解产品（结果逆推过程）
正确的认识是加快速度的基础，在讨论或接受需求之后，要先稳住跟脚，先从宏观的角度去思考，做这个产品是为了解决什么问题；如果有，为解决这个问题，产品会有怎样的延伸（当然，也可以想想为什么要解决这个问题，然后去找老板砍需求XD）。等等，不要着急点退出，我并没有在总结怎么做一个产品经理，事实上，这些概念上的想法对于我们码农完成工作同样是非常重要的。凭心而论，从业近三年来，我经手过的项目做出来之后有好有坏，有能让我记忆深刻的，也有让我羞于启齿的。生活也像玩俄罗斯方块一样，好事会消失，坏事会累积，忘掉幸运，总结教训才能本文的目的。
大部分人对于每天都习以为常的概念，都自以为明白了，但实际上都是下意识的，并不是主动的认识。我这两天看过一篇关于架构的佳作，里面举了个例子：问“什么是桌子？”，答四条腿，一个平面，可以用来放东西。乍一想，没错，但柜子其实也是这样的。但我们不会在柜子上办公和吃饭，所以桌子实际上是和椅子配对出现，可以让人坐在椅子上，手还能够支撑在一个平面上继续开展某种活动的东西。与此同时，还要延伸思考，桌子为什么成为桌子而不是柜子———这不是一个白马非马的辩题———桌子为了让人坐着开展活动，是有一个容纳膝部和小腿的空间的。有了这些配置项，那么桌子才是你需要的那个东西，不至于失之千里。
上面的举例算是将我们开始前的准备工作抽象化了一部分，站在需求层去理解产品，知道它是什么、它为什么这么做对于它应该怎么做的重要性不言而喻。从表面的东西去挖里面的概念，将之抽离出来，作为我们的大纲，当然，也是我得以继续把键盘敲下去的铺垫。
2.用概念去架构功能（提高项目的可定制化）
我们了解了需求的基本状况，相当于基本敲定需求文档，明白了此项目的地基工程，接下来开始进入开发准备阶段。那么，我们继续以上文的桌子举例，刚才造好的桌子只能满足基本的使用，现在我想在上面添加书架用来摆放一些我的技术书籍，比如说《Java从入门到入土》、《Python从上手到上天》、《JavaScript三年模拟》等，还要让这些书分门别类并且占用最小空间。这个书架我造到一半了，好嘛，产品经理过来跟我讲，买家家里的小孩喜欢在桌子上跳舞，需要我配置足够大的空间。不需要去管为什么跳舞要在桌子上，实际开发中要满足抱着猫跳舞的情况也不是没有。
相信大家都看过那个用户走进酒吧点了一份炒饭，然后酒吧炸了的段子，我们虽然不至于会碰到这种极端场景，但是酒吧添加供应品的场景倒是难免。这次我们就用这个将炸未炸的酒吧做例，今天酒吧老板决定要中西酒一起发展，决定酒吧不光供应白兰地轩尼诗，还要上新二锅头和五粮液，对于方案提供商来说，这只是一个普通添加，但对于我们这些服务员来说，上新功能简单，后续影响麻烦。万一接口一铺设，本应取出来的白兰地变成了红星陈酿，顾客不得骂街嘛。对于项目深度很可观的项目来说（如果每一行代码都能直观的影响UI的话，那这个项目就不在此列），这并不算罕见。更何况我书写的js语言本身就是弱类型动态语言，一些粗糙的代码很可能就要了我的老命。
那么，诸如此类的情况对于我们项目的可扩展性和可定制化就有较高要求了，而这两者如果在项目搭建前没有一个清晰的脉络，开发中再转向的话花费的精力和时间是论以倍计的。所以，为了避免这样的无意义损耗，进入开发环境前，进行一个自我思考是非常要必要的。要完成这一既定规划，就不得不讲一讲百谈不厌的面向对象，我并不想在宝贵的七夕夜长篇累牍的抄百科和前辈们的理论，就再用桌子举个例子。比如说，我要完成我要用来放书的书架，有两种方法：
1.我去买木材、螺丝、锤子等工具，自己造一个安到上面去；
2.我去家居市场，喊一声，老板给我来个桌上书架。
没错，第一种可以粗浅的理解为面向过程，第二种就是面向对象。相比较起来，第二种有什么优势呢，我完全可以不用去知道书架是怎么做的——降低耦合性。而且如果我突然不想要书架了，我想要个猫爬支架，我就让老板给我重新整个——提高可维护性。再者，如果我突然又需要在书架上再安一个书架，我不需要做两次，我只要买两个就可以了——提高可定制化。（值得一提的是，我并没有偷换概念的意思，的确，制作书架都是需要第一步的，区别是使用时做还是使用前做。）
引申下来，我们知道要这个书桌要有一个书架，不能具体化的，流程化的去造一个有书架的桌子，而是变成了做出一个配有书架的-桌子-。哪怕有一天，这个书架要做成地震前要显示文字提示的功能，我也不用去动桌子，我只要去削书架就行了，削提出功能的人也可以。
所以，为了避免成为bug制造商，在正式进入中大型项目开发时，将解耦放在第一位将是我追求的重中之重。因为进行项目设计需要做出的决定中，必然会包括逻辑结构、物理结构，以及它们如何影响到系统的所有非功能性特征。这些决定中会有很多是一旦做出，就很难更改的。
3.用以人为本的角度去实现程序
以人为本是个很时髦的词，我用在这里，意思也很明了，毕竟程序是人用的，代码也是人写的，文档再花哨也是死物，他无法知道程序员的长处和弱点，也无从得知真正编写时不同人的代码追求和书写风格，所以，我强调一点，写代码一定要保持成熟和微观的主观想法。这决定了你将会为这个程序加多少次班。
确定了对程序的认知，还需要确定对自己的认知，清楚我要成为一个什么样的程序员，是追求优雅的代码的文艺程序员，还是想追求速度的结果论程序员；清楚我在从业中自身的缺点，是不是一个粗枝大叶的人，是不是一个容易钻牛角尖的人。也要确定对小组同事的认知，同事会在哪方面让你做的更好，会不会你们的编写风格有什么冲突等等等等。我无意去煲一碗鸡汤，这的确是经验之谈——说句通俗的，我们普通的码农，最怕的是什么，还不是出bug，要说比这个还怕的东西，那就是这个bug是我写的。
尾声
我并不算是一个很有天赋或者很聪明的人，进入编程也是机缘巧合半路出家，磕磕碰碰也写了不少烂活，但我还是希望能以有涯求无涯，起码在我结束从业时能达到我想要的高度或者无愧于心。写这篇文章也的确是在本次项目中碰到了不少从未遇到或从未注视的问题，走了不少弯路也跌了不少深坑，把这些东西写出来落到互联网上第一给自己个警示，第二也让大家茶余饭后做个笑谈和借鉴。之后我将会仔细描述碰到的业务问题，视复杂情况写出不同的篇幅，之所以将此文开篇，我是真的认识到，代码打得好不如勤动脑。大部分人不是Jeff Dean，也不是阮一峰，想要少背锅就得多动笔，想要少挨骂只能少张嘴。就好像我以前打LOL，放连招的时候总是先熟悉一下键位，就算到时候还是慌乱，起码不会懵，天赋这是老天赏的，大局观却是可以练的。
那么，这篇文章到这里也就结束了，我深知，我尚且还是一个菜鸟程序员，很多的理解都是以管窥豹不足为鉴，写出来的东西也难免有所纰漏、贻笑大方，也希望发现问题的朋友能斧正一二，携助前行，再次感谢。
