打造高品质的前端代码
我很喜欢用面向对象写较大规模的程序，写个几百几千行的代码，还没尽到兴，就结束了，很没劲。写大一些规模程序时，体验就会完全不同。
起初你做好规划，哪儿哪儿栽下几棵小树苗，然后看着这些小树苗会不断地成长，枝叶越来越茂密，而树也越栽越多，超初的小树苗还是主要由着你的喜好来修剪，但到了后来，很多时候树苗们已经差不多自已有了灵魂了，如何成长是靠他们自己，而我只是个修剪枝叶、浇浇水的花匠。小树苗越长越多，越长越密，慢慢就变成了一片森林。
尽管这片森林是由你自己亲手栽下来的，但你慢慢就看不清全貌，被掩埋在森林中。好的花匠，会在栽树苗时注意留下主路，即使树苗变森林，也依然不会迷路。然后慢慢惬意地欣赏森林的变化，看着它自已生长和演化。
虽然程序完全是由你写的，但其实只有前半截是按照你的意志在布局，在发展，到了后半截，你会发现你的程序活了，你设计的一个个对象有了灵魂。前半截你创造了一个世界，这个世界有哪些人，有什么游戏规则，全是按你的设计创造的。到了后半截，对象们便在这个世界中活动起来了，你在这个世界中做着一些维护秩序的事，把一些坏人关起
我不是个喜欢”深究“的权威型工程师，所以一些观点并不敢保证精准和正确。我喜欢就自己的经验，谈一下个人的理解，如果说错什么，敬请批评指正。
1）关于面向“类”和面向“对象”的问题
面向对象编程是种编程范式，在提出这种范式之初，关心的东西只有“对象”和“对象间的消息传递机制”。而随着面向对象范式在语言层面的不断探索，于是出现了“类”的概念，有了面向对象三大特点“封装”、“继承”和“多态”。现在有不少人在追本朔源，说“面向对象”现在变成了”面向类“，已经不再是它的初衷了，面向对象走向了错误了方向，应该反思。
反思是应该的，追本朔源可以帮助我们站在一个更高的角度来看问题。但结论我并不认同，私以为”类“的概念的提出，是对”面向对象“在实践方面的一个很好的补充和完善，它属于”面向对象“理念的”实践“，而且是一个非常好非常精彩的实践。我承认在当今的实践中，面向”对象“实在太容易变成面向”类“了，类的作用非常重要，可是我并不觉得提高类的重要性对编程带来了多大的麻烦。类的作用变得如此之大，我觉得并非”走火入魔，误入歧途“，而是”自然发展，自然选择“。没必要为”类“的重要性太
css长命名可以带来好多好处：
1）有命名空间般的作用，不用为命名冲突担心;
2）选择符权重低了，在层叠时容易被覆盖，不用为了获得高权重而不停地加长子孙选择器，形成恶性循环越加越长;
3）少使用子孙选择器可以让css更好的和html结构解耦，在抽取css模块时更好地保持独立，不依赖其他模块和html结构，在多人合作时，特别是模块需要给别人复用时，特别安全，易用。
我暂时还没遇到css长命名带来的坏处，所以私以为这是种最好的实践了。
less这种东西我兴趣不大，感觉那是程序员的玩具，想通过编程方法跨界解决css问题。可是css该面临的问题一个也少不了，只是增加了一个编译过程而已，玩法变得更高级了，但降低了自己对最终代码的控制力，类似java和c的关系。更要命的是提高了门槛，首先是上手门槛，其次是维护门槛，再来是团队整体水平和规范的门槛。水平高的个人玩玩无妨，可是大规模推广真心不看好。
从PHP简单的语法称霸Web server编程，html战胜xmI成为网页标记语言，json格式淘汰xml格式成为接口的主流格式，ES5淘汰ES4等等等等，事实一再表明门槛越低越能生存下来。再看看咱前端吧，js库中，YUI，Dojo，Ext哪一个不比jQuery强大数倍，可是jQuery却赢了，
我很喜欢看三国，中学时候第一次看《三国演义》的书，某个暑假花了半个月看完。然后零零散散看了些三国的电视剧，看得不全，却也不少。再然后喜欢听易中天品三国，每次易老师的解说都听得津津有味。以上这些是我对三国文化最主要的了解途径，我不是个三国专家，但对三国文化也算有点小心得。而自工作以来，我也辗转过几家不同的公司，亲身经历过不同的公司企业文化，另外，也从朋友们口中了解过一些其它公司的文化。昨天看到腾讯小马哥谈“工程师文化是IT企业最好的文化”，我没待过腾讯，不知道腾讯的工程师文化具体是怎样表现的。想依我这个普通工程师自己的一些见闻，就着三国漫谈一下我个人觉得最靠谱的企业文化。
看三国时，有几个点让我印象很深刻：
1）十八路诸侯联军大战董卓——人多心不齐，难成事。
这是三国早期，一个非常振奋人心的高潮，非常好看。单凭那阵仗，多气派啊，而且是正义之师，师出有名，照理说，这仗应该是不难打赢啊。可是，这里面实际问题大着呢，十八路诸侯是真心想来讨伐董卓的吗？大部分人不是，所以袁绍联军总司令这个位置只是大家表面上投给他的，诸侯们却各自有着自己的小算盘，
对于周教主，一直有些话特别想说，直到这两天看到周教主要进军手机业，更是忍不住想说几句了。
先声明，我没有在周教主身边待过，并没有亲身和他本人有过深入直接的接触。所以这是一个纯粉丝，在谈自己对偶像的见闻和感想，一家之言，而且是一个远远的旁观者的一家之言。因为涉及到很多公司，流弹击中的话请勿见怪，对事不对公司，而且我是真的”不明真相的观众“，只是一个旁观者，如果我说错了，也可以作为一个普通旁观者的意见供参考。
国内互联网界，我最佩服三个人：丁磊、史玉柱和周鸿祎。
对丁磊的好感从他开始养猪时开始。如果没记错的话，网易应该是在08年底或09年初宣布要养猪的。记得那年的猪肉价特别高，养猪利润很大。然而谁也想不到身为国内门户四巨头之一的网易，居然会跨界跨这么大去养猪。老实说，IT这个行业听起来算是个很高级的职业，这个领域的人大多会有种职业优越感，不论实际赚不赚钱，至少表面上很有面子。一听到“养猪”这个词，脑子里第一反应就是农民，还是又脏又累的那种农民，做这事至少在面子上似乎很有点自降身价。为此，当时很多人第一反应就是惊讶，惊讶完了之后马上是轰笑。
对于职场和职业发展，过去这两三年因为角色转换，有了更多机会遇到、看到和听到很多事，了解的信息越来越多，经历越来越多，渐渐想明白了很多事：
1）是地雷就会爆炸，从一开始就注定了，什么时候爆只是时间问题，但一定躲不了。如果你有选择权，能一开始就避免这雷，就尽量避开。如果避不掉，那么一定要做好准备防着，尽量将其危害控制到最小的范围。驼鸟是最坏的做法，客观问题不会因你主观视而不见，就真的不存在。
2）个人只能在一定范围内努力做出一些改变，对更大范围内的事挣扎也没用，要明白妥协和明哲保身。要明白，有些事是你能解决的，有些事你解决不了，如果抓牌抓到一手烂牌，要么认输换个环境再重新抓牌，要么就该考虑如何将这手牌输得最少，这时还纠结着想赢，是自已为难自己，如果一看牌面就注定赢不了，那么能输得最少，就是赢了。一抓到烂牌就想换环境重新抓牌，只会在牌面好的时候才愿意玩的人，其实很难熬出头，因为各个环境都会有自己的问题，一个特别好没有任何问题的环境其实是不存在的，你很可能会不停地换环境，而其实那些能被公司重用的人，大部分是熬出来，而不是空降来的，越是需要被信任的事，越会交给一起扛枪一路打过来的人。
3
一年前，我还在新浪时，写了一篇文章叫做《关于“产品驱动”和“技术驱动”》http://hi.baidu.com/cly84920/blog/item/741a13ced83ad21093457ea5.html。我在雅虎、淘宝和新浪都待过，这些公司都是产品驱动型的公司，我很熟悉，而关于技术驱动，我只听之前的一位同事谈过，他去过美国google参观，了解过那边的文化，我是从他那儿听说的“技术驱动”。
那时的我，特别信奉技术驱动的工程师文化，技术驱动除了公司老板要担相当的风险之外，基本没什么坏处，是一种非常好的IT公司文化，懂得尊重工程师，工程师的忠诚度和满意度一定非常高，人员流失少，而且能技术创新出很多精彩的产品出来。那时我很憧憬技术驱动型的公司，觉得那一定是工程师的天堂。我在新浪的级别还挺高的，领导们很器重我，给了我不少机会，带重要的产品团队、内部培训讲师、校园网络学院讲师等等，还在一年后给我涨了50%的薪水。可是即便如此，我还是离开了新浪，去了国内某家技术驱动型的公司S，因为我对技术驱动型的公司实在是太向往了。想来，对新浪至今仍有愧疚，希望以后能有机会以别的方式来回报新浪。
一年多以后的现在，我在S公司感受了一整年的技术驱动文化，作为一个扮演多重角色的员工（产品
用我自己的感悟来说，进入IT圈就像进入一个江湖，江湖上有很多传说——某某大侠啊，某某帮主啊、某某之父啊，也许从书本上、也许从博客或论坛上，也许从QQ群里，你总会听到各路神仙的大名，从你一进入江湖开始，就会主动或被动地对某些领袖产生膜拜。有些人高高在上，有原始天尊一般高不可及且不容置疑的地位;有些人站在你不太远的前面，为你开路，然后到处传教，受人尊敬;有些人资历尚浅，虽年纪轻轻却极有天赋，以惊人的速度成为新一代领袖;有些人虽不够权威，但观点鲜明，粉丝众多，经常和同级别的人引发论战。每天还在产生着新的英雄，或真才实料，或徒有虚名，但就是这样一个江湖，精彩不断，我们每个IT人都在这江湖中，比小说和网游真实。
江湖上还有门派，当你进入IT圈时，就会为自己找一个方向，也许是桌面软件开发派、也许是web开发派、也许是已经渐渐没落的嵌入式派、也许是势力扩张速度快到另人发指的新门派移动开发派，也许是少林般的C派、也许是武当般的C++派、也许是武林正派java派，也许是邪教势力强大的ruby派（ruby粉丝轻拍），总之你会先选择某一个门派，从这个门派开始进入这个江湖。
进入某个门派之后，作为初级入门弟子，首先你
首先需要为pache安装mod_python模块
sudo apt-get install libapache2-mod-python
安装mod-python，然后Apache的配置文件/etc/aApache2/httpd.conf，添加如下内容：
LoadModule python_module /usr/lib/apache2/modules/mod_python.so
然后对/etc/apache2/sites-available/default这个配置文件进行类似如下的设置：
<VirtualHost *:80>
ServerName www.somesite.com
DocumentRoot /home/adang/workspace/kpw ＃用于处理静态文件，指定静态文件根目录
Alias /admin_media /usr/share/pyshared/django/contrib/admin/media ＃用于处理admin模块的样式
<Directory "/usr/share/pyshared/django/contrib/admin/media"> ＃用于处理admin模块的样式
AllowOverride None
Options None
Order allow,deny
Allow from all
</Directory>
&nb
真累啊，做个项目从product owner、scrum master、架构师、工程师甚至游戏策划，数个角色全占了。
自己做产品经理设计原型，取舍功能，排优先级，自己做项目经理pk自己的产品经理，每个轮次接受做什么。我很清楚product owner和scrum master最好不要是同一个人来担负，因为天生这两个角色就会因为立场不同而难免在很多时候会对立，如果同一个人来担任两个角色，一定要能清楚从逻辑上将自己划分开来，什么时候扮演的是product owner，什么时候扮演的是scrum master。关注敏捷有两三年的时间了，几位大师的书也都看过了，也在新浪内部做过敏捷方面的培训讲师，自认为对敏捷的心得还算是理解得比较到位。但在实际工作中，同时扮演product owner和scrum master的时候，还是会有比较头疼的时候，一方面来自自己和自己PK，另一方面来自于团队成员的不太信任——尽管我非常努力在平衡两者的角色，也自认为做得很好，可是，将两者同时放在一个人身上时，的确容易让人怀疑是否能很好地胜任。
我尝试过将scrum master的角色抽出来，让团队其它成员来担任，我不兼任scrum master。但事实上，对于一个小团队来说，不一定能找到这样的人出来，至少我所在这个团队，工程师们要么经验太浅，要么只愿做执行者，一个技术
