一般我的blog只写些开发时遇到的坑，让大家在开发的时候少遇到这种坑，从而更好的顺畅的开发程序，
也或许是很久没写blog了，最近这阵子不停的发博，有点上瘾的意思，今天想以发博客的方式来表达自己的思想。我没有一个更好的标题来标明主要的内容，其实不一定是前端开发的内容，:)。但本人现在做前端，所以暂且以《关于前端开发的那些事》来命名。
这也是算是理清自己的思路，准备迎接下一场战斗，任何时刻，希望自己应该有清醒的头脑，当然在感情上最好不要这样。
现在国内的前端团队都很年轻，换句话说就是要么是成立不久的，要么是正在建立当中。都有很多问题尚须解决，但哪些问题真正是我们现阶段要解决的呢？每个团队都有自己的答案。
没有什么最佳实践，也没有永远的银弹，只有不停的摸索，找出适合自己的开发方式，管理方式和执行方式。
所以，我也有自己的想法，以下的一些话，肯定也不一定全对。
找到现在真正的问题所在我们现在缺人，请调些人过来帮帮忙。我们现在比较闲，但闲的时间也不知道利用到哪里。现在的项目管理上很混乱。需要一个管理者去沟通解决这些问题现在没有一个人可以做决策，我们需要招聘一些技术牛人来领导，引导我们作决策。现在项目中是用YUI, Jquery, dojo, 还是Prototype？大家的开发方式都很混乱，如命名，如接口，各自都有自己的一套。。。大家都在重复的造轮子，某一天share的时候发现，很多人都在做同一件事，然后，相视而笑。。。脚本库维护，请帮我们写写通用UI组件。。。新人来了怎么培养，很头疼呀。。。....这些问题相信前端的同学或多或少都遇到过，更或者今天你正在解决这样的问题。而我想说，请静下心来仔细想想，你现在真正遇到的问题是表象上的这些吗？
大学有云：“知止而后有定，定而后能静，静而后能安，安而后能虑，虑而后能得。
物有本末，事有终始。知所先后，则近道矣。”
我不是照本宣科，也不要拿鸡蛋扔我，凭良心讲，是不是我们很多时候头疼医头，脚疼医脚的？
前端开发，我们同样也需要有敏锐的洞察力找出真正的问题。
其实每个行业都如此，上次在书上看到个故事。说的是A城市和B城市有一天建了一座8车道的大桥，但是发现每天这座大桥都堵车，于是向这两座城市的人征集修改意见。有人说拓宽车道，有人说再建一座等等等等的意见都有。但最后的解决方案是有人通过观察发现每天早上是A城市到B城市的人很多，于是堵上了。而下班时间是B城市到A城市的车多。于是一个很自然的解决办法是，上班时间A到B城市变6车道，下班时间B到A城市是6车道。
不知道各位看到这个故事是何感想？我们现在需要的不正是这样的解决办法吗？
缺人的问题是不是资源配置有问题，是要了解下属的工作内容，工作计划太饱和，是不是周期性的原因，而这个原因又是什么？又是不是会议太多了？不能缺人就去补人，而应该找出目前真正的问题，再讨论解决方案。
我所遇到过缺人的问题，有会议过多，产品业务过多，一些同学的工作量安排不均匀，也没有充分了解他们的特长，发挥好他们的自身优势，工作效率最大化。
甚至有可能还会因为没有个人发展空间的问题导致的。。。
往往导致直接原因极有可能是项目周期性的原因。
那好吧。我们就从这里开始说，
有些高峰期其实我们完全可以避免。不知道各位的项目开发是怎么样的，是否是关心你下一周要做什么？是不是每天都按例写周报？而你写日报这些可能都不知道是为什么。。。现在很多团队都把敏捷开发当作互联网开发的圣经，什么scrum，XP等等。而敏捷开发的大师告诉我们的也是一种理念，没有一个精确的答案。回到正题，如果是我，我会更关心的是接下来一段时间内的计划，然后根据自己的判断做规划。例如，一个月。拥抱PM，拥包后端研发吧。让大家在这些计划当中形成共识，从而更好的拥抱变化。而上面缺人问题，很有可能是没有计划和规划好导致的。如果协调好，或许根本不存在缺人问题。
因为不是到处都着火，所以我们应该考虑我们现在要的是不是救火队
也或许，有些人认为上面的话相当于什么都没说。
关于脚本库？
脚本库是一个产品，一个项目，一个公司某一阶段的产物。
自然就会有，不同阶段的产物不同。
也就是不一样的产品、项目、公司，有自己各自的问题和脚本库。
要说的是 不是你用YUI就什么事都没了，一大堆配套的解决方案没有给你。YUI也一样。
比如：YUI2，和YUI3升级了。要你痛苦，你怎么升级？不要YUI2了？
唉。以前没想过这个问题。OK，你升级吧，你要测试的同学拿枪指你脑袋吗。
回到原点，重新反思，你需要的是什么，当然，我没说你不能用YUI，juery。
任何事有利有弊，需要的是我们去发现缺的是什么，需要的是什么。
再补一句，壶底抽薪的解决方法是重新审视自己，抽象再抽象，然后。
瞧瞧w3c多聪明，只做标准，能忽悠，谁去它那打酱油还能卖钱。眼红得不得了。我们呢？不能这么做吗？IDL谁说只能给w3c用？
反思自己：我们是前端开发吗？
说到这个问题，其实与上面提到怎么培养新人的问题密切相关，如何相关？等会自然各自有各自的答案。
在第一次做这件事之前，先想想，学校是怎么教你的。你更意愿，更想是什么样的方式来教你，来教你什么内容。
这样你就会有自己的想法了吧？
我本人没有什么技术，脾气比较急，对人比较严格（女的除外）。
其实他们新人很多很多人很优秀，有可能是我们没发现挖掘出来。所以要做的事是：了解他的不足，了解他的优势。――没谁是个圣人。给一个平台，展示自己。――每个人有属于自己的舞台，如果你没有给他这个平台，十个有八个想要走。除非你给他足够高的工资，高工资的概念不是每个人都一样的。
他原来一千块工资，你现在给他两千块，当然可以留，如果原来是一万，现在给一万一，你说呢？
有句话说得好，一分钟有多长？这在于你在厕所里面还是在厕所外面。
给个好平台，他可以自己得到更多。如果他还有激情，至少，他实现了自己自身的价值。
帮助他们引导，而不是解决。――古语这个说得很多了，不需要多说这些了。新人来不是一上来就让他告诉他这个是一那个是二。我个人更倾向于让他看流程图。他自己理解，如果他来执行，怎么样更有执行力。如果他觉得某个地方有问题，不要否认他，也不要认为公司流程一定是对的。
有可能原先的流程就是错的，只不过大家都在一个山洞里做事，不知道外面还有房子住。
解决问题不是满分，请永远记得这句话。纵观所有行业都是如此，现在的年代技术一般不是瓶颈，中国最不缺的就是代码工。其实我想说的是，不要一成不变的做事情，人只有思考才能成长。多总结多思考，好处在于坏处，当然支持多分享。他山之石可以攻玉。
如果以前我们的先辈们以为单车帮我们解决了走路慢的问题，那么现在我肯定漂不到北京。通常来说新人同学来我总是强调，我们很多人都只看到一面，特别是在自己心情不平静的时候。
从世界的表象看来本来就是看圆，当我看只到一面的话，而不去想地球对面是什么的话永远也不知道对面是黑暗的。不是吗？
更何况我们所见不只是这些，它是一个N维立方体。如果你看到的面越多，了解越多，你的世界就越多彩。
所以我更愿意大家更多的去了解PM，思考，多去听听后端的工程师逻辑。了解后端工作这对我们极有好处，对于找线上问题，对于开发当中的业务理解等等都有帮助。
我记得原来后端的新同学来的时候我还可以讲解一下后端的负载和架构部署，嘿嘿。
而了解PM你不觉得很爽吗？你知道现在我们拿到的数据，下一步可以做什么事吗？做运营，做产品为什么这么做，交互与产品与速度如何折衷？了解之后可以多提提建议。
还有可能。。。以后还可以考虑做PM，哈哈。
所以，回到小标题的问题――我们，不一定是前端。
培训，topic
一些大的公司都有学院，一些必选课程，帮助新人来快速成长。
也有topic这样的内容。一般来说这样的topic都是技术研究成果。例如优化flash的swf文件体积新方向。例如CSS3，HTML5。标准。例如ecma。但效果往往都没有太好的效果。我作为一个听者与演讲者的角度看，其原因是因为
演讲者不知道讲什么让大家听，听众不一定感兴趣。
其结果讲么是不知道怎么讲，或者听众人数少，亦或者大家都在用笔记本看小说。
两者兼顾的topic相对比较少，达不到期望值。甚至有可能形成我们为之“骄傲”的形式主义。
是不是有什么方法来解决这个问题呢？习惯从现实当中找找什么解决方案，听上去这个问题象学校一样，那么从学校说起。
我们先假设所有的老师水平是一样的。
在学校里，有选修课和必须课，你会听什么类型的课。
再假设，如果老师知道你们都想问什么，都想学到什么（当然，老师的经验丰富，一般都知道）
如果上述的情况类比到topic，做个简单的系统：开设“选修”。对所有人员在系统里进行征集问题――想听什么topic。topic的什么内容。当然演讲者也可以一定要是技术的吗？不见得。我们太多时候都以程序员的方式去思考问题了，该改改了。
一定要是上述技术的吗？就不能是某个做得比较好的项目的项目管理，协调的经验分享？
演讲者可以领取某个topic，更可以找外部的人员进行培训。最近再给个投票。例如我想听听整个后端的系统架构和设计思路topic。相关问题是，数据库有多少？机器多少？怎么计算带宽。怎么负载均衡。和架设CDN等知识。
topic本身就是为了解决问题，所以只有知道问题，才有解决之道。，还可以将这些toipc的问题总结和结果出来，以后来新人了还可以让其它学习，了解得比较好的同学来讲解。还对大家的职业规划有点好处。做自己感兴趣的有共识的，才有意思。
好象写得有点多。。。我自己都没想到写那么多，如果你看到这里，恭喜你，解脱了，你看完了。
下次有空，再罗索下这些。不要再重复造轮子我们想了解大家即时遇到的问题让会议尽可能少些吧---------------
over。