博客园_传说中的弦哥

是谁动了程序员的尊严续-也谈谈软件开发团队的管理

2011-11-28T15:00:00Z

点题：是谁动了程序员的尊严？其实质是对一些遭受挫折的程序员的勉励，对热爱技术的肯定，以及小部分对以前疯狂追求技术状态的缅怀。和管理一毛钱关系都没有。居然在回复里有小部分人拿管理手段和管理艺术说事，弦哥想说的是本质上无所谓有什么管理，核心或中层人员往往目标明确，很大程度上是自我管理，底层人员其实只需要扔几个管理工具即可，不起决定性作用。打个比方：你第一个次和MM开房，装13的人会告诉你那是艺术，需要很多技巧和花招，弦哥只会笑而不语，临走前告诉你：“跟随你的心...”。结果是明显的，如果你听信前者，必然导致你心中杂念太多，手忙脚乱，折腾一个小时之后一事无成，最后被MM一巴掌扇下床...管理就像独孤九剑，一旦你有“招”就会被识破，一开始就输了...

是谁动了程序员的尊严？里谈了作为程序员和技术人员应该积极的去面对一些挫折。相应的这篇是谈作为技术团队管理者应该思考的一些问题。首先我是比较不喜欢“管理”这个词的，因为没有谁会喜欢被“管理”，开始我以为是我放荡不羁的性格和无知者无畏的草根情怀所导致的...后来接受了一些关于所谓管理的正规训练后，这种感觉反而更加强烈。

对于所谓项目管理，我大概有这些学习背景,公司培训的：MBA全景教程，欧洲商学院系列，高级项目经理考试，PMP考试，还有时代光华的那些诸如领导艺术之类的，世界500强流行的什么MOT之类的培训（也可以说是洗脑...）这些虽然我都不是太感兴趣，感觉这些都是西学中的术，个人比较推崇国学中的道，但也不是很排斥，基本都过了一遍；自己看的：《人月神话》，《软件工程》，《敏捷开发》，《代码大全》，《软件开发随想录》，还有些不入流的等等，JavaEye的软件开发和项目管理版也爱没事看看；人文方面的：各种中国正史野史不全的（明史正儿八经的看过正史，主要高中的时候受韩寒和《万历十五年》的影响），杂七杂八的各种儒释道粗略的，诸子百家中显学大概的，西方哲学简要的...所以可以看出我应该不只是一个会写代码和好色的偏激狂....-_-b，下面言归正传，来谈谈“管理”：

1.首先对于软件开发团队来说根本不存在严格意义上的“管理”。你从敏捷开发就可以看出来，敏捷只允许你团队中有1个，不超过2个的新手。对其他的团队成员的要求基本是从技术到职业素养的全才。很多人在研究敏捷，什么结对，扁平结构，站立会议....那些都是术，都是花招...。比如你10人的团队没有8个神一样的程序员那都是白瞎...。而神一样的程序员还需要管理吗？我承认敏捷里有非常多优秀的思想和实践，但若放到你自己的团队里玩，我觉得更多的结果是悲剧,喜剧是因为你真的非常幸运，你的团队成员足够强大，和你管理水平和敏捷真的一点关系都没有...

2.而现实的情况是，一个10人的团队中只有2-3个骨干程序员。他们解决了整个项目80%的问题，剩下的7-8个程序员无关痛痒，他们机械的去写一些有完整技术解决方案的模块，最坏的情况是这7-8个人解决不了任何问题，还会在原本成熟的解决方案下制造一些问题。这段可能很多人不爱听，但不能否则这是事实，同时也自问自己在团队中的价值。其实你看很多牛X的大产品其实都是由个别的几个牛X的技术人员写的，团队其他人基本都是打杂的，国内外都一样。

3.谈到这里，作为一个团队Leader你应该清醒的意识到你要做的事情首先是对于骨干程序员来说的：最次的让2-3个骨干程序员不会认为你是个不懂技术的蠢货，较好的是让他们觉得你在技术上是有建树的，最好的是用你的人格魅力感染他们。

4.对于其他的7-8个程序员，适当的技术培训是必要的，但不应该对他们抱有太大希望，这样大家都会很累。既然他们想成为码农就让他们当好了，个别能脱颖而出的可以重点培养。

5.管理工具和管理技巧：不要让大家觉得在被管理，没有人喜欢被管理。你可以先给大家介绍一个比较前卫的管理工具，然后说我们大家来玩玩这个管理工具，看看咋样。如果效果不好，大家不会觉得你的管理水平垃圾，只会觉得这个管理工具不好玩而已；如果效果好，那大家就Happy的玩下去，最后你会发现你的团队成员完全没有感觉在被管理，但其实你团队里的管理工具和管理方法真的是一大堆，有时候你自己都会觉得比较烦，但大家还乐滋不疲....人力资源部的来评估你部门管理水平的时候会着实吓一跳...

6.对于一个团队Leader或公司技术总监是否应该深入了解技术的问题，我想是没有什么必要讨论的，这是必须的！对于公司来说，你决定的技术方向决定了公司未来几年的产品和战略，如果你对技术一知半解，那是不可想象的，足以搞死整个团队甚至是公司。比如让一个技术水平一般的技术团队使用MOSS作为平台进行开发，比如老板被微软,IBM那帮所谓首席科学家忽悠的头脑发热想大搞云计算中心等等...往小了说，你不懂技术就意味着你无法真正掌握项目的进度，那些所谓的项目管理工具都是浮云....连项目进度都掌握不了的项目经理？还是项目经理吗？

7.你想说我有一揽子的管理工具，但我只需要一个问题就可以破解你那不需要技术的管理神话，项目做到一半，遇到一个技术问题，所有的技术人员都告诉你不能解决，你怎么办？怎么保证工期？外包？外援？那只会使你的项目风险更大，更加不可控我们都学过的是吧？ 问题在于由于你技术的缺乏导致你的技术风险预知能力下降，技术解决能力基本为零，你在大家面前是个十足的蠢货....

8.我们经常看到一些团队的项目经理的很多问题和抱怨，我说解决问题的方法和简单，你把代码实现就可以了嘛.......你会实现而不去实现，和你压根儿不懂实现是有本质区别的。就像流行的“技术不重要，思想才重要”，这句话是给懂技术的过来人说的....代码都没写过10万行就拿这话来说事是可笑的。

9.在公司里，没有带团队做3个以上真正成功的项目之前，先把你的任何关于公司和团队的想法意见保留起来。就算你在那个职位，也不会有太多人听的进去，实力和尊重是靠事实证明的。

　 10.真正给公司赚到钱，也让大家看到你的人品和实力之后：对非技术的领导强调技术，对团队技术人员强调需求。

总结：大道至简！不要过于迷信西学的那些管理工具和管理技巧，除非你把西方哲学和文化的历史好好学一遍，否则你只会邯郸学步，不得要领。也许你回过头来看看咱老祖宗的那些东西，反而会豁然开朗呢？

举个例子：软件开发中的面向对象和面向过程的两种开发方式最早可以追溯到亚里士多德（貌似在我们的教科书中他就是个该打倒的学术权威..）的分类和逻辑两种认识世界的工具...其实这也是西方科学的根本，想当年我们学编程的时候那个云里雾里啊...点破之后其实很简单是不是？什么一切皆为对象，什么至上而下...说白了就是分类和逻辑。有时候我们会标榜面向对象而鄙视面向过程，其实很愚蠢是不？

再比如现在量子物理学算是走进了唯心主义的死胡同（当然也有平行宇宙的说法..）...居然观察会影响客观结果！但其实孔子对于占卜早说过,你不要算，在你算的一瞬间其实结果就已经变了(不占而已矣)。真的是和电子的波粒二相性一样一样儿的啊...

当然！这些“思想”固然重要，但请不要忘记踏踏实实写好你的10W行代码先...

也许有朋友会问，你上篇说的那种有亮剑精神的团队呢？比较遗憾现在在一个比较大的公司，在一切都需要看财务报表的公司文化里不允许我那样搞，大公司很多事情也更复杂需要考虑更多。而且那种需要我投入极大理想主义精神，精力和感情的团队貌似也不太适合我这个快当孩子他爹的人。谨以文送给我那牛B的亮剑团队和团队里的兄弟们。

本文链接

是谁动了程序员的尊严？

2011-11-28T06:12:00Z

最近园子里有个MM发了一篇一些让程序员伤心让程序员开心的话，作为入行快10年的老程序员的我，她那篇帖子里不管是 “让别人开心的话”还是“让别人不开心的话”，基本我都说过。软件开发中的各个角色基本我也都担当过，程序员，架构设计，项目经理，技术总监，甚至是售前，陪客户吃饭。虽然现在早已不是当初迷茫的小菜鸟，但对于技术和编码的热爱是一直没有改变的，也从来没有脱离过一线的编码工作。所以我想关于程序员的社会认同感和尊严这类的，我是可以来谈一谈的。

首先我们来谈一谈什么是尊严。从哲学的范畴来说尊严是一种文化，文化是人和动物的本质区别。比如自杀这种行为就是一种文化,只有人才会有。如果要说活着有什么意义的话，对于动物来说生存和繁衍就是他们的全部意义。但人不一样，人为了尊严，为了信仰可以“不为五斗米折腰”甚至可以“留取丹心照汗青”，汪精卫的“引刀成一快，不负少年头”也无不让老少爷们儿热血沸腾。所以马斯洛的人类需求金字塔我是不大赞同的。至少作为一个受过教育的人来说，精神层面的需求应该高于生存的需求而存在的。否则为了生存而抛弃自己的信仰和尊严，那活着也是毫无意义的，与猪狗无异。

当然有好事者会问生命的意义是什么？所谓的信仰和尊严于乎宇宙又有什么意义呢？我想说对于这种终极问题的思考大概是这样的：大多数人会觉得研究这种问题是在浪费时间，这种终极问题本身就是毫无意义的；一部分人从小时候就开始研究到死也没有研究出什么名堂，一事无成；一部分人走火入魔，研究成了精神病.....;极少数人获得了极高的成就。

扯远了，接下来我们来谈谈如何得到所谓的尊严。可以明确的说，尊严并不是自指的。你可以说“我是独善其身的！”，但你不能说“我是有尊严的！”，这是毫无意义的。我们必须承认，尊严是别人（社会）给我们的，我们自己是无法有尊严的。所以从这个意义来说我是比较反感“自尊”这个词的，我一直以为自尊不过是一些心理有问题（自卑）的人的挡箭牌，很明显“自尊”是不能脱离“自卑”而存在的。稍有社会经验的同学肯定都会遇到那种表现出具有极强自尊心的人，这种人往往很难相处，非常敏感，你不小心的一句话就会踩到他的狗尾巴。而随着深入的了解，你都会发现这种人其实内心非常自卑，整个人处于一种强大的防御姿态，就像WOW里的防战，恨不得“盾墙”是没有CD的...所以一味标榜自己的“自尊”是可笑的，不会赢得别人的尊重，只会让别人觉得你是一个又自卑又可怜的家伙...

所以，以上你可以看出尊严问题并不是程序员独有的。但往往我们发现程序员，技术人员往往都有极强的自尊心，或者说异常饥渴的希望获得别人的认可和尊重，而另一方面他们往往也表现出不大尊重别人，很难相处。这个结论你可以轻易从IT公司所有的非技术人员嘴里获得。其实如果你对科学史有一定了解，你会发现有这个毛病的大有人在，像牛顿，爱因斯坦，波尔，薛定谔..."愚蠢","白痴"这类的语言经常充斥于他们的科学论文。如果你看过一些比尔盖茨，乔布斯，鲍尔默这些人的八卦和传记，也是出了名的"fuck","dick"之类的常挂在嘴上。而我认为（和看到的），任何一个能力强悍的软件开发项目经理或团队Leader都不可能的是一个好脾气。我并不是说他们在某方面小有建树就有资格对菜鸟们呼来呵去，但我敢保证，如果你有一天成为一个能独当一面的真正认真负责的一线Leader的时候，你的脾气绝对不会比我好到哪儿去。所以高手并不像有些菜鸟说的那样如此超脱，淡定，谦恭...那是圣人，你有问题的时候不会叫“圣人，替我做主啊～～”，你只会叫“大人，饶命啊！”。你的直接团队Leader才是“大人”，他才能给你调Bug帮你擦屁股。作为“圣人”的董事长，技术总监虽然都是笑呵呵的，但他不会解决你的任何实际问题，他只会告诉“总裁”，总裁总裁，总是在裁人嘛...还搞不懂“大人”的可以参考《易经》九二爻辞“见龙在田，利见大人“...

就拿我自己来说，我也知道有时候我脾气不是很好，在团队沟通中说话很直，有时候甚至很暴躁。我也尝试了好几年，上到儒释道，中到西方哲学，印度灵修，下到什么办公室处世之道，看不少...就想变得淡定一点，变得有点高手的仙风道骨...可悲剧的是,我在大家心目中的形象还是这样的：

我自己归纳了一下，有如下原因：

1.对做的每一个项目，甚至每段代码都力争完美，很难忍受团队成员不认真负责的态度。

2.不能忍受年轻的团队成员做一天和尚撞一天钟的工作生活态度，天天教训他们要好好学习工作将来才能娶个好媳妇儿（现在改了，毕竟不同的人有不同的生活态度）。

3.有喜欢推诿责任，爱找借口的人。

4.多次纠正而不改变学习和工作方法的人（路都走错了，再怎么努力也是白瞎）。

5.仅把写代码当成一种工作的人（对于搞技术工作，你不热爱它就根本不可能做好）。

6.在既定的详细框架下还频繁出错的人（就算是一黑丝美女天天撅着屁股让你擦，你的心情也不见得会很好，更别说是一群蓬头垢面的天然呆的家伙们）。

7.幻想混几年代码就能当项目经理，脱离技术做管理的人（这种人，哥都不惜得理他...）

8.在非技术的领导面前天天强调重视技术人员的重要性（一方面给你们这些家伙争取利益，一方面你们这些家伙还不争气，我能不火吗！）

所以你可以看出在国内任何开发团队中都有不少这种人，这也就是敏捷开发无法在国内真正实践的根本原因，敏捷里要求的是真正的程序员，而现实团队中能有2-3个真正的程序员，作为Leader的你做梦也会笑醒。只要你的Leader出发点是好的，请你原谅他的坏脾气吧...一团和气，对项目质量不闻不问的团队里是不可能做出好的项目和产品的，对你个人的成长也是不利的...真想混日子还是去当公务员比较好...

那么如何成为能让大家尊重的程序员呢，按我个人的经验来说要做到以下几点：

1.为人正直，不要有道德上的硬伤。否则就算你技术再好也无法得到别人的尊重和重用。

2.真心热爱技术，热爱工作。可以迷茫，可以彷徨，但永远不要放弃当初自己追求技术的梦想。

3.努力把看起来无意义的事做得有意义。也许你正在做一些无关痛痒的蛋疼项目，但不要埋怨社会，不要找借口，蛋疼项目也可以做成伟哥项目...关键在于你！哥们儿！就是你！你才是它真正的爹！，不在于你的客户和老板。

4.也许你旁边充斥着各种马屁精，混世魔王，但你要相信他们一样也会觉得没有被尊重。否则也不会有办公室的一群娘们儿聚在一起八卦谁谁谁是马屁精之类的...你要相信群众的眼睛是雪亮的，真正做实事的人越少，越显得你的价值重要，你也越被尊重。哥们儿经常去政府部门，事业单位做项目，酒后三旬无一例外的都会说“还是佩服你们这些搞技术的，是靠真本事吃饭，你看我们，唉...”。所以说你看都是“围城”。人都是很贱的，就看你想怎么个贱了...顺带说一句所谓“拍马屁”那也是本事，你也不要瞧不起别人。其实大家都是出来混饭吃的，谁也没比谁高尚多少。高尚是高尚者的墓志铭,真正高尚的都卧轨了...

5.努力充实自己，让自己自信起来。有一天当你遇到别人的批评你的时候，你会对批评你的人竖起大拇指说：“牛B！人才！哥已经独孤求败很久了...”，而不是凄凄哀哀的发帖乞求得到别人的尊重。

6.尊重非技术人员，尊重所谓“拍马屁”的人。如果你觉得你周围尽是不学无术的在得志,在做领导，那么我想说其实你还太嫩了，看到的都是表面现象...

7.不要太把自己当回事，这个很重要。太把自己当回事的人是无法进步的。你还很年轻，只要做的事情的对的，不要太在意自己的身体和幼小的心灵，随意糟蹋吧！熬夜吧！熬夜的时间与你技术水平和出人头地的几率是成正比的。当然我说的是熬夜搞技术写代码，不是下副本...

8.坚持自己的信仰，坚信搞技术是有出路的。

9.对待工作认真严谨的人，走到哪里都会被人尊重，这是毫无疑问的。很多小妞不都说吗？男人认真工作的样子是最性感。。。

总结：天行健，君子以自强不息。尊严不是乞求别人施舍的，而是自己奋斗出来的！至于女人嘛，你懂的...

后记：本来我不是很喜欢发这种人生贴的，不过看到那个MM帖子，人家女孩子撒撒娇其实可以理解。但一群大老爷们儿也在那里跟风，实在有点看不下去，于是乎有了本篇...

回复中也有对我带的团队真实情况的设想，关于我个人的性格和团队的情况应该可以参考《亮剑》。俺们的口号是“剑锋所指，所向披靡” ，说白了应该是一群虽然过着苦B的生活，但仍然保持着一种技术人员独有的牛B气质的人。团队成员之间也在各种苦B的加班，熬夜，酒后谈技术谈人生谈理想谈女人的状态中结下了深厚的友谊。这是那种“互相尊重，客客气气”的团队说不能企及的，也是我所追求的,它具有非凡的战斗力。其实建议大家看看《亮剑》的小说，电视剧只拍了前半本，后半本过于残酷，没有被拍出来，但恰恰体现出了亮剑精神的精髓...一个牛B的leader从本质上说不在于他的技术有多强，而在于他用他独有的人格去感染团队中的每个成员，使得这个团队也具有同样的气质。当然这种方式并不一定值得推广，也并不一定在所有团队中适用,但你不能否认它对像我一样的偏执狂们具有致命的吸引力。

拿“管理”说事的看这个是谁动了程序员的尊严续-也谈谈软件开发团队的管理。。。

本文链接

Asp.Net大型项目实践系列第二季（三）莫人云亦云,莫走弯路!正确认识ExtJs4

2011-11-24T02:36:00Z

华丽的背后是枯燥的代码，这就是程序员的杯具，把华丽带给别人，把枯燥留给自己....下篇我们将讨论对ExtJs认识的误区，评估它是否适合用在你的项目中，并且弦哥会带你走捷径，正确的掌握ExtJs的开发调试方法，让ExtJs的上手和开发不再纠结。

认识ExtJs

1.Asp.Net能用ExtJs吗？

它是展现层的技术，与JS,HTML,CSS有关。至于服务器端是.Net,还是Java,PHP等无关。

2.ExtJs适合什么样的项目？

按照官方的说法，ExtJs是给你拿来做B/S的桌面应用程序的，并不适合做门户网站。我个人理解，ExtJs比较适合做需要大量复杂界面布局和交互的信息管理系统（MIS）。

3.ExtJs效率不行，好慢...？

确实，ExtJs做的复杂布局和交互的页面，在IE6,7,8下非常慢,在IE9下也不是很理想，但在Chrome,FireFox等新一代浏览器中运行速度很理想。我敢说在同样复杂的页面布局和交互下，绝对比你用Asp.Net第三方服务器控件强几倍。所以在目前情况下，你不得不强烈推介你的客户使用Chrome这类的浏览器来运行你的系统。对于一般内部局域网使用的信息管理系统，这样的要求是不过分的。

4.ExtJs效率问题的原因？

B/S程序，展现层的效率瓶颈在于3个方面：浏览器对Js的解释速度,HTML DOM的渲染速度,内存释放以及网络带宽。随着ExtJS的多次版本优化之后，这些问题都得以在一定程度的解决。特别以前让人诟病的1M多的庞大JS库的问题，在ExtJS4新的按需加载机制下已经完美解决。而其他问题往往和具体的浏览器有关，也不是Ext能解决的。事实上目前在Chrome浏览器下，我们用ExtJS做的系统响应速度已经快到了令人发指的地步....如果要实现同样复杂的界面布局和交互，我找不出能比ExtJS这个解解决方案更快的技术。

5.用ExtJS需要写大量的JS代码，会导致系统难以开发，调试，维护？

相对于习惯了简单拖拽控件的Asp.net程序员，ExtJs确实需要你掌握更多的基础知识。但我们都承认很多需求并不是拖拽控件能解决的，要想做一个真正拿得出手的应用程序，你不得不付出更多的努力，下篇我们会讲如何正确的学习，开发，调试ExtJs。所以技术水平不好的技术团队并不适合用ExtJs，用一些功能强大的第三方服务器控件，如DevExpress,Telerik也许是你们的更好选择。正如也有很多难以维护的C#项目一样，你不能怪C#垃圾，只能怪自己垃圾。就像玩Wow一样，没有垃圾的职业，只有垃圾的玩家....

6.公司,技术团队和个人是否值得对ExtJs投入学习成本？

客观的说你投入的是对Javascript的学习成本，ExtJs本身没有太多你需要投入的。除非你觉得看英文API是一件非常困难的事情。而对Javascript的投入，从现在的技术发展趋势来说，绝对是值得投入的...不幸的是大部分国内Asp.Net程序员对Js的掌握程度还停留在从网上扒段特效的水平...

7.ExtJs的界面看起来都一样一样的，审美疲劳...

没有人阻止你对ExtJs的界面进行改造...事实上国外有很多用ExtJs做的应用你根本看不出来说ExtJs做的。而且在ExtJs4里支持sass,可以非常方便的改变ExtJS的皮肤和样式。

8.Ext.Net很好,我可以不用写烦人的Js,用C#也能实现ExtJs的强大界面功能？

我想说更深的封装只能让你更难驾驭ExtJs，虽然Ext.Net也是开源的，但很难想象连JS都不敢碰，怎么能用好Ext.Net。用Ext.Net就意味着你已经丢掉了很多ExtJs的优势，还不如用第三方服务器控件...

9.选择ExtJs的理由？

优秀的UI交互能力和功能强大的UI组件天生就是给信息管理系统用的；

附送的皮肤样式和成熟的布局，一定程度上减少了美工的投入；

文档非常完善和好用；

已经很多年了,到了第4个大版本,无论是成功案例还是社区的技术讨论都非常丰富,你可以轻易搜索到自己遇到的问题；

开源和良好的面向对象结构，可以让你非常容易的扩展和重写ExtJs，实现自己想要的功能，也可以自己根据项目需求深度封装成自己的组件；

多浏览器的兼容性做的非常好，几乎不用做任何修改，就能在目前流行的所有的浏览器下完美运行；

Javascript+HTML(5)做为WebUI开发的主流技术现在开来已经非常明朗,ExtJs发展形式一片大好；

从近些年来的ExtJs的版本升级可以看出，ExtJs的开发团队是非常负责任的也是非常牛B的；

弦哥也在用...

总结：对于开发技术的应用，只有垃圾的选择和垃圾的应用，没有垃圾的技术。不加前提的对一个技术片面评价，是浮躁的；不深入了解就人云亦云那是愚蠢的...

下篇预告：

Asp.Net大型项目实践系列第二季（四）ExtJs4 入门,开发,调试不完全指南

To be continue...

本文链接

Asp.Net大型项目实践系列第二季（二）Windows桌面的ExtJs4实现(含源码)

2011-11-22T16:16:00Z

女人用丝袜征服男人,男人用丝袜征服银行，光鲜亮丽的外表和包装是非常重要的。对于看惯了千篇一律的框架菜单界面的客户，一个华丽的模拟Windows桌面的系统界面一定能让他就像看到穿黑丝的背影一样，感到眼前一亮。虽然穿黑丝的背影正面可能是个大妈，信息系统的核心也绝不是华而不实的界面。不管怎么说提供一个能瞬间亮瞎客户狗眼的界面和交互模式绝对不是件坏事。

源码下载：Xg.part1.rar , Xg.part2.rar

说明：

1.有些地方没有仔细推敲,还有重构的空间,应该没有Bug,不过还是建议学习消化后再用。

2.我修改了下,代码里只有展现层。业务逻辑和数据访问层我先去掉了，这样比较符合本篇主题，也方便大家单独应用，以后会陆续添加

3.附送登录页，存在明文传送密码的问题，用在项目中要注意

4.附送传统菜单页面,主要是为了演示模块化加载功能页,缺少基本的退出,重新登录之类的功能,自己可以添加功能

5.如果打算全套上ExtJs4,建议看完本系列并熟悉ExtJs4后再酌情考虑。如果只是用这个“壳”，套Iframe用自己的页,那就没啥太大问题了。

6.如果没有使用ExtJs的经验，不建议用本篇的代码来学习，这是综合应用，代码比较复杂。

部署运行指南：

1.下载Xg.part1.rar和Xg.part2.rar 两个文件并解压，得到目录 Xg

2.在 Visual Studio 2010中打开 Xg.sln,如下图

3.把整个解决方案编译一下,应该没有任何错误。

4.把Xg.MVC.Application项目设为启动项，然后按F5运行（建议用Chrome浏览器,IE9也行。不建议用IE6,7,8 速度会比较慢）。你也可以部署到IIS里运行。运行起来如下图：

5.用户名：admin 密码: 000000 界面模式有“酷炫桌面”和“经典菜单”2种选择进去后分别如下图：

不完全使用指南：

1.目录结构解释：

2.菜单和快捷方式都是从C#返回的Json动态生成的，打开Fiddler2 根据请求的URL地址找到相应Controller下的Action 就可以查看到代码。

3.“测试模块1”演示了ExtJS4的按需加载新特性，也就是只有你打开这个模块的时候，js才会加载。所以在Module1.aspx并没有对Module1.js的引用。而是这样去new了一个模块对象的实例：

要注意的是按需加载需要在run.js里注册文件夹路径：

Ext.Loader.setConfig({
enabled : true,
paths : {
'Mod.TestModule' : 'http://www.cnblogs.com/Scripts/Mod/TestModule',
'OIT.ex' : 'http://www.cnblogs.com/Scripts/Extensions',
'Ext.ux' : 'http://www.cnblogs.com/Scripts/ux'
}
});

3.如果不想要那个在飘的浮云，去run.js去掉如下代码：

// 浮云控制
var i = -500;
var el = Ext.get('scene_cloud');
var cloudTask = {
run : function() {
el.setStyle('left', i + 'px');
i++;
if (i > document.body.clientWidth)
i = -500;
},
interval : 30

}
Ext.TaskManager.start(cloudTask);

4.WallpaperSettings.js可以设置自己的背景图片列表，对应的文件夹是“\Scripts\Desktop\wallpapers”

store : new Ext.data.TreeStore({
model : 'HMSDesktop.WallpaperModel',
root : {
text : 'Wallpaper',
expanded : true,
children : [{
text : "无",
iconCls : 'asterisk_orange',
leaf : true
}, child('blue.jpg'),
child('blue-curtain.jpg'),
child('fields-of-peace.jpg'),
child('fresh-morning.jpg'),
child('colorado-farm.jpg'),
child('blue-swirl.jpg'),
child('desk.jpg'),
child('desktop.jpg'),
child('desktop2.jpg'),
child('sky.jpg'),
child('19201080.jpg'),
child('FGHJ_079020.jpg'),
child('cloud.jpg')]
}
})

5.HMSDesktop.js是桌面js的实例，建议从这里看起，改开始菜单的标题也在这里：

// 开始菜单
getStartConfig : function() {
var me = this, ret = me.callParent();

return Ext.apply(ret, {
title : '传说中的弦哥',
height : 400,

6.logo图片啥的路径在“\Content“和"\Scripts\Desktop\images"下，可以自己换。

下篇预告：

估计大家会提出一些问题，计划下篇集中回答和解决大家关于本篇的问题，以及更详细的各个界面元素的代码说明。

如果大家没有提啥问题，那下篇将会是这个：

Asp.Net大型项目实践系列第二季（三）莫人云亦云,莫走弯路!ExtJs 认知、开发、调试
华丽的背后是枯燥的代码，这就是程序员的杯具，把华丽带给别人，把枯燥留给自己....下篇我们将讨论对ExtJs认识的误区，评估它是否适合用在你的项目中，并且弦哥会带你走捷径，正确的掌握ExtJs的开发和调试方法，让ExtJs的上手和开发不再纠结...

To be continue...

本文链接

Asp.Net大型项目实践系列第二季（一）哥欲善其事，必先利其器...

2011-11-18T00:24:00Z

　　Asp.net大型项目实践系列第二季 发布后得到了大家的鼓励和支持，相对于博客园近期充斥的各种面试贴，职场贴，人生贴，新闻贴的浮躁态势，大家的反馈让我感到一丝欣慰。我会尽量把这个系列写好，不辜负大家的希望。

哥欲善其事，必先利其器...做软件项目不是请客吃饭，不是做文章，不是做毕业设计，也不是做个小Demo。它是对各种技术和思想的综合应用，是对你智商，情商，体力的变态考验。所以在开始之前我们需要做一些准备工作...

技能准备：

1.如果是你公会的MT，你必须选择放弃一切公会活动来专心跟我们一起做这个项目，我最讨厌边做项目边玩Wow的程序员，不抛弃浮躁的心态是不可能做出靠谱的项目的，所以请将你的金币邮寄给下图的角色：

2.掌握.Net和C#的一些基础知识，下面的这些是必须的，否则可能使你对这个项目的代码理解造成障碍。

3.对架构,分层开发,设计有一些基本的了解，如果不想系统的去看《企业应用架构模式》，《领域驱动设计》这类书，至少也应该去JavaEye的领域模型板看看那些口水贴。进一步的建议去http://www.codeplex.com/上找一些开源的范例项目看一看如: Oxite, Microsoft Spain - Domain Oriented N-Layered

4.对MVC模式及Asp.Net MVC有大概了解，没有了解的应该在园子里搜下入门,教程什么的，然后做个可以Run起来的简单Demo。

5.如果你是一直在用拖服务器控件的方式去开发Asp.net的，那么可能需要你恶补一下Html,Css,Javascript的基础知识，尤其是如果对Javascript的语法掌握的不熟练，ExtJs绝对会让你感到恐惧和无从入手....话说Javascript现在形势一片大好，还处于从别人那里扒js代码片段来实现点特效水平的同学值得在Javascript上下点功夫了。

6.去ExtJs官方网站上看看ExtJs的Examples和Documentation 在这个项目中你将长期和它们打交道，除非你只想用我自己封装好的一些组件,做一个初级程序员,但可惜你不在我的团队,我也无法对你提供技术支持...

7.去把李永京大哥的NHibernate之旅系列文章从头到尾看一看，作为对NHibernate的入门和基础掌握，我只会讲NHibernate在实际项目中的应用

工具与开发环境准备：

Microsoft Visual Studio 2010：

不解释...

Microsoft SQL Server 2008：

这里我们以SQL Server为例,这个解决方案几乎不做修改也可以用到Oracle里

Aptana Studio + Spket插件：

不建议你在记事本或Visual Stdio里敲Javascript代码，那会是场噩梦....所以装上Aptana Studio 和Spket插件并基本熟悉这个IDE，让Javascript不再可怕。

Fiddler2：

如果你不想在Web开发中成为瞎子，请你装上Fiddler2并熟悉他的使用。

NHibernate Profiler：

如果你不想在Nhibernate访问数据库的开发中成为瞎子，请你装上NHibernate Profiler

PowerDesigner 15：

就算你再“敏捷”数据库物理模型总得有吧...

Google Chrome：

ExtJs在它上面跑非常有快感。如果你不想在Javascript执行的时候成为瞎子，请按F12 ，确保在开发过程中一直打开“开发人员工具”的Console页（如下图），并学习掌握Scripts页

看完上面这些准备工作，有些同学估计心里凉了半截。应该可以看出就算现在给你源码，你要在项目中掌握和使用好它也不是一件容易的事情，至少你需要把你Wow帐号里的金币都给我....

另外我看回复中大多都是觉得界面比较Cool，其实有两点误区：

1.也许站在程序员的角度，ExtJs的界面确实有可圈可点的地方，但我敢保证作为非技术人员的客户看到这样的界面并不会太兴奋，所以想做出良好的人机交互界面不仅仅是用ExtJs那么简单，其实也有不少用ExtJs但用起来很垃圾的系统。而且ExtJs本身有不少问题和局限性，以后我们会谈到。

2.ExtJs只是本项目中的界面解决方案，是一个技术难点，但不是全部。

下篇预告：

Asp.Net大型项目实践系列第二季（二）Windows桌面的ExtJs实现（含源码）

To be continue...

本文链接

Asp.net大型项目实践系列第二季

2011-11-17T06:30:00Z

2年前心血来潮写了Asp.Net大型项目实践系列,得了园子里很多朋友的关注和宝贵意见。时隔2年无论是工作和生活都发生了很多变化，唯一没有变的是对技术的热情。回过头看,之前写的那个系列和构架还是有很多错误和值得改进的地方。打算把这2年的积累和改进做成一个新的系列，应该是一个全新的东西。但和之前那个系列一样，不会变的理念是：实践第一；是真正可以用在生产环境下综合技术解决方案；放全部源码；

下面简单描述下准备在这个系列里讲的东西，看看大家的反应，如果感兴趣的人多我就开始写。

1.和前一个系列一样还是一个从持久层到展现层的完整信息管理系统解决方案

2.持久层用的NHibernate3.1

3.展现层用的Asp.net MVC+Ext 4.x

4.完整的权限控制

5.一套代码两种UI模式

模拟Windows桌面模式:

传统模式：

6.自定义的EXTJS组件，极大屏蔽ExtJs复杂的API

7.特定业务场景下需要的自定义表，自定义字段，动态表单，动态列表，自定义Excel导入导出，自定义查询。

注意我并不是在做一个所谓的平台，但在有些特定业务场景下真的需要一定程度上的自定义，放出来的目的只是抛砖引玉讨论技术实现，个人是坚定的反开发平台主义者

自定义表和字段

根据自定义表和自定义字段动态生成的表单和表格。根据数据类型生成相应的表单控件和动态列的表格

自定义Excel文件导入，解析Excel里的工作簿和列，自定义工作簿与表的映射关系，自定义Excel列与字段的映射关系，然后执行导入

自定义查询：支持条件查询 and ，or，括号；支持多表查询；支持分组；有部分功能还没完成大概思路是

指定要查询的表=》指定表间关联=》查询条件=》选择要查询的列=》选择要输出的查询结果（表格，图表）=》保存查询方案：

说实话我现在看到ExtJs的界面就想吐，不过ExtJs确实非常适合信息管理系统的界面开发，好在最近Extjs放出了一个新的皮肤挺好看的

4.1的版本中就会放出来

期待大家的讨论谢谢....

本文链接

Asp.Net大型项目实践(13)-尽可能的去掉项目中的大量XML配置文件

2011-03-21T08:01:00Z

在此系统的项目中我们采用NHibernate实现了ORM；采用Unity来实现了DI和AOP。这2个技术方案应该说都很不错。但随之而来的是，在较大规模系统中产生了大量的XML配置文件。
在我们的实际开发中发现编写和存在大量的XML配置文件有以下几点不利：

1.我们需要在XML中编写大量项目中的数据表名，数据库字段名，命名控件，类名等，但由于各种因素我们很难保证在XML的纯文本文件编辑器里键入的准确性。
往往一个字母或符号搞错，就会导致整个项目无法运行。就连“复制粘贴大法”有时候也难避免出错，且不说“复制粘贴大法”其实效率很低....,后来尝试做了
些自动生成工具，但因为有很多差异化，效果也不理想。

2.对于XML里的字符，维护检索比较困难。刚开始还好，做到后面你会发现随着项目进度的不断推进，项目中的XML已经变得非常庞大了。
想要从中准确的找到并正确修改一些东西已经成了一件很麻烦的事情，而且还会提心吊胆的怕改错了....

3.由于实际上线中的各种情况，XML文件实现不重新编译代码就能改变系统的想法其实不大现实....对于大多数系统更新我们往往还是要暂停系统重新编译整个项目

于是我们想到，不如把这些XML的相关配置都用代码实现，干掉这些难以编写和维护的XML文件！！

一.用Fluent代替NHibernate的XML配置和映射

在Asp.Net大型项目实践(4)-用NHibernate保存和查询我们的业务领域对象之实现基本的数据库访问（附源码）中我们采用XML文件来实现映射：

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
assembly="Infrastructure.Core" namespace="Demo.HIS.Infrastructure.Core">
<class name="Demo.HIS.Infrastructure.Core.Dictionary" table="INFRA_DICTIONARY" dynamic-insert="true" dynamic-update="true" where="IsDelete=0">
<id name="Id" column="DICTIONARY_ID" type="String">
<generator class="assigned"/>
</id>
<version name="Version" column="VERSION" unsaved-value="0"/>
<property name="Name" column="NAME" type="String"/>
<property name="Code" column="CODE" type="String"/>
<property name="InputCode1" column="INPUT_CODE1" type="String"/>
<property name="InputCode2" column="INPUT_CODE2" type="String"/>
<property name="InputCode3" column="INPUT_CODE3" type="String"/>
<property name="Index" column="INDEX_FIELD" type="Int32"/>
<property name="Description" column="DESCRIPTION" type="String"/>
<property name="CreateTime" column="CREATETIME" type="DateTime"/>
<property name="IsDelete" column="ISDELETE" type="Boolean"/>
<many-to-one name="Category" column="DICCATEGORY_ID" not-null="true" lazy="proxy" class="Demo.HIS.Infrastructure.Core.DicCategory" />
</class>
</hibernate-mapping>

现在我们改进用Fluent来实现映射：

1 namespace EVHIP.OMS.Repositories.Mapping
2 {
3 public class DicItemMap : InputItemMap<DicItem>
4 {
5 public DicItemMap()
6 {
7 Table("OMS_DIC_ITEM");
8 Id(t => t.Id, "DIC_ITEM_ID");
9 References(t => t.Category, "DIC_CATEGORYD_ID");
10 Map(t => t.Description, "DESCRIPTION");
11 Map(t => t.IndexField, "INDEX_FIELD");
12 Map(t => t.IsEnable, "IS_ENABLE");
13 }
14 }
15 }

注意代码中继承的这个类InputItemMap<DicItem>,用了Fluent附带的好处类的映射也可以根据类的继承关系进行继承:

1 namespace EVHIP.Support.BaseEntities.Mapping
2 {
3 public abstract class InputItemMap<T> : BaseEntityMap<T> where T : InputItem
4 {
5 public InputItemMap()
6 {
7 Map(t => t.Text, "TEXT");
8 Map(t => t.Code, "CODE");
9 Map(t => t.InputCode1, "INPUT_CODE1");
10 Map(t => t.InputCode2, "INPUT_CODE2");
11 Map(t => t.InputCode3, "INPUT_CODE3");
12 }
13 }
14 }

二.把Unity的DI和AOP配置写到代码里

在Asp.Net大型项目实践(6)-用Unity实现层与层之间的接口调用（附源码）中我们也是采用XML来配置接口和具体实现：

现在改为写到代码里：

1 #region Dictionary
2 container.RegisterType<IDicCategoryRepository, DicCategoryRepositoryImpl>();
3 container.RegisterType<IDicItemRepository, DicItemRepositoryImpl>();
4 container.RegisterType<IDicCategoryBiz, DicCategoryBizImpl>();
5 container.RegisterType<IDicItemBiz, DicItemBizImpl>();
6 container.RegisterType<IDictionaryManager, DictionaryManagerImpl>();
7 container.RegisterType<IDictionaryService, DictionaryServiceImpl>();
8 #endregion Dictionary
9
10 #region GeneralDept
11 container.RegisterType<IGeneralDeptRepository, GeneralDeptRepositoryImpl>();
12 container.RegisterType<IGeneralDeptBiz, GeneralDeptBizImpl>();
13 container.RegisterType<IGeneralDeptManager, GeneralDeptManagerImpl>();
14 container.RegisterType<IGeneralDeptService, GeneralDeptServiceImpl>();
15 #endregion GeneralDept

有了强类型的智能感知，不用复制粘贴了，也不怕字符敲错了......

项目里没有一大堆Xml配置文件都不好意思和别人打招呼的时代已经过去了....让我们一起来干掉无厘头的XML吧....

下篇预告：Asp.Net大型项目实践(14)-约定胜于配置：解决Asp.net中繁琐的UI层赋值代码

本文链接

Asp.Net大型项目实践(12)-商业项目上线报告

2011-03-19T08:00:00Z

从这个系列写到现在差不多，在这一年期间有不少同学都对此系列表示了关注。虽然一直没更新但我还是尽量抽空解答大家提出的问题。这一年时间我也没闲着，一直在对这个框架进行完善和更新。更重要的是进行了实际商业项目的实践，事实证明本系列提出的很多思路和技术还是能经得起实际项目检验的。

打算把这一年间对此系列的完善更新和实际项目操作中遇到的问题和心得和大家分享，具体项目是一个较为复杂的医院信息管理系统，有图有真相......

1.登录页面提供对相关支持客户端ActiveX的检查和下载

2.基础数据维护典型的CRUD

3.权限管理

4.挂号窗口 web通过Activex 实现套打，实现对本地医保读卡器操作支持全键盘快捷键操作

5.DevExpress报表控件实现报表设计器，打印，各种导出

6.复杂的交互界面

图就看到这里吧

未完待续.....

本文链接

Asp.Net大型项目实践(11)-基于MVC Action粒度的权限管理【续】【源码在这里】（在线demo，全部源码）

2010-01-25T00:44:00Z

接上篇Asp.Net大型项目实践(10)-基于MVC Action粒度的权限管理（在线demo，全部源码）在线Demo:地址：http://218.60.8.35:1234/服务器：网通端口：不要禁用1234端口应该就可以访问注意：连了数据库的，时间仓促肯定有漏洞，不要捣乱哈：）登录用户： 1.用户名：牛头人战士密码:000000 权限：有全部菜单页面，不能进行数据库的更改操作（不影响录入体验） 2.用户名：老虎MM 密码:000000 权限：少两个菜单页面，不能进行数据库的更改操作（不影响录入体验） 3.用户名：admin 密码不公开权限：所有权限注：以上的实现都是通过权限管理s配置出的哈，没有任何硬编码

Asp.Net大型项目实践(10)-基于MVC Action粒度的权限管理（在线demo，全部源码）

2010-01-21T22:50:00Z

权限管理是个老生常谈的功能，我看博客园也有不少“高手”写了相关的文章，但大多不是空谈理论，就是做的十分傻瓜和玩具差不多没有真正项目实用性。少数基于RBAC的看设计还可以，但半遮琵琶半遮面的，谈到关键实现就阳痿，生怕别人学到似的。权限管理是每个项目都要用到的，但一般想写好也有一定难度。所以不少人动不动就想做所谓“通用权限管理”，但基本我看都是雷声大雨点小。弦哥也写过所谓通用权限，什么基于RBAC，什么资源+操作=权限。搞来搞去灵活是灵活了，结果配置十分复杂在项目中使用并不理想，再加上“通用”二字，那就必须要独立于平台技术和项目，实现解耦，而权限是经常都需要访问的，所以数据传输，效率也成了大问题。而且通用权限的需求是非常多的，一般很难想全，我看园子里吉日大哥虽然技术不咋地，但征集权限需求这个路子还是对的，至少比有些人随便写个玩具就敢号称“通用权限”来的好些。BB了这么多，来说说我的权限管理吧，正如上面所说我基本放弃搞所谓通用权限了，在吉日大哥非常牛X非常通用的权限管理出来之前。我觉得针对不同项目特点写不同的权限管理功能还是目前比较可行办法。所以我的

博客园_传说中的弦哥

是谁动了程序员的尊严续-也谈谈软件开发团队的管理

是谁动了程序员的尊严？

Asp.Net大型项目实践系列第二季（三）莫人云亦云,莫走弯路!正确认识ExtJs4

Asp.Net大型项目实践系列第二季（二）Windows桌面的ExtJs4实现(含源码)

Asp.Net大型项目实践系列第二季（一）哥欲善其事，必先利其器...

Asp.net大型项目实践系列 第二季

Asp.Net大型项目实践(13)-尽可能的去掉项目中的大量XML配置文件

Asp.Net大型项目实践(12)-商业项目上线报告

Asp.Net大型项目实践(11)-基于MVC Action粒度的权限管理【续】【源码在这里】（在线demo，全部源码）

Asp.Net大型项目实践(10)-基于MVC Action粒度的权限管理（在线demo，全部源码）

Asp.net大型项目实践系列第二季