阅读和实践是最好的老师

这是这几个月来最深的感触了。 随便写写大家看看就好。 讲几段故事吧:

第一段故事————学习WEB开发。

今天的4月份，但是刚从新浪Qing离职回学校潜心读书。
突然有一天看到有一个比赛，HTML5的，感觉这是个不错的方向就去参加学习一下吧。
于是找了几个同学组了个小队，然后项目就开始了。
选了近一个月吧，最后决定做一个像素主题网站。一来觉得会简单一点，二来像素，8bit，数字和艺术的完美融合呀。

简单介绍下队伍情况：
我：产品还行、技术么简单的WEB技术略懂一点。
小越越：前端出身。
璇爷：WEB开发经验 === 0,其余都还行。
野哥：做过OPENGL 和XXX、XXX、XXX、XXX、XXX…

于是决定我去做产品和后端。小越越和野哥去做像素作品制作功能的实现。璇爷去做UI和部分前端。

这里插一段吧，我们准备做个2D和3D两个版的，  
但是商议的结果是用three.js来实现3D版，然后通过改变视角和交互来转化成2D版的。这是我们犯的比较严重的错误。  
一次在open party上吴军老师讲过正确的模型可以很轻松地解决问题。
如果选择了错误的模型，就会一直选择各种方式来补漏洞，最后直到补不下去了。  
现在开来实在是太对了。所以各种恶心的解决方案基本都是不可取的。  
可能现在它WORK了，但是会给你以后的工作带来各种各样的麻烦，最终把你弄得WORK不下去了。

回来，继续讲。
因为之前只用过PHP，而且是无框架纯手写。
这一次的项目有点大，所以还是仔细地考虑了这个问题。

当你对一个领域知之甚少的时候，问询专家可能是一种最好的方式。

于是我去问了luin神，当时推荐了Yii,Bootstrap。

专家推荐的东西的东西一般都是好东西，但是适不适合你就不一定了。

然后我就去了解了下Yii和Bootstrap，了解的方式就是去知乎、百度、google、然后对应的社区什么的。 最后后端我选择了CI框架，原因是文档全、上手快。Bootstrap的确很好用。

之后开始学习框架使用，就是跑跑DEMO随便写写。一个星期左右，大致明白怎么回事了，开始用来实现项目。

这里我发现了一个巨大的阻碍就是追求完美、先要一步到位。  
后来发现与其费劲脑子做设计，不如去实践遇到问题，然后解决问题。

先学前端么，写写练练手，就当做了个原型。效果的确很好。
然后学后端，先写一些简单的功能，验证下自己使用的是否正确。

跑的太快容易扯到蛋，绝对的真理。

之间又写了很多小项目来练手。

就这样慢慢写到了6月份。然后》》》

第二段故事————一次“敏捷”实践

开始思考设计模式，开始接触RESTFUL。
主要在于MVC三层C层和M层放什么我总掌握不好，最后干脆C层就是把数据传给V层。 这样以后写其他平台的客户端也会好干很多。 万幸CI对rest支持很好。。接下来就是重复实践跑DEMO学习了。

后来学校软件工程过程课要搞敏捷开发实践。。。 这个事说起来很无语，10多天？敏捷开发？语言不一样？平台不一样？XXX不一样？怎么能够在一起。

本来我们自己组了个队，清一色的MAC，技术水平也都很好，自己熬几天写完整个项目都不是问题。不过不幸被不知情的老师拆散了。

不过还好最后队里的技术水平都还不错，就是大家习惯的语言平台不大一样。还好没有windows。

队里一个前端大牛、一个服务器大牛、一个后端前端都微懂的小菜鸟就是我。其余的都各自会点不相关的。
讲下用的技术吧。

后端 CI REST ,我鼎立推荐，主要是因为自己很熟悉，很清楚能告诉其他同伙怎么用。另外但是大家都会的也就PHP。其实后来发现会的最多的是python只不过有的人没说。。
前端 backbone coffeescript bootstrap less 还有各种自动化测试的东西。

先写收获吧：
1. 团队的想法要一致。
2. 统一的开发环境。
3. 维持一个问题WIKI
4. 适合团队的技术解决方案，我们的前端选择就不是一个好方案，因为其他没接触过这些东西的人很难快速掌握。
5. 不要过早设计。
6. 要乐于重构，重构前要想想为什么要做这次重构。
7. 有些事情自己一个人做可能要比两个人做要快要好要开心。
8. git是个好东西。
9. 布道之道那本书一定要看，我反思整个过程，收益良多呀。

讲下大致的过程。
后端是我负责，6人小组，3台MAC做开发机,自由结队开发。 情况3个人一条集训后，可完成开发任务。另三人，一人有事长期不在，另两人配ubuntu开发环境数天。。 项目中期API进行了一次大范围的重构，GIT的使用也布上了正轨。 开始我很抵制GIT，后来见识到git的有点之后，自然而然地接受了。

前端情况就不大好，除了一个前端大牛、一个会JS的，其他两人没有WEB开发基础。所以less\coffee\backbone什么的徒增了很多烦恼。大牛又因被安排讲自动化测试，导致真正写逻辑的就一个人，还是刚接触coffee。现在想想这个技术方案真是不大合适。这就是大跨步容易扯到蛋。

其他的一些东西有些觉得有用，有些就有点形式化。 其实东西有没有用，要看你在什么样的团队，干的是什么事。 把宝贵的经历放在最有意义的事情上才是对的，别的都是扯淡。

第三段故事————个人开发阶段

放假回家，开始对之前像素项目的后端代码进行大范围重构。 不过很快陷入了过度设计的困扰之中。然后就停了一阵，看看书，玩玩服务器。 把开发的脚手架搭好。

整理了下本地的开发化境， 将本地项目的访问方式设为真实域名，通过修改hosts文件来切换线上和线下。主要是为了解决用到很多插件跟域名有关的问题。

在linode上配置好git,本地写好代码push至GIThub,然后在linode上pull下来，简化部署操作。

将资源文件移植到阿里云OSS上，这样前端后端就严格分离了。前端用一个.html就可以进行开发，合代码的时候改动量大大减少。

然后单线程地做事，因为实践中服务器、后端、前端很多事，有时候一忙就都乱了，所以一段时间一干一件事，可以说一个完成功能场景、可以修改前端的整体样式代码结构。

之后觉得来不及了就开始涉足canvas部分。 其实克服心中的恐惧，投入一定的时间，不断地去实践，一切都会相当地容易。 我自己一直对JS有点恐惧，莫名的恐惧。等到自己可以做点什么东西出来的时候，这种恐惧自然而然地就消失了。 这个过程可以总结几点

动手做最重要。
获取知识要有选择。
解决问题最重要。

这里会有个问题，开始不懂JS就盲目地写，写出来的东西也乱七八糟各种BUG。其实这是一个好事，出现问题，解决问题，然后你就学到了有用的新知识，这比无谓地看一堆可能一辈子都用不到的东西要好很多。不要怕写错、不要怕浪费时间在一些你觉得份SB的问题上，其实这可能事最有收获的事情。

分割线

以上存按时间记录了一些收获，看法什么的。基本都是实践，现在说说阅读。 阅读和实践的关系是融合在一起很难分离的，通过阅读书籍、手册、文章可以让你了解一些大概，这些大概作为实践的基础。而在实践之后，阅读，来反思实践，会收获颇丰。所以保持实践和阅读的习惯，他们会成为最好的老师。

本文转自：图灵社区http://www.ituring.com.cn/article/10158