当初学的并不是计算机，半路出家；
当初只会c ，鄙视一切其他语言；凭借c ，凭借STL，面试的公司基本都进了，可谓意气风发！
当初特醉心于算法，对数学专业毕业的同事膜拜的不行，也嫉妒的不行；并下意识的向他们学习，向
他们靠拢；自豪于一些奇工淫技，揪心于代码的复杂长短；
时间苒苒，飞逝而过，转眼6年；
经历过不少项目，8成失败，2成成功；失败的项目有各自失败的原因和失败的理由，成功的项目
也都有各自成功的缘由；
有的产品模糊到怎么解释都解释不清楚，模糊到连自己也不知道自己做的是什么，有的简单到一句
话让人明明白白清清楚楚，简单到大家都知道目标在哪里；
有的进展如沐春风，畅快而淋漓；有的感觉掉进了泥潭，有如在齐腰深的水里跑步；
有的产品大到一个部门上百人为此挣扎，有的产品小到只有一个产品，只有一个开发，只有一个测
试；
有的产品复杂到模块堆积起来没人理得清楚里面到底在搞什么，有的产品简单到只有几个cgi和几个
数据库加一个后台管理端；
有的产品周期像传统软件行业一样，开发几个月，然后内侧，邀请测试，公测；有的产品一周开发
完毕，立即上线；
从简单的c cgi写起，写过js，用过as；后来转纯粹的linux后台了；
写过非常复杂的c和c 代码，但至今，只有那些架构精简，对外耦合度小，运行稳定的经得起时间
考验的代码才能让我自豪；
写过一些非常淫荡的代码，有时确实为了解决问题，但更多的时候可能是为了满足内心深处的那种
满足感而写的；
以后还会写些这些代码，一来练手，比如指针的妙用，永远都不过时，c语言是其他高级语言的基础
另外，好钢用在刀刃上，反过来：刀刃上确实要用好钢！
解决过很多bug，有时抓狂的core就因为自己粗心造成的，也有很多core就是因为架构不佳造成的；
写程序虽然还没达到某些高手的写一遍就没什么错误的地步，但还好，一般不是太复杂的程序，解
决几个拼写错误，基本ok了；
忍受过一些复杂混乱到无法维护的代码，有些是自己稚嫩的时候写的，很多都是别人写的；
用过很多c++写的框架，有些只有孤零零的socket包装，有些包装的层数让新手望而生畏；最后发现
这些所谓的框架基本没有满意的，甚至让我稍微感觉到还可用的都没用！
用c和c++写的东西写多了，写酒了，感觉到了c和c++的短处和缺点；越来越难以容忍这些缺点和不
便的时候，慢慢寻找可以替代c和c++的东西；于是一些脚本语言被慢慢发掘，python，perl，lua 都用，而
且确实能感觉到给我带来的冲击，不管是思想上的巨大转变，还是实际工作的工作方式；当被《黑客和画
家》这本薄薄的书吸引的时候，我又迫不及待的接触了comm lisp，然后才明白了什么叫黑客，也才明白其
实黑客其实都非常不喜欢静态类型语言的；脚本语言，这个名词得改一改，脚本语言能做的可以做的，远远
不只是"脚本"所能做到的！
从希望代码越复杂越喜欢到尊崇越简单越好；
从一个人写代码，模仿别人的代码做起，到后来慢慢教别人怎么写代码，到后来强力纠正他人的代
码，到后来直接操刀底层框架和共享库代码，然后强制用的人遵循某些规则...
从什么轮子都自己发明到慢慢接收开源产品到主动发掘有用成熟的开源软件到现在逐渐开源自己的
代码和经验，在吸取开源的经验和好处的同时，尝试为开源做点自己能做的贡献
当代码写的还不错的时候，慢慢尝试架构；慢慢理解了码农和程序员的巨大差别，我鄙视码农，但
实际上确实有很多人都一直只满足于码农现状；另外，我鄙视那种程序员只能做到30的说法，架构的好坏从
技术上决定了一个产品能不能成功；
好的架构，才能保证产品开发的速度推出和不断迭代，敏捷不是光靠想光靠说就能敏捷的，需要技
术和架构来保证；
好的架构，才能保证产品的易于扩展和易于改变，才能在最大的限度上满足不断变化且变化迅速的
产品需求和用户需求；
好的架构，才能摆脱对程序开发人员的一种依赖；坏的架构使不好的地方在系统中毫无阻挡的到处
蔓延，使得到处都是坏味道；好的架构控制了坏味道的四散；...
开始是简单的架构，到后来越来越大的系统，越来越复杂的架构；架构的特点是，小系统很难体会
到优秀架构的好处；但大的系统对架构的要求是非常高的；一旦架构有问题，会导致后面的系统越来越恶心
越来越窘迫；好的架构对于大系统的简化也是非常有帮助的；
经历了一些失败的架构，到后面的越来越纯熟，越来越明白了架构的真谛：简单，简单，再简单，
简单到愚蠢；低耦合，高内聚，重复用，一切自动化；
在经历了各类架构后，才嗅到了传说中的架构的坏味道之类的，才欣赏到好的架构是多么优美，真
的像一件艺术品一样！而好的架构是需要经验的，而且是丰富的经验的；这也正式我每过一段时间再看之前
的架构总会找出一堆不合理和可以改进的地方的原因；光经验也是不够的，好的架构也是需要天赋的，有时
有些想法思路是偶尔脑光一闪才出现的，脑光闪不闪还真不是自己控制的了的；这也同样说明：好的架构
也是艺术！
关于管理，其实我更加专注于技术，甚至有时会因为过于倾注于技术而忽视了管理；手下带着一帮
兄弟确实不轻松，他们的技术水平层次不齐，但感觉都和我工作没多久比较像，可能算法之类的还不错，但
对于构建，对于架构，对于集成，对于自动化，对于公共库，对于脚本语言都没有什么很深的映象和概念，
在他们的世界里，似乎只有c++（甚至没有c）；对于更深层次的比如重复的危害，手动化的低效等之类的感
受可能就更少了；培养他们真的要花很多时间；
兄弟多了，肯定有些会走，然后新的兄弟补上来；...
渐渐的需要把更多的时间放在项目管理上，放在项目的执行追踪上面，放在团队成员的培养上面；
尝试看很多书，最初是一些c和c++的纯粹技术书籍，慢慢的到架构，到构建，到敏捷开发，到部署，
到项目管理；看的书越多，越觉得互联网任何一个成功的产品都是 艺术+科学+管理 的工程杰作；越来越感
觉项目开发远不是画写UI,写些代码那么简单
买了很多书，不轻易买书，买的书都是觉得可以看很多次的，每随便一翻都能有收获的书；也买过
一些书，后来发现没啥用，于是就藏起来了，好书我都直接放书桌的一边了，闲暇的时候，随手抽出一本，
从没失望过；
这些书中，《代码大全》对我影响最大，其次是《unix编程艺术》--unix编程真的是一门艺术，绝对
不是码农所说的毫无技术含量，也绝对不是码农所崇拜的数学才牛逼，其实编程和数学没有多大的关系，只是
学数学的人编程在某些很少的项目中会有一定点优势而已，仅此而已；理解这点是我在看了《黑客和画家》
之后最大的收获；还有很多比较经典的，比如《从小工到专家》《持续集成发布》...当然一批经典的工具书
比如《unix网络编程》《perl编程》,APUE之类的；
接触的多了，看的书多了，想的就多了，反思也就多了；
