超越起点 追随自由 我想故我所有

我看不见,我的明天,但今天,绝不重复昨天;顺风是滑翔,逆风才是飞翔,火烧过才能化凤凰!总想对你表白,我的心情是多么豪迈
总想对你倾诉,我对生活是多么热爱

  博客园 :: 首页 :: 博问 :: 闪存 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理 ::

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


分离,这个美丽的词,自从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)

posted on 2008-08-20 00:06  爆牙齿  阅读(4323)  评论(50编辑  收藏  举报