三十岁，在我个人心中是无比重要的一岁，我整个以二开头的年岁都为了这一年。去年的今天我豪情万丈的写下《三十岁》，然后飞了进去……现在我飞出来了，回头一看，这我寄予厚望的一年完全不是我曾想像的那样辉煌和灿烂，甚至从某种角度来看，是最动荡波折惨淡的一年。

三十岁的冬天——热情（2007年11月12日～2008年2月28日）

一年前的今天，在经过3个月的规划与筹备，2个月的开发，海词2008上线了Beta 1.0版本。那时的我毫不怀疑它会走向成功，虽然是冬天，虽然外面雪封冰冻，但是我心中的火焰让我根本感觉不到寒冷，我相信我一定能做出一个绝佳的英语应用，为海词用户提供更好的服务，我相信我能够站在巨人的肩膀上，帮助海词走向更大的成功。我那时感觉三十岁五十万收入的目标简直如翻掌之易，已经提前进入口袋了，甚至我开始幻想着那辆一直沉没在我口水中的保时捷正在浮出水面……

三十岁的春天——绝望（2007年3月1日～2008年5月1日）

海词2008的团队经过3个月的奋斗，把版本号从1.0提升到了1.6，并且准备好了整个部署中极其重要的1.7版本，就在每个人对未来都充满期待之时，在1.7版本3月1日上线的前一天，2月28日，突然的事变，让所有参与该项目的人都被解聘或架空，包括领导我的大股东。具体精彩细节……算了……我忍。真有意思，经历过集体辞职的我居然还能经历集体解聘……我和刘勇想尽各种办法来挽救新海词，做尽了努力，最后，我知道无论是主观还是客观，我都必须选择放弃。

我从天上掉下来了。当我从内心确定放弃后，真是茫然失措。为了新海词我放弃了所有也付出了所有，放弃了超过十万的年薪、写书成了传说、博客也稀稀落落，我甚至没有一丁点股份和期权，顶着巨大的风险和压力，每天只做一件事：海词2008。我和刘勇一年的心血，团队半年的努力，数以万计的用户和他们的数据，瞬间灰飞烟灭，从互联网上消失。以至于后来用户不断因为找不到新海词却找到了我的博客，发信向我询问这个虽有瑕疵却仍不失优秀的产品为什么突然不见了，也没有给予任何说法和数据备份的手段，完全绝口不提。我不知道如何回复他们，我只能说不好意思，海词内部出现问题，正在处理。当然我知道这纯粹是个没有结果的安慰，想想也郁闷，我TMD还不断的为海词安慰用户，唉。

这个打击对我来说真的很大，这是我三十岁的春天？我所有的梦想、期待和激情，哗啦一声碎得我难以承受。我真的很绝望，甚至对自我性格严重怀疑，天天自我否定。我去上海，在弟弟家里昏睡；我去厦门，除了昏睡每天给妹妹和她的同学们做六人份以上正宗川菜，然后妹妹陪我到鼓浪屿散心。一个月后，四月底，我上了厦门返回杭州的火车。

美丽的鼓浪屿确实能让人抛开烦恼，但是它并不能消灭烦恼，离开鼓浪屿我还是得和内心斗争，得面对现实。在这一个月内，我不断的自我鼓励，直到我坐在火车窗边，看着外面朝气蓬勃的春天，农民在春耕，我想如果是天灾呢？如果农民在收成之时遇到天灾，比如年初造成巨大毁灭的雪灾，难道农民们来年就不春耕了吗？擦干眼泪还不是得继续春耕，为了下一个秋天，为了生命而奋斗。直到那一刻我才觉得我真的从海词的沮丧中走了出来，我不再去想海词，不再去想如何挽救过去，无论是创业还是打工，我需要重新开始，而我选择了创业。

回到杭州，我完成了在海词的最后一件事，为每个兄弟和自己争取到了每人四个月的工资补偿。三月到五月一直没参与补偿战斗的兄弟们很开心的拿着补偿屁颠屁颠，能不屁颠吗？他们最先还担心二月份的工资都拿不到，结果不但拿到还多出三个月来，再算上之前我发出的三次任务奖金再除以实际工作时间，兼职月薪基本接近正职月薪，比我还赚。而我完全以创业姿态在做，为了低成本的进行，我压下自己的全职月薪主动顶风作案，希望给了项目，三个月的补偿，也就比我去年一个月多一点，我还一直全职。旁边放着卡，我抽出一支烟，吐出最后一口海词的气，算了吧，88。

三十岁的夏天——挣扎（2008年5月1日～2008年8月7日）

再次昏睡两日后，5月1日，我背着电脑重新走进了两岸咖啡，这基本算是我颓废两个月后第一次开始工作，这次我为Englive奋斗！我从13：00一直设计到凌晨2：00直到两岸咖啡打烊，在钢琴声中忘情的投入都忘了点餐吃饭，时针转了一圈，我只喝了一杯咖啡。有个小插曲，接近23点的时候，正当我如入无人之地中时，背后冒出一个鬼来，拍了拍我的肩膀：“你在做网站？英来网？你的计划是什么？”我想不会是风投吧，这种传说中的故事怎么可能发生在我身上？不管怎么说我开始和他聊，他否定了我的一切，而我越来越觉得他像个风投的业务员。最后他递给我一张名片，我一看：红鼎创投总裁。……我晕……在我重新开始的第一天就遇到传说了，这也太巧了吧……好了，接下来的故事当然就如传说般顺理成章的发展啦！嗯，我用了5分钟，嗯，完美的口才和演出，嗯，完美的人格魅力，投资者拜倒在我飘逸的长发和破烂的牛仔裤下，然后倾囊而出，多么美妙，呵呵。

哪有那么多传说哦！传说只所以叫传说，就因为它是用来传的，并不用来真实发生。他没有给予我任何帮助，正如我说的那样，他全盘否定了我。但我没有被打击，开玩笑，我在互联网沉了八年，这是我设计出来的项目，并已经为它奋斗了一年，而他根本不了解情况，不身临其境，我也不太相信传说，更相信事实，而这个事实随着海词2008的消失只存在于我脑袋里。不过我很感谢他那鬼魅般的一拍，感谢这次偶遇，它在我重拾信心的第一天，强化了我创业的决心，我要把这个事实重新做出来，我要让这个产品重现世间，我坚信它能给用户带去帮助和价值，我坚信我能为用户提供一个好的服务。

怎么做？我从巨人的肩膀上掉下来，没有资金没有成品甚至之前产生以万计的用户及各种数据我都留给了以前的程序员，虽有一闪而过的犹豫，我还是没有在火速安排他备份后的第一时间向他索取，我把信任给了他，那是团队的成绩，不属于某个人我也不会去抢。我天真的以为解散的团队能重新组织起来，因为一起相处磨合奋斗了半年，而且我告诉他们，只要我们坚持把产品做下去，等名利风波平息后，也许我们带着更加成熟和完善的产品还能继续回到海词。但是我错了，只有我的信心是建立在自己和产品本身上，对我而言，海词只是能帮助这个产品更快的成长。而他们的信心完全依附于海词这个品牌，依附于海词数百万用户，一离开海词，桥一拆面对河就崩了退了，全面否定和怀疑之前的所有努力和成绩，然后打着自己心里的小算盘。居然某人对我说出绝对可以射精的话：“你投十万，我还是兼职，工资要保持在海词的水平，我要有足够的股份，并且不能完全按你说的做，否则浪费我的时间，我也有风险，要按我说的做才行。”我无比崇拜地把他望着，右手想拿起桌上的咖啡给他敬过去，TMD我还帮你这个没签合同的人争到四个月的补偿，你给我冒出这么经典极品能流芳百世的话来。我才发现之前的和谐全是假的，当团队面对灾难，小算盘的表演噼里啪啦是多么精彩，而我很认真的欣赏，补上了这课：没有经过灾难考验的团队不算真正的团队。这是我重拾信心后的第一次重大打击，原团队组织不起来就意味着，起点不能建立在成型并成熟的产品和万计的用户基础上，随之消失的还有半年的团队磨合，大家应该知道对于创业，失去这样的起点是什么损失和打击。无论我想得通想不通，我都变成一无所有，只剩下脑袋和脑袋里的记忆。是的，只是记忆，当我因为融资所需向程序员索取运营数据截图，截图哦！程序员告诉我重装了系统，硬盘不小心格式化了……有没有人不知道这是什么意思……

什么都没有了，我也想过妈的一个人做，我有两年编程经验，再臭也能对付一下。但是这个念头只闪了一下我就灭了它，我要坚定不移的走团队合作之路，我绝对不做个人网站，经过这几年的Web标准大团队协同经历，团队和合作这两个词深深的被植入我心中，而个人英雄主义基本上就从我脑袋里消失了。一个人无法专注，无法把自己最擅长的贡献给产品，面面俱到的后果肯定是平庸，我的时间要用在让我的长处更长而不是让我的短处加长，我必须选择合作。团队这个话题展开就多了，dudu在协助我购置服务器时对我感慨，博客园也是在四年后的今年才走上团队建设的道路，而我一开始就选择了这条无比艰难的道路。我得感谢新团队的成员，在我拿不出数据的情况下，选择了对我记忆的信任，对我个人的信任，甚至在我始终对拿不回过去数据，无法有个好起点上而耿耿于怀之时，鼓励我，帮我坚定了放弃过去，从头开始，从零开始的决心。并在面对每个团队初期无可避免涉及复杂的股份期权回报的时候，仅来回两份邮件讨论就说出了让我无比感动的话：“就像你说的那样，大家因为相互信任彼此的人品才走到一起，股份期权的问题，你看着办，我信任你，咱们开工吧！”

于是，我按下了清零复位键。于是，每一个字符，每一行代码，每一个字段，每一块数据都是崭新的，我所有的设计思路，全部铺在桌面上，一起一条一条的清理、拭擦、审视、规划。然后，动手了，开始还原我的记忆，干干净净的从白纸开始，不让任何人有任何机会对我，对团队，对团队的心血产品说三道四，我行得正邪不怕！2008年8月7日，Englive.cn 新生了，诞生在金黄的立秋之时。

三十岁的秋天——希望（2008年8月7日～今天）

一个生命，最危险的时刻便是毫无抵抗力和免疫力的初生阶段，随时都可能两眼一翻，两腿一蹬，透明的腾空而起。Englive同样如此，没有任何特殊和例外，甚至更加的危险和让人揪心。团队配合不默契、心态不稳，前景不妙，有人淡出、有人离开、有人进来，每一个变化都可能导致Englive眼腿翻蹬，都是初期不能承受的，但不能承受也得去顶啊。每一个版本都是一次战斗，一段故事，我曾很想每上一个版本写一篇博，实在做不到。一步走在生，下一步就落在死；一步走在希望，下一步就落在绝望，巨大的风险和压力铺天盖地的笼罩我，一片黑暗，我做得最多的一件事不是技术，而是不放过任何蛛丝马迹的机会来强化自己的信心，守护住自己心中的希望之火不被蜂拥而来的黑暗所扑灭，从而使自己靠着这微弱的火光，更多的持续在高潮而更少的进入更快的走出低潮。我感谢我前半年在海词的半创业经历（心态和投入上是，形式上不是），它锻炼了我的风险和压力的承受与化解能力，我想，如果没有这段经历，也许在这三个月内的某一天，我已经崩溃了。这和我在爆米花潇洒的拿着全技术团队最高工资埋头只写html，完全不同；这也和我在海词用对等的时间和精力亡命投入，完全不同。我深刻的体会着“创业”二字，然后对每一个勇于全身心投入创业的人肃然起敬，无论他是成功者还是失败者，无论他是刚刚开始还是已然沧桑。

就这样，在我上午确定html结构、一个像数一个像数的调试css、还拿着钢笔在FW中设计图标画线条，一个消息传来，下午就奔上去上海见投资谈合作的和谐号，晚上随23元的蜗牛火车爬回杭州继续和团队协同沟通。就这样，周末没了休息也没了，当一个版本结束，大家睡去，我不能，我需要想：下面该做什么？怎么做？下个周期到哪里？如何承前启后？如何使产品开发节奏和市场接受节奏尽量同步……铺开一个大圈子最后做出一个小决定，还需要尽量提前把原型设计出来以便更快的讲解设计思路，于是大家醒来，又有了新的方向和目标，然后各就其位包括我，协同又开始了。就这样，在我几乎每天除了吃饭睡觉，10～15小时昏天黑地飞砂走石的专注投入下……不对，也许吃饭也应该算上，脑袋没停眼睛没闭呀，也许睡觉也要算上，人家是要做梦的啊，梦中的工作时间不算吗！算吗？不算吗！！……靠！24小时投入诶……

三个月，Englive开始慢慢成长。从立秋的alpha 1走到立冬的alpha 9，秋天结束了，冬天开始了，我们用了整一个秋天的时间，终于赶在冬天开始前为她披上了一件衣服。而她给予的回报，是增长的用户数据和好评甚至坏评，那都是希望！终于，我的希望开始不仅仅只是从自己内心获得，团队的希望也开始不仅仅只是从我口中记忆中获得了。虽然这种外界给予的希望之火还很微弱，虽然我们仍然得靠挖掘自己内心的希望来保持前进的动力和激情，但是终归我们坚持着的走过了一个阶段，那是最容易眼腿翻蹬的阶段。

Alpha 9上线了，我们完成了Alpha阶段全部功能，我松了一口气合上电脑，决定去西湖边散心，在公交车上站了五分钟，晃荡加上气闷，我一阵反胃想呕吐，然后晕倒在车上，五秒中后爬起来冲下车，大口呼吸新鲜空气，然后使劲笑，人生第一次晕倒，感觉帅呆了。

还不能休息，几天后beta版就要上线了，这很重要。Alpha的用户界面无论首页还是内页的风格，我可预见的已经成了未来的瓶颈。随着未来beta版功能的不断增加与积累，用户界面和用户体验会失去轻盈而显得沉重与堆砌，谁说只有代码需要重构，界面一样，设计一样需要重构，以适应未来的发展。我早早的就在脑袋中一遍又一遍的设计着beta版的用户界面，我翻看着内页不断构思着首页，某一天，一个灵感触动，我瞬间完成了首页的转变，我超级惊喜，本来我们的首页就很有特点，现在感觉更加大气，甚至我觉得产生了质变。本来首页定下后，内页风格是自然而然的事情。但是首页信息量不大，容易出彩，而内页则需要考虑太多。每一个图片，每一个图标，每一个色彩，每一条线条，每一个文字……最难处理的就是视觉导向和轻重平衡。Alpha版本用户界面就比较平衡，也因此得到了用户很强的认可和赞美，这让我高兴也让我为难，平衡一旦建立，一旦得到认可要更改就很困难了。设计有蝴蝶效应的，有时哪怕一个px的变动，也会使得整体失衡。我不断的尝试和微调，却总是无法在得到扩展力的同时重新获取视觉平衡，总是无法在兼顾UI的同时照顾好UE，总是无法在兼顾内页的同时保持住首页，整体设计啊……我在四个界面（老首页、老内页、新首页、新内页），还有不同的功能页上不断切换，发呆，努力的发呆，一直到今天中午，beta上线前1个小时，我终于感觉找到了平衡，一阵狂喜，我觉得又完成了一次自我超越。我提交到服务器，兄弟告诉我：“新内页不错，而且和新首页很搭配。”我啊，在踩了大量的设计尸体后，终于圆满了。但是在用户对老界面的好评下，我仍然对新内页没有100%的信心，不敢马上全部替换，我还需要沉淀，我还需要时间来审视和对比新旧风格与体验，并继续完善。（你可以通过IE访问和FF访问来对比不同的内页设计，但是首页，我已经100%确定了，你看不见老的。想对比的抓紧，我的信心是越来越强了，会全面替换的。）

2008年11月12日，下午3点，Englive.cn Beta 1.0 终于上线了。我无比感慨，一年的轮回，从2007年11月12日的海词2008 beta 1.0到2008年11月12日的Englive beta 1.0，整整一年。这一年我做的事情从表面上一言蔽之就是把4个字母的Dict换成7个字母的Englive，但我已不是一年前的我，团队也不是一年前的团队，产品更不是一年前的产品，人在成长自然投射在产品上。无论前端、后端、界面、体验、速度、性能、功能、扩展力、甚至各项运营数据……Englive.cn Beta 1.0 远远把曾经的海词 2008 Beta 1.0甩在身后，更是和现在海词的词典方向彻底分道扬镳，Englive随便你从哪个方向看她都不是Dict！哦，还有，我们还有完美的iPhone版本！我们有多少用户？我不方便说，我只能这么告诉你，我已经不再耿耿于怀曾经的数据，那已经不算什么啰，我现在关心的是我们的服务器是否能接纳更多的用户，为更多的用户提供服务。

明天？我看不见不知道。对手？我看不见不知道。我只知道我的今天没有重复昨天，我只知道我最好的设计永远是下一个。而我关注的对手是：昨天的爆牙齿。乐此不彼！

等待春天

写下这个小标题，让我又想起了今年的春天，我写了很长的同名文章来记录当时所有五颜六色的感受，当我写完的时候，春天已过，我没有发表，我想，我那时所等待的春天肯定不是今年的春天。

Alpha走完了，站在Beta面前，这不是终点，这只是另一个起点，等待去被超越，而我依旧已准备好继续上路。

已经入冬，这将是异常寒冷和漫长的冬天。老早老早领袖们就争先恐后的抛出了过冬论，裁员的裁员，积粮的积粮，投资者在寒风凛冽中紧紧的捂着自己的口袋。我那在汇丰的牛逼弟弟在签名中写到：“没有被炒鱿鱼，值得庆祝”，我回头看看才三个月的婴儿，多么渺小多么脆弱，如何能抵抗中国经济三十年来的第一次雪冻冰封？死亡将随时会在明天来临。但是你忘了吗？我是谁？我是不管明天只管今天的爆牙齿。我明白的告诉你我已经基本预定了明天的死亡，这不是九死一生的决心。我不知道未来会有多少的障碍和困难，也许会比今年所遇更大更猛，我也不知道未来会有多少人坚持不住而离开，但是我把话放出来，哪怕我一个人也一定会坚持到最后一个子，然后再想办法，继续坚持！那么多用户，给了我们希望，我们不能用失望回报他们。有了用户，我们就必须对每一个用户和他们的数据还有期待负责，所以我们不能倒，我不会倒！我不是海词的那个人，想删就删，还有百万，万算什么？甚至3月31日为了证明海词是他的个人网站，发出邮件，然后连百万用户都无视，随手关闭海词长达十天，光这两个行为就让我毫不犹豫的直接放弃了他。

我是撞了南墙也不会回头，头撞掉了，老子还有脖子继续撞，直到脚丫。

我是一只小小鸟，抱着九十九死一生的决心扑进火里，死了，那是该！但是，只要我让抓住那一线，那一闪而过的一线生机，你们将看见凤凰从火里飞出！

我的三十岁终于结束了，五十万年薪我依旧不知道在哪里，那辆保时捷依旧还在我口水中泡着，老天依旧没有扔一个天使下来，但是我觉得我拼尽全力终于还是没有辜负我的三十岁，我还是对得起它，没有遗憾。

好了，不管那么多了，新的一岁开始了，继续愤斗！

和去年一样：生日照。

我太阳，发了！还是那句话：浪费了我写的时间，就一定要用折磨你眼睛的方式补回来！
　　现在，我-宣-布：年总结开始。

我不担心其他任何问题，我都认真考虑过，我只是很平常的记录自己的经历和感受，总结我这不平常的一年。但是正因为它真的很不平常，至少对我而言，我担心会让我无法安静的工作。也许这篇文章发在博客园首页能间接的为Englive带来一些用户，也许，我是说也许，因为对“用户”这个词我有不同的理解。就拿传统意义上的所谓软文推广而言，对我太容易了，我只要用Englive作为实例讲解Web标准就行了，并没有什么技术秘密，但是我一直没做这事。这是后话了，如果未来我做这件事，很大程度也不会是为了软推Englive。

我只是担心，我就是担心这篇文章会让我难以继续保持在一个安静的角落，思考、工作与愤斗。我原以为我是不会被外界影响的，但我发现现在却担心了，担心自己做不到气定神闲……都怪该死的Englive，上升势头太猛了，有些是意料之中的，有许却意料之外……最大的意外是：我还有好多好多的计划都还没做呢！你着什么急啊，就想飞了！

打坐。“气定神闲，气定神闲，气定神闲，气定神闲，气定神闲，气定神闲，气定神闲”

发了后，果然影响来了，果然导致我这一天都无法安心工作，老是刷评论。现在我要做一件事：关掉博客园，干TMD活去！

当然我不是要在这里自我标榜，标题说了，重点是平面设计。

做设计这么多年，我从来不敢说自己是平面设计师，因为我对设计两字充满敬畏，尤其是艺术设计。网页设计中的艺术设计含量没有平面设计高，也没有平面设计严谨，更不是设计的最黄金点。所以我这个完全没有美术基础和理论知识的人才能仅依靠投入超量时间堆积起来的经验和感觉在网页设计中呆那么长时间。

我拍着胸脯骄傲的对你说我是龙逼的网页设计师，然后怯生生的说这个平面设计也许我可以客串一下下。这就是我对待网页和平面的态度。

我的平面设计经历和经验都很浅。第一次平面设计是2001年初，内容是一个标志一个横幅一个海报，那时我还不会使用CorelDraw绘图（现在都不会），标志是用Flash 3做的，然后转成矢量导入CorelDraw中，横幅是用FW4做的，同样转成矢量导入CorelDraw，连海报也是用FW做的，因为不会用PS……我还记得当时很郁闷因为FW无法处理高精度，我连px和cm都没搞懂，更不要说dpi了。反正稀里糊涂做了，而且稀里糊涂的中标印刷了，然后稀里糊涂的把一个已经4个月没发工资的公司救活了，我没看见印刷产品，因为我设计完后和老总大吵一架，然后背起包包抱起电脑，分文不取就走了（我把自己电脑搬到公司里的），中标的事情是一个月后我在深圳时，朋友告诉我的。设计稿还在，只是懒得找，作罢。

2001年在深圳一家专业的平面设计公司做网页，周围都是MAC，我一个人PC。我呆过的唯一一家平面公司，纯粹感受了一下平面设计的氛围，另外就是学会并熟练了PS的钢笔，终于扔了魔棒，能精确的抠图了（其实至今PS对我而言就是抠图工具，哈哈哈，唯一的PS技能），还有一个就是耳熏目染的对排版设计有了初步认知，学会了用line-height来控制行距（之前都是用td……我找到的我最早的css文件是2000年6月，里面有三行：.front9pt {font-size: 9pt}.noneline {text-decoration: none}.frontwhite {color: #FFFFFF}，看见没连font都写成front，一直不知道，直到一天，深圳平安网里的美女设计师问我你的字体呢？我指着“front”说这儿，她望了我一眼一句话都没说也没纠正我，但我马上反应过来，超囧，所以印象非常深刻）。

2002年底公司做用户帮助手册，我自告奋勇接下来便有了第二次平面设计经验。在同事“CorelDraw都不会还敢接手册设计”的鄙视和帮助下，学会了用CorelDraw排版，知道了文字需要打散，打散后会乱七八糟，还有一些比如“出血”的专业术语。第一次看见了自己设计的印刷成品，而且是无需创意的纯排版设计。设计稿肯定找不到了，可惜。

2004年初公司承办展会，需要找公司做平面设计，负责网页的我自告奋勇，能节约成本，老总当然happy答应，于是我又有了第三次平面设计经验。内容更丰富了，是门票背面、手提袋、工作牌、宣传画册。设计稿如下，时间是2005年2月：

门票背面


手提袋


画册-封面封底


画册-内页

画册的灰色部分是镀银处理。封面封底最终没有选用，老总无法接受，换成了我认为中庸的设计。当然我自己的也有点假大空呵呵，其他都全部做了印刷，比两年前简单的用户帮助手册，有了更多的设计，也看到了更多的成品。我发现电脑效果最差的手提袋却是成品效果最好的，超喜欢。然后我知道了平面设计上效果图的视觉和成品的视觉有时有巨大差别。所以要玩好平面设计，必须吃透印刷，因为你的作品不能是图片，要是实物成品。然后我理解了为什么很多平面设计公司的宣传都是实物照片而不是效果图。我特意保留了这些实物作品，可惜后来也慢慢丢失了。

同理，家装设计含金量在施工而不是3DMAX效果图，网页设计同样如此，价值在成型可操作的网页上，而不是一张PS图片。总而言之，效果图只是指引，价值在成品上。说到这里又想起张艺谋的经典：凤还巢的创意和效果图都很漂亮，所以它也就只是一张美丽的效果图。这也是为什么平面设计师不能做网页设计师的根本点，他只能做效果图而不能保证成品。网页设计的成品需要太多艺术设计外的知识。而这部分充满逻辑和理性的代码知识对纯感性的平面设计师来说是巨大的障碍。同样网页设计师也成不了平面设计师，不仅仅是艺术设计的不专业，还因为缺乏印刷知识而不能有预见性的进行设计。设计虽然通行，但是成品的方式却截然不同，所以不同设计职业，其实很难互换。

2005年来杭州前我又做了一次平面设计，不过是这次纯粹属于自我YY，并没有实现印刷：

2006年卡当要设计名片，我又冲了上去了，还没设计过名片呢！可惜卡当有专职的平面设计师，我不好只为了爱好去抢别人的饭碗，我想体验一把名片设计的愿望落空了。不过卡当的个性产品让我爽了一把鼠标垫的设计，上次的画册的封面十字老总没让印刷出来，一直耿耿于怀，因为要知道当时我把这个人抠出来并很细心的修正，再转成矢量图花了很大功夫（后面一个就没耐心修正了，所以它是模糊的没有清晰的骨架），于是这次我把它在鼠标上印出来了，哈哈。

2007年底并不需要名片的海词在我的鼓吹和先斩后奏（先把名片悄悄设计了）的策略下，我终于体验了一把名片设计，有了处女作，感觉不错，虽然实际效果没我想像的好。然后我看着实际的名片，对名片设计的认知有了提高，我想我知道下次我该做一个怎样的名片设计了，一定更好。可惜海词2008随着我的离开灰飞烟灭，成了历史作古，空留下几百张孤独的名片目睹见证Englive.cn的新生。

2008年……哎呀，今年是个真空，一个平面设计都没做过。不过我想，加油，也许明年我能把大大小小，平面设计的瘾过够，过足！标志、横幅、海报、手册、画册、门票、手提袋、名片，都做过一次了，都有处女作，那么当我第二次做的时候肯定会很无敌，哈哈哈哈！

如果你有正职工作的概念，那么所有的这一切都是正职工作外的工作，也许会说：有毛病，不是任务又没有钱。我会说：老子喜欢！我没有正职工作，我只有爱好。设计带给我的快乐岂是单纯的金钱能带来的？我现在都还在设计，不亦乐乎！有时我在想，我为什么不能放下呢，去做所谓更高级的工作，是我不信任他人吗？有这个因素，因为处理大量细节是个苦力活，需要很强的耐心，细心和对苦力活价值的认可。前段时间我想到一个问题，我花一个小时设计一个图标和花一个小时谈下一次合作，其实从某种角度上，是等值的（此话题太跑题，不展开了）。我想说的是不能放下更重要的是我喜欢设计，很享受它给我带来的快乐和成就，还有成长，以后有空我再把我8年来做的网页设计一字排开，我基本都保留了每一次网页设计。

好了，这就是，我和平面设计。

这个团队角色理论叫做贝尔宾团队角色理论。基本思想是：“没有完美的个人，只有完美的团队。人无完人，但团队却可以是完美的团队，只要适当的拥有如下各种角色。”

最初很随意，慢慢很认真的修正了几遍答案，我的做题思路是，很明确的有，就填1，然后用排除法来权衡比较的增减。不代表有无，只代表轻重。

我的答案如下：

最后我的SH和FI最高都是15分，其次是PL11分，再次是ME9分，最弱的是TW2分，呵呵。

15分的推进者 SH（Shaper）：
优势与贡献：
为团队带来动力，勇于挑战，直面压力。
为团队克服前进障碍提供动力和勇气。
塑造者是任务导向型的领导者，他富有无穷的精神力量，具有高度的成就动机，对他而言，任务的别称就是成功。 在追求成功的过程中，他不断塑造和影响其他团队成员，以期共同实现团队目标。

典型特征：思维敏捷；坦荡；主动探索
积极特性：积极，主动，有干劲，随时准备向传统、低效率、自满自足挑战，有紧迫感，视成功为目标，追求高效率。
能容忍的弱点：好激起争端，爱冲动，易急躁，容易给别人压力；说话太直接，虽然SH总是就事论事，却经常伤人不伤己。
在团队中的作用：
1、寻找和发现团队讨论中可能的方案。SH一旦找到自己认为好的方案或模式，SH会希望团队都follow这一方案或模式，因此SH会强力的向团队成员推销自己认为好的方案或模式。
2、使团队内的任务和目标成形
3、推动团队达成一致意见，并朝向决策行动。经常自觉不自觉的，SH在团队中扮演一个二领导的角色，即SH可能不是名义上的领导（CO一般是领导），但SH却给人二老板的感觉。

总结：有活力、外向、易激动、爱挑战、爱施压、困难面前寻找各种办法。可接受的弱点：容易发脾气。

15分的完美主义者 FI（Completer Finisher）：
优势与贡献：
为团队带来严谨，勤勤恳恳，满怀热望。
发现团队在执行任务过程中的错误和遗漏。 准时完成任务。
完成者注重工作细节，并确保工作任务按计划时序进行，一役毕其功。 他们往往表现出扎实肯干、一以贯之的角色特征。

典型特征: 勤奋有序；认真；有紧迫感
积极特性: 理想主义者；追求完美；持之以恒
能容忍的弱点: 常常拘泥于细节；焦虑感（注意和SH的不同，SH有紧迫感，但FI是焦虑感）；不洒脱
在团队中的作用：
1、强调任务的目标要求和活动日程表
2、在方案中寻找并指出错误、遗漏和被忽视的内容
3、刺激其他人参加活动，并促使团队成员产生时间紧迫的感觉

总结：吃苦耐劳、尽职尽责、严肃、善于发现错误、守时。可接受的弱点：有时过度忧虑、不愿授权他人。

11分的智多星 PL（Plant）：
优势与贡献：
为团队带来创新，敢想敢干，不拘成规。 解决难题。
典型特征: 有个性；思想深刻；不拘一格
积极特性: 才华横溢；富有想象力；智慧；知识面广
能容忍的弱点: 高高在上；不重细节；不拘礼仪
在团队中的作用：
1、提供建议；
2、提出批评并有助于引出相反意见。

总结：有创造力、有想象力、善于打破常规、解决困难问题。可接受的弱点：不善与普通人交往

只有2分的协力工作者 TW（Team Worker）
典型特征: 擅长人际交往；温和；敏感，是人际关系的敏感者（注意RI是外界信息的敏感者）
积极特性: 有适应周围环境以及人的能力；能促进团队的合作；倾听能力最强。
能容忍的弱点: 在危急时刻往往优柔寡断，一般很中庸。
在团队中的作用：
1、给予他人支持，并帮助别人
2、打破讨论中的沉默
3、采取行动扭转或克服团队中的分歧

总结：爱社交、温和、善解人意、乐于助人、倾听、营造力、避免不合。可接受的弱点：在棘手环境下优柔寡断。

这个答案不知道是否吻合大家眼中心中爆牙的形象，呵呵。http://www.chedong.com/blog/archives/001398.html，下载那个Excel即可，千万不要去那个一苇网测试网站，我去网站做题，题做完了，告诉我填入邮箱发送pdf答案，我填了，提交，又一表单，向我索取一大堆个人资料，我操，不填了。回头邮件到了，打开一看，没有pdf答案是注册成功通知，我再太阳他，这样骗取注册用户，有什么意义？MMD！

好了，娱乐了自己，也娱乐了大家，继续干活。

这段时间超级繁忙，文章断了一个多月了，不好意思。

当程序员完全放弃对结构的编写与确定，高呼万岁，解脱了。真的，我发现我经过的程序员没有一个不是超爱Web标准，能不爱吗？我告诉他们再也不用写html，不用写css，不用写js，最多最烦人最招惹领导的界面问题都与你们无关。（我说句悄悄话：不要看现在每个公司后端“程序员”一堆一堆，我敢说对于其中不少人，像我这样把html/css/js部分从他们手中一抽走，基本就废了他们，他们剩下没多少可做的工作了。唉，别说他们，后来我把自个儿也废了，因为我速度太快了，后面慢聊……）

我是要说什么来着？哦，我要说得是程序员万岁了，但压力并不会凭空的消失，而是转移了，本来由大量程序员分担的工作便集中压到往往人单力薄的前端，前端的一系列问题就出来了，那就是设计、结构、样式、行为之间以及其自身的分离。这个分离相当困难，因为这几个东西太缠绵了，千丝万缕的纠缠。实际上，至今我仍在努力梳理，所以我只能在我的能力范围、认知范围和实践范围内说说看。

我曾在卡当顶着大量工作成为前端瓶颈，我后来一直在反思：为什么？怎么会这样？web标准错了吗？我开始抛开无法回避的客观因素，从主观上自身上去找答案。web标准，我还是信任的。

我当时的工作有哪些？管理和前后协调上的工作就不说了，说说前端技术上。首先我要做设计，因为那时能设计的人都不懂Web标准甚至不懂table，我自然否定他们的设计，因为传统的表格拼图设计思路会给制作带来麻烦，尤其是当时崭新的结构化思路非常需要设计的支持；其次我要做结构，这没啥说的，在结构上的理解与运用没人比我强；最后我还得做样式，由于我从那时开始就追求自创的独立于根的写法，而且狂热的恋上这种我认为最精简最漂亮能最大限度摆脱布局思路的结构，而这需要无比的耐心和深厚的css功底作为支撑，否则难以去除冗余结构也难以还原设计稿……

这样，为了避开层层的障碍做得更好，自己理想中的完美，我不自觉的把所有工作都集到了我一个人身上，使其他人很难介入进来，只能走在边缘。随着产品越来越复杂，恶性循环下我就陷得越来越深，不但我得陷在开发中，还得陷在维护中，出了什么bug，不管何时我必须在场，否则无法解决，我手机为QA开着，随时响应他们的召唤。在后来的反思中，我认为陷进去的原因之一就是：通用。

可能这一说，是会被开发砍脑袋的。因为“编写一次，畅通无阻”，是开发至上追求，大家都讨厌重复劳动，讨厌苦力活，觉得这些都没有价值，不值得做，通用了，就能节省自己的时间，他人的时间。程序编写我不熟悉，我这里单说前端，更具体的是特指css。

css的诞生就是为了统一控制，最初我们就知道使用css来统一全站字体、字体色彩、行距等表现性的东西。多方便啊，维护的时候改一个地方，全站都变了。使用css后给人的第一个感觉就是通用。后来web标准来了，css的控制能力和范围在前端得到了几近无限的放大。我们发现通过css不仅仅可以控制颜色，还能控制布局。那么能使颜色通用，思路自然而然的无缝转嫁：统一控制布局。这是在我脑子里曾长久主导的设计思路和设计方向。我追求着通用，在卡当做到了当时个人能力下的极致甚至写过类似如此变态的css：
xxx div{float:left;}——一个css中。
xxx div div{float:none}——另一个css中。
xxx div div div{float:right;}。——再一个css中。
可能光看这部分代码你会觉得很狗屁，呵呵。也许你会说：“不是通用的错，是你做得不好。”完全是这样的吗？

2006年9月，正好两年前，在我围着通用上扑下扑，鸡飞狗跳的折腾过程中，CTO郑文军和我有一次交流，在多次的常规交流中唯这次让我记忆犹新。当时我炫耀着目前的前端多么多么的畅通，要变什么改一个小地方全变，要个性化什么通过css的优先级处理覆盖掉通用定义就行了，当然实际上我是焦头烂额的，忽悠领导呗是吧……文军看了看说：“嗯，不错嘛。”我正为忽悠成功而暗自开心。他话锋一转：“但是我觉得你不应该做得这么通用，有些地方即便能通用你也不应该让它通用，你要允许冗余的存在，允许看起来很讨厌的东西残留在系统中。”这可把我反忽悠了，可以说我把通用处理得不够好，但是能够通用为什么不通用，冗余的存在意味着无意义的重复劳动，无谓的多余时间消耗。我能节省我的时间，为什么不呢？是吧，Why not! 一抹袖子，办公室里，One、Two、Three, Fight!……

最后他说：“我们先把技术搁下好不好，不谈技术。换个角度来看，现在要做一件事情，比如我们一个新版本要上，包含很多内容很多模块很多面要处理，上线时间是3天后，铁板钉钉是不允许变的，钱不是问题，但时间晚一秒都不行。而我们现在的人力是肯定做不到的，就比如你前端，你要多少人我都给你，但是3天后必须完成，你可以吗？你做得越通用，对新人而言学习成本越高，无法迅速的开始。……”

我当时立刻就有一种醍湖灌顶的感觉，我解决问题处理问题的思路确实局限在了技术这个范围，没有跳出来，不够宏观。所谓的节省精力和时间局限在了一个小范围，甚至只是自己，而实际上我心知肚明的清楚，我自己也并没有省心反而更加烦心。

也许程序上的通用是有很大价值的，因为功能的需求变动和扩展通常不会很大和频繁，但是在过于直观的界面设计上，变动是频繁的。很简单嘛，boss通常看不到也看不懂程序，但是界面谁不会看呢？也能很方便的发表意见，甚至路过你身边冒一句：“把这个挪到这边，把那个挪到这里，这个图片不要了，那个角弯一下。”冒完泡后，大摇大摆的带着指点江山的成就感离开，也不会觉得有什么麻烦。只剩下你对着屏幕的反光，大眼瞪小眼，还得提防他啥时候再次路过，然后把之前说的话反着说一次。

这样的变动，对于界面设计来说虽然烦，但是这种烦不是因为实施，在PS/FW里拖来拖去的实施并不麻烦，抵触主要源于心烦（老子觉得这样好看，老子专业，凭什么改？）但是对于之后的css设计，实施就是灾难了。css不是银弹，特别是在处理布局上。我们设想也实施过各种各样的css文件：处理字体的，处理颜色的，处理模块的，处理布局的……这样的细分就是在分离，目的是通用。程序之所以相对而言能够去通用，我觉得因为功能之间能够通过定接口基本做到分开。一个优秀的程序员和一个差劲的程序员，无论谁上谁下，只通过接口握手，不会因为不同的编码习惯、风格、优雅度而相互影响。但是css不行，它没有接口，不管你细分了多少模块，最终css面对的是一份混在一起的，整合的html。这种情况下，如果由不同的人来完成不同模块，再组合起来，css间就会冲突，因为布局总是相关的，有时这种冲突会非常激烈。当然我们可以通过优先级去解决，这就是覆盖操作，分离程度越高，覆盖操作越多，而分离层次越多，当你面对一个新页面的时候，你越迷惑：到底以前在这个标签上定义了哪些样式我需要去清除或覆盖。我曾经在这上面陷得很深，我自己都记不得我需要处理哪些我曾定义过的东西，翻箱倒柜的寻找……

问题还不仅仅出在开发过程中，维护时也是。分离后，通用后，引一发而动全身是其优势，同时也是其劣势！随着项目的壮大，页面越来越多，而人员变更，使得后续的css设计五花八门，这个时候，分离出来的通用样式就越来越难以更改，因为你不知道引这一发，全身会怎样的抖动，也许左手很正常，而右手在抽羊癫疯。也许全身很正常，但某一处血管已经断了（因为样式问题而导致功能失效不是低概率），于是你不敢轻举妄动，恶性循环后，通用的这些css慢慢就成为沉重的历史包袱压着后续开发。如何查找？就像在超长代码中去寻找一个未关闭的标签或忘写的“;”一样困难，而且你还得首先确诊问题的根本是有个未关闭的标签或“;”。曾经我们上线一个版本后出现严重bug，前后所有相关人力在追查了整整两天后才发现，是程序员套结构时一个未关闭的标签导致。虽然只是一个小问题，习惯问题，却引发了高度重视，甚至大家产生对web标准的怀疑，因为风险太大。（唉，你们不知道我当时的苦啊，有一次我发现程序员居然一个页面少关闭了近10个标签……这还是我写他套……）

我要说的是，从那次交流后，我就开始很慎重的对待样式的通用和分离。尽可能少的分离，尽可能少的通用定义，除了兼容尽可能少的进行覆盖，尽可能的回避!important，目的是为了使自己，使他人在面对新页面时不要背着难以卸掉的、沉重的历史包袱。我们知道对待一个页面写样式最快最爽的办法就是面对一个完全无样式的页面，不仅如此，干净的页面对界面设计的宽容度也是最大的。前端是什么，UI和UE，是用户界面和用户体验，界面源于设计，体验源于交互。css不是主角，它是配角，在设计和交互间是穿针引线的作用，css需要做的是尽可能的不限制。而css的高通用、高分离，我认为就是喧宾夺主，对设计和交互构成了限制。

从2007年开始，我写CSS就基本上为一个public.css+"page".css，页面链接"page".css，而"page".css中对public进行import，并且尽可能少的定义public，把控制权尽可能多的交给"page".css。"page".css得到了更多的控制权就意味着"page"的界面设计得到了来自css更少的限制。目的就是让css之间的牵连更少，而操作更自由。自由当然需要代价，那就是各个page的css会存在冗余，会在开发时产生重复劳动，但我觉得对于css来说，最重要的还是自由。少了分离少了通用，无论人员变更还是水平高低，都能迅速的参与到项目中来，而不是先啃一套css规范，如果公司一换，屁用没有，又得重新啃新的规范。我float用得比你的position还好，我为啥要遵循你的position规范呢？我想很多人都不会乐意去修改别人的css，因为很难理清别人的思路，padding-top只是padding-top吗？它很可能是页面的布局重点。我相信每个人在接手他人工作的时候最乐意的就是按自己的方式来，哪怕全新开始也会很快。那么好，你现在把他的"page".css内容删了重写，页面干干净净，自己搞吧，如果赶时间，极端点，你甚至不用了解和导入public.css。而你写的"page".css并不会被其他页面引用，写得再烂，也不会破坏整体。或许会有人拿面目全非的改版说事，别异想天开只动css，通常来说，面目全非的改版改的是需求，需求一大变，css？直接del吧。不要一说起css的灵活就把轻松改版挂在口中，你做到过吗？css的灵活是体现在开发、维护的过程中各个细微之处，在大量的细节问题处理上节约时间并推进进度，而不是面对整体。如果非要把css拔升到全局控制的高度，会是灾难。再重申一次：css不是银弹。

最后一个必须提的，是组件化。如果说我的左手是反对，右手是支持，从2004年开始，面对组件化操作css的做法，我左手就没放下来过，很简单：组件化操作css是更高的通用和更高的分离。前段时间我们在讨论片段化的时候我也是反对将css纳入其中，哪怕最终能自动合并而不必担心文件数的问题。因为，需要给予千变万化、动荡不安的前端更多的宽容和自由。还有一个原因，我会在下篇中讲到。

分离的第二步：减少分离，降低通用，解放css。

连接
◆《重构之美》总目录
上一篇：重构之美－跨越Web标准，触碰语义网[分离：程序员请“远离”Web标准] (8-20 00:06)

于是从昨天开始，没有测试工具，我横下一条心，用最古老最繁琐的方式，苦力测试五小时，WIFI和EDGE轮番上阵，各种情况各种条件各种组合，一个不拉的记录，然后分析。根据测试结果，晚上兄弟倾力配合进行修改，然后我一遍一遍的再测，终于14秒，12秒，10秒，8秒，6秒，最后锁定到5秒通过全功能，而凌晨两点，看着全功能的页面和测试数字，我不管大家已经都入眠了，发出短信：“打扰了，通告：XXXXX，WIFI和EDGE，通通秒杀！”是的，1秒！！！依旧全功能，依旧低流量，14秒优化成1秒，并且不管兔子般的WIFI还是乌龟般的EDGE都一样猎豹。真正的秒杀！太帅了。Englive iPhone Web App 几近死去却破茧新生。

秒杀是好，但是不是唯一选择，今天和长君同学又经过一上午的努力，不断分析和测试，将昨天的5秒再降低了2秒，于是最终我们确定了3秒杀，并将1秒杀藏在兜里。别惹我们，千万别惹我们，惹毛了，秒你！（悄悄话：我们都还没有做html，css和js的编写内容及方式优化哦）

了了重大心事，抬起头来，我想着昨天晚上偷偷摸摸商量的客户端应用事情，就是为我们的iPhone Version建立一个极度精简、定制的浏览器外壳，开发一个EXE文件以供下载，因为我发现太合适了，而且可以很方便的在桌面应用，虽然从另外一个角度思考，这种方式并不好，因为学习应该专注，尤其是我们目前的背单词，那种三心二意的客户端提示学习对背单词这个点而言，我认为完全是浪费时间。不管怎么说还算一个可行之事，也许会有用户喜欢。于是我打开BT，打算下载VS2008 完整版以便开发一个winForm。似乎整个团队就我一个人曾经还做过客户端（VS做个精简的浏览器外壳记忆中好像很简单）。

摩拳擦掌，我正准备下载时，从理辉的MSN签名上看见Google Chrome 浏览器。我第一个感觉是Google把Android上的safari核心浏览器移到桌面了。虽然我对这样的浏览器不感冒，但终归是件大事，立刻下载。理辉告诉我javascript V8，html5, Gears, webkit等特性，我不太感冒，没份额，集成了web标准八代又有什么意思呢？唯一有点开心的是既然基于safari核心，那么我们Englive不用独立兼容了，完美呈现。我想99%的网站都不会为safari兼容，现在Chrome来了，兼不兼嘛？容不容嘛？慢慢争论去吧，都关我们屁事！我笑着对理辉说：“我们又领先了，很多哦。”

得以于我变态的前端架构和实现方式，兼容工作对我来说10%不到的工作时间，现在已经兼容IE6/IE7/FF/Safari/Opera，IE8看了一下，没啥新鲜的，就算再多一个也就是再拍死一只蚂蚁而已。所以真正让我跳起来的还不是兼容性问题，而是我发现Chrome登录Englive.cn是我们的iPhone版（确实是safari核心），然后我有些快乐预感的用Chrome创建Englive应用程序后，我蹦起来了，立刻放弃了VS的下载，转向Google Chrome推广页面的设计。我对长君说：“真是巧啊，昨天还在偷偷摸摸的想这事，没想到Google今天就做得这么纯粹。”梦想就这样被Google实现了，再回想它所拥有的特性，Google真的革了浏览器的命，革了微软的命，Chrome就像iphone一样，是那么清新脱俗和富有创新力，相比之下，IE8成了史前文明，FF和safari也黯然失色，我是这么认为，虽然因为FF插件我暂时还不会转向Chrome，但是我必须要说：

类似Apple告诉世界：“手机的未来是这样的，我现在把它（iPhone）带给您。”；Google告诉我们：“互联网的未来是这样的，我现在把它（Google Chrome）带给您。”

因为iPhone，我成了Apple的追随者；现在因为Chrome，我成了Google的追随者。严格的说我还是崇拜Apple多些，因为Chrome所示的互联网未来对我而言，叫英雄所见略同，不同是他的力量可以领导，而我不过一直在响应，过去在心里响应，现在Englive是我行动上的响应，刚好配上。但是iPhone所示的另一种未来，移动的未来，是我之前完全没想到的，没想到这么快就接近完美的拥有了。

想想，曾经讨论过的Gears；想想，Chrome会开源；我仿佛看见无限可能的未来就在眼前，触手可及。而我要做的就是赶快抓紧准备，欢迎未来大驾光临。

不说了，给大家Englive.cn iPhone Version in Google Chrome App Window的截图，你也可以使用Chrome来创建、访问与应用。至于 iPhone Version 的3秒杀，下个版本Ver.0.0.3上线。

自从失眠后，我就没喝过豆浆油条了。昨天，小毅对我说，睡前喝点酒。我立即响应小毅的帮助，买了两瓶100ml，56度的红星二锅头。到了晚上，没酒量的我，每一口都鼓了莫大的勇气，最后居然喝完了整整一瓶，热血沸腾，浑身疼痛，有效果了，终于凌晨四点睡着了。现在，手臂还在痛，酒精还没挥发完……

随着Englive.cn Alpha 2的上线，我们的iphone web app今天终于开放了，其实早已上线，但是一直屏蔽，一拖再拖，我有时在想，我是不是在产品质量的控制和把关上过于严谨了，包括我们的web version。

开发版、测试版、正式版，对我来说其实感觉都是文字游戏。我们的开发走得是几乎0 bug的上线模式，我可以允许单薄的功能但求无错完美，不能容忍丰富的功能但臭虫随处可见。曾经想过一句口号：简单，行云流水（Simple & Flexible）。这不仅仅是应用的设计思路，也是开发思路。一个一个的来，一个一个的极致，绝不搞一窝蜂。那么现在，我们就是在线背单词。随着iphone版的上线，我们的口号开始改变：学习，无处不在（Study, Anywhere），为此而努力。

Alpha 2版本我觉得已经具备实用性了，昨天晚上我第一次叫上一个完全不是互联网行业的朋友试试看，他说了一句话：“感觉界面很不错，操作不错”，哈哈，真是让我无比受用，我想我们团队也会很受用，我们全体为了UI和UE花费了太多的心思和精力。

http://www.englive.cn/el/service/intro_support_iphone.html

Alpha 2在iphone上还有几个bug，比如进度条不能在翻页时自动伸缩，比如丢失了进度记忆功能。今晚修复了，我们就可以向Alpha 3前进了，我也可以抽时间继续写《重构之美》了，上周简直没时间也没心情。

还有一瓶二锅头，我双眼喷火的望着它，我想，今晚应该能3点睡觉了，明天，估计豆浆油条还是喝不上，奋斗。

float和absolute会有关系吗？我想，都不会这么想，因为absolute意味着脱离文档，不受页面元素影响。

如果一个元素必须先清除浮动（clear:left;）才能正常绝对定位（position:absolute;），你作何感想？

{clear:left;position:absolute;}，今天之前，我从来没有过这种写法和想法。

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>爆牙齿的新发现，请在ie6中显示x</title> <style> .z{position:relative;width:700px;height:1000px;background:#777;} .a,.b,.c{float:left;color:#FFF} .a{width:400px;height:200px;background:#000} .b{width:300px;height:100px;background:#333} .c{width:300px;height:100px;background:#999} .x{position:absolute;top:0;left:0;width:100px;height:100px;background:red} </style> </head> <body> <div class="z"> <div class="a">a</div> <div class="b">b</div> <div class="c">c</div> <div class="x">x</div> </div> </body> </html>

很特定，你如果删除c或b或bc的定义，都是正常的。陈成说改成703也可以，是3px bug？这个bug我知道但忘了，也许3px bug有更好的解决方案了？我不研究了，自由发挥吧。

我仿佛看见IE6潇洒的甩甩头，双手一摊耸耸肩，对我冒出一泡：“一切皆有可能。”……老子直想冲过去拳打脚踢一顿海扁。

分离，这个美丽的词，自从Web标准出现后，便梦萦魂牵的围绕着我，吞噬着我的脑细胞，一百遍啊一百遍。

《理解表现与结构相分离》，多么古老的文章；分离，多么诱人的词语！作为Web标准的核心理念，理论上是那么的干净，透彻与清晰，可为何放到实际操作中却那么的棘手和困难？直到四年后的今天，我仍挣扎于其中。

我第一次真正以团队角度去尝试分离是06年《重构之美》发表完后，我开始以结构化的理念去实施。结果是我基本成功的分离了原本纠缠在一起的前端和后端，但是在前端却没有完成分离，甚至一度我成为了团队的一个瓶颈，因为虽然我解放了后端，却没能让解放出来的大量工作协调的分配给前端的每个人，我只能一个人扛着，我分不出去，06年下半年，我几乎天天0点离开公司，每天12到14小时的工作。那时廷廷对我反复说的两个字是：放下！叫我不要把所有的事都揽到自己手上，哪有下属准点下班双休，而主管天天熬夜还包括周末的。我一脸沮丧的望着他：我分不出去……放下的前提是拿起，我没有拿起，我就没有资格放下，我也放不下。所以我必须先奋力去拿起。

前端和后端的分离相对而言是最容易的，只要后端放弃对结构的编写即可做到，其实在这最容易的一点分离上我也走了一年的弯路。通常而言，一个大团队，后端的人数远远高于前端，不少公司在前端的定义上仅仅限于界面设计，而交互、结构甚至样式其实都放在了后端上，由程序员完成。因此我曾理想的希望每个程序员都能够熟悉Web标准的理念，能够统一思想写出标准化甚至相同的结构，这样可以将结构的编写由众多程序员来平均分担，避免压力全部集中在前端。但是半年多的几次尝试过后我放弃了，首先编写一份合理的结构所需要的附加能力，都是程序员不应该投入精力的前端工作，其次结构的编写是个仁者见仁、智者见智的工作，想统一每个人的思想，何其难！而当我放弃后，当程序员不再参与对结构的编写后，前端和后端的工作就清晰的分离了。这里要特别强调，后端放弃对结构的编写是指每一个标签的确定都不参与。这对一些控件形式开发是个打击，比如asp.net的一些控件，如果前端确定的结构是“<div>数据</div>”，后端这么操作“<div><asp:label /></div>”那么就错了，因为最终输出的是“<div><span>数据</span></div>”。

博客园里大部分都是程序员，实际上普遍来说，程序员也远远高于设计师，看我的文章很多都是程序员，听到我说放弃对结构的设计也许会有抵触，尤其是一些不错的程序员。我想一些工作了三、五年的程序员在前端上的造诣或许不亚于甚至高于工作了一、两年的设计师，即便这样，我建议你要做得最好是指导而不是代替。其实真正优秀的程序员会很准确的找到自己的位置，会很清楚自己的光芒在哪里或将在哪里才是最耀眼的。

说到这里我突然想到也许会产生一个混淆，然后特意去百度“Web标准 程序员”，出现一篇广为传播的文章《网站程序员如何应对web标准》。然后我再次发现不可思议的文章：《为什么ASP.NET程序员应该学习Web标准》，好像还是翻译的，国外的文章。

在第一篇文章中，举了一个例：

<asp:Repeater ID="topNewsList" runat="server" >
　　<HeaderTemplate>
　　<ul>
　　</HeaderTemplate>
　　<ItemTemplate>
　　<li><a href="shownews.asp?id=<%#Container.DataItem("id")%>"><%#Container.DataItem("title")%></a></li>
　　</ItemTemplate>
　　<FooterTemplate>
　　</ul>
　　</FooterTemplate>
</asp:Repeater>

它说这部分代码，由“页面设计师”也就是表示层的程序员完成，这实际上是程序员参与了结构的设计，确定了ul、li、a，我觉得这是错误，而且从某种意义上来说很严重。首先必须区分一下，程序员和设计师的界限在哪里？前端也有编程开发一说，那么和后端的编程开发区分在哪里？再宏观点，什么是前端？什么是后端？这条三八线应该怎么划？

什么是程序员？数据层的开发是程序员，还有通用层，业务逻辑层，表示层。表示层算不算程序员？算前端还是后端？js随着ajax新生，也会和数据频繁打交道，交互开发是不是程序员？又算前端还是后端？写代码的开发就是程序员吗？程序员就代表后端吗？那么结构的设计也是写代码，样式的设计也是写代码，都算程序员都算后端罗？除了界面设计，都是开发都是程序员都是后端罗？最搞笑的是很多人不说自己在做样式设计、交互设计而要说成样式开发、交互开发，甚至还有结构开发，我琢磨着剩下孤零零的界面设计，哪天不爽了跳出来高呼一声“还有我界面开发”，似乎顶着“开发”二字，脚不弯了，腰也直了，鸡胸也挺起来了……凸-.-凸

实际上设计师、程序员、设计、开发都是文字忽悠游戏，无所谓。但是前端和后端是应该有分界线的，而这条三八线，我认为：以操作方式来划分。凡是不需要环境可以静态完成设计、开发与调试的工作是前端。而需要运行环境、编译、数据库等必须动态化才能完成设计、开发与调试的工作是后端。所以大部分交互开发虽然也是编程也会操作数据库，但是我认为它还是属于前端，而表示层的开发则属于后端。“程序员”这三个字通常更多的是泛指后端。那么在上面的实例中，就应该这样：由前端确定用ul还是ol还是div等，后端要做的是动态化页面（加入数据并循环）。用什么方式实现数据的载入（Repeater控件还是其他）不关前端的事，而用什么结构标签格式化数据不关后端的事！不要说后端了，这甚至不关位于前端的交互开发的事，交互开发无论从协同考虑上、性能考虑上、维护考虑上都需要尽可能的避免创建结构，更不应该擅自创建结构。

上面两篇以及类似的一些文章，我认为最大的错误就是没有立足于团队的角度去明确区分前端和后端，混为一谈。简单说说在这点上我的经历和态度转变：2006年上半年我对方欣几十个程序员做Web标准培训，那时我是完全希望结构由程序员编写，结果完败；2006年下半年我在卡当，我再次提出全体培训，被拒绝后开始以边开发边沟通的方式将Web标准理念分散渗透和传递，那时我虽然仍抱希望，却已经有所怀疑，因为我发现结构本来是简单的东西，但是一旦多人带着仁者见仁智者见智的心态去操作时，它就变得复杂难控，于是我开始抓结构的决定权，结果成功了；2007年在爆米花，我开始常说一句话：“不管你用什么方式，控件或编程或其他我听不懂的，反正我只要最终输出的页面，在浏览器中查看源代码，其结构和前端确定下来的完全保持一致，丝毫不差，就OK，剩下的事属于前端，你可以不管了。”程序员可以建议或提出障碍，但是结构的决定权100%的落在前端，我完全的放弃了对程序员的主动培训，结果轻松而极速。

那么，程序员是否需要学习Web标准呢？这个问题换个角度，就是问：设计师需要学习数据库吗？答案其实是一样的：需要。但是这种学习我觉得应该是属于了解的学习，而不是钻研，是辅助的学习，而不是主导。为什么？因为首先确定结构需要深厚的CSS设计能力作为支持。两年前我写过一篇《CSS,Stop!》的文章来提醒大家关注结构，很快我就想再写一篇《CSS, Important!》的文章来阐述结构和样式的关系，因为通过后来那道面试题我发现，CSS的设计能力在很大程度上影响和限制着你的结构设计能力，如果你CSS水平不够你根本不敢去选择更好的结构哪怕你知道（比如你如果不知道如何清除浮动，势必要加入冗余标签）。其次，CSS和界面设计又是密切相关的（比如圆角的变通灵活实现或图片切割的针对性设计），和交互设计也有瓜葛，而最后界面设计与交互设计源于产品设计。这条线就牵出了前端两个字。如果程序员编写结构，就要学习CSS，然后被莫名其妙稀奇古怪的浏览器兼容打懵掉，还得纠缠进界面艺术及排版设计……一步一坑，越走越不熟悉障碍也就越大，水深火热，最后导致的结果便是团队无法形成专业的前端队伍，也无法形成专业的后端队伍，人人在执行上身兼数职，单兵作战，更不要说协同了。这无论对团队还是对个人都是糟糕的：团队是混乱的散沙，个人是平庸的全面。

程序员可以学习Web标准，如果自我感觉很好，可以建议甚至强烈建议，但是不要去替代去操作。术业专攻，博览群晓。前一句指在执行上专一，后一句指在认知上全面。其实我认为如果你决心投身于后端做个牛逼的程序员，完全可以不用在实践中去刻意学习Web标准，学习方式很多，沟通协同中也能学习和了解很多，足矣。而执行上的做与不做，对于个人没影响，一个人可以从头做到尾，但是对于团队这个问题很重要，非常重要！你必须认识到一点，全能是幻象，没有在执行上既精于前端也精于后端的人，因为时间和精力是有限的，你必须放弃，让自己有短处，你才可能拥有傲人的长处。当然我知道还有客观环境在左右程序员的行为，是公司没有建立前端队伍而导致程序员不得不去扛起前端的工作，这是很无奈的事情。所以众多网站强在后端弱在前端，怎么可能不弱嘛，前端的工作由后端程序员兼任，想起一句话：“抢劫，咱不专业啊。”再说下去就是前后人才问题了，不说了。

差不多说完了，我想有人会说：“你在说大团队，我们是小团队人少，不可能分得那么细。”其实无论3、5个人的小队还是30、50个人的大队都可以并应该把前后端分离开来。这个东西，和人多人少没关系，人少你都分不清，人多了就只会更混乱。

所以，分离的第一步：程序员们，珍爱生命，“远离”标准；CTO们，珍爱程序员，分离前后端。

连接
◆《重构之美》总目录
上一篇：重构之美－跨越Web标准，触碰语义网[开门见山：Microformat] (8-11 00:28)
下一篇：重构之美－跨越Web标准，触碰语义网[分离：通用也许是个美丽陷阱] (9-23 08:43)

回锅文，写于2007-5-23 12:21

之后群里不时的对microformat的一些讨论就不发来凑字数了，我只是想说当我第一眼看见microformat的时候极为不齿，甚至没细看，肤浅的因为“micro”就想当然的认为它是微软的东东，我大概记得当时还说过这么一句：“不就是一套class命名规则嘛，老子也定义一套class命名规则，然后叫它爆格式。”但是3个月后，当我在部署标准过程中遇到了一个很棘手的问题时，我猛然想起了microformat，可惜当时自己身陷在繁琐流程、大小会议和沉重的编码设计压力中无法静心思考。今年年初的时候，我终于有机会安静下来，带着自己一直的困惑再度审视microformat后，终于感觉上有所斩获。具体怎样下次再表，我们先还是来认识一下曾被我鄙视的，大名鼎鼎的Microformat。

Microformat到底是什么东东？上面对话中，其实Realazy已经做了简单总结：是在兼容当前XHTML的前提下组织信息的一种方式，通过这个标准的格式，方便于各种不同的用户端来处理。这个比较抽象，我们把它扩展开来。

google了好一阵，都没能找到Microformat的起点，能找到的最早的文献就是我上面的那个链接：http://www.xml.com/lpt/a/2005/03/23/deviant.html。从时间上看是2005年3月23日，发展至少都两年多了，我是在一年多后才接触，两年后才思考，真不合时代节奏，落伍啊。

对Microformat的解释大家可以通过google进行了解，英文强的兄弟可以直接访问Microformats.org了解和学习，中文资料方面比较零散和缺乏，我也没什么好建议。

文字没有实例直观，就像文档没有设计稿直观一样。那么现在我们先直接来看一个实例：将“<cite>Dr. John Philip Paul Stevenson, Jr., M.D., A.C.P.<cite>”格式化为hCard Microformat。

格式化后的结果是：
<cite class="fn n">
    <span class="honorific-prefix">Dr.</span>
    <span class="given-name">John</span>
    <span class="additional-name">Philip</span>
    <span class="additional-name">Paul</span> 
    <span class="family-name">Stevenson</span>,
    <span class="honorific-suffix">Jr.</span>,
    <span class="honorific-suffix">M.D.</span>,
    <span class="honorific-suffix">A.C.P.</span>
</cite>

怎么样？感受如何？我的第一个反应，第二个反应……反应无数次后就是放在现在仍然是两个字：夸张。至于嘛，一句话用这么多的标签来格式化，每个都有class，每个class都很大方，长长的。当然这里我例举了一个比较极端的实例（晕人的专例^_^）。其实Microformat在大多数情况下相对而言代码上是没那么冗余的。下面我们来看另外一个不极端的Microformat。

这是常规的一个页脚呈现，来自http://microformatique.com/：
© 2007 John Allsopp | Thanks, WordPress | Barthelme theme by Scott Allan Wallick | Standards compliant XHTML & CSS | RSS: Posts & Comments
在这个页脚里面有两个微格式：

1、John Allsopp
<span class="vcard">
    <a class="url fn n" href="http://westciv.com">
        <span class="given-name">John</span>
        <span class="family-name">Allsopp</span>
    </a>
</span>

2、Scott和上面类似我就不写了。

我加粗部分就是为了微格式化而必要的代码，这么一看好像也不怎么常规，如果不使用微格式，同样的表现只需要短短的<a href="http://westciv.com">John Allsopp</a>就可以完成。看起来冗余代码依旧很多，那么是否冗余呢？其实这也是我一直迷惑的。其实我也一直在试图说服自己和他人包括现在的读者你：这是有用的。但是……这个这个先暂且放下。

为什么要这么做，增加这么多的标记？Microformat曰：语义化、API。通过这种方式申明数据的语义，形成API，将数据开放出来。问题又来了，需要吗不需要吗需要吗？研究研究？我相信未来的互联网，语义网一定是开放的互联网，不会像现在这样数据无法畅通无阻，存在大量的信息孤岛和信息盲点。但是我们不在明天我们在今天啊，今天需要吗不需要吗需要吗？……靠，不研究了还是先暂且放下。

好吧，增加了这么多代码，好处在哪里？给我一个应用实例。Microformat曰：firefox的Operator插件。耐着性子下载下来，再打开http://microformatique.com/，Operator工具栏上的Export Contact有了数字“3”，他识别出了页面上的3个hCard，选择John Allsopp，Operate提示Outlook打开或下载，下载下来一个hCard.vcf文件，vcf是一种通用的电子名片文件格式。可以被导入各种识别该格式的设备（如手机）和软件（如Outlook）中。打开这个hCard.vcf文件，看见如下代码：

BEGIN:VCARD
PRODID:
SOURCE:http://microformatique.com/?p=160
NAME:microformatique - a blog about microformats and data at the edges : some finer points of hCard and n optimization
VERSION:3.0
N;CHARSET=UTF-8:Allsopp;John;;;
FN;CHARSET=UTF-8:John Allsopp
UID:
URL:http://westciv.com/
END:VCARD

我加粗的地方是可以从页面中获取的数据，而其他部分是Operator按.vcf标准对数据进行的转换，可不可以这么理解呢：Operate充当了xsl的角色，将“xml”转为“xhtml”，将一种标准转为另一种标准。这么一看，要实现这种转换确实需要添加代码申明每个数据的语义，否则无法使得程序读懂数据从而匹配的进行转换。

好了，有所理解了，也对为此增加的额外的、大量的标记有了理论上的认可……可是但是以及But，理论终究是理论，放到实践中，根本没有多大的意义嘛！

什么是梦想，什么是现实，什么是梦想照不进现实，诠译得多么准确。microformat……

开门见了山，横在路中间……登还是绕？

连接
下一篇：重构之美－跨越Web标准，触碰语义网[分离：程序员请“远离”Web标准] (8-20 00:06)
上一篇：重构之美－跨越Web标准，拥抱语义网[废话先] (8-3 14:57)
◆《重构之美》总目录