网站总结

    最代码为了激励大家的分享热情，开始第一批牛币回购计划，已经给贡献前12名的用户发了私信，也是希望大家能更多的分享高质量的代码，带动更多的人一起参与网站的内容建设。希望大家理解和支持。

    最近google广告点击率非常低，也请大家在浏览最代码的时候关闭屏蔽广告的插件，时不时帮忙点击下广告以帮助我更有动力去完善最代码，给大家提供更多更好的服务，分享更多技术的思想，感谢大家一直以来的支持和关注。

    哪位有认识的朋友，同学，同事有网站pr高的可以和最代码交换友链的也可以帮忙推荐下，希望最代码2014年能更长足的发展。

资讯精选

可以让你尝鲜 Java 8 的 IDE

Java 8已于3月18日正式发布了，所有新特性最终确定了下来——Lambda表达式、简洁的配置文件、日期时间API、Stream等。（具体可参见：Java 8 正式发布，新特性全搜罗）

各大IDE开发商也紧跟着纷纷升级产品，以便能够跟Java 8同步。下面来看看你可以使用哪些IDE来体验Java 8。

1.  NetBeans 8.0

 

作为Java的同门兄弟，NetBeans 8.0跟JDK 8同时发布，在版本号上也与JDK保持一致，在JDK官方下载地址中也出现了“JDK 8 & NetBeans 8.0”的下载链接。

下面是NetBeans 8.0针对Java的一些改进：
 

• 改进了代码分析器和编辑器，以便更好地支持JDK8中的配置文件、Lambdas、Streams和方法引用等。
• 支持部署、运行、调试、配置嵌入式设备上的Java应用。
• 支持Java ME Embedded 8。
• 改善了Java编辑器，包括新的Java编程提示、Javadoc提示框显示、即时重命名等功能。
• 改善了与JavaFX Scene Builder的整合。

下载地址：https://netbeans.org/community/releases/80/

2.  Eclipse 4.4 build I20140318-0830
 

作为最多Java开发者使用的IDE，Eclipse也不敢怠慢，推出了Eclipse 4.4（代号Luna）I20140318-0830版本。

下面是Eclipse 4.4新版本针对Java的一些改进：
 

• Eclipse编译器已经实现了Java 8所有新的语言特性
• 搜索和重构功能现在支持Java 8
• 将Quick Assist和Clean Up的匿名类创建移植到lambda表达式
• 新的Lambda格式化器选项

下载地址：http://download.eclipse.org/eclipse/downloads/drops4/I20140318-0830/

3.  IntelliJ IDEA 13.1
 

IntelliJ IDEA堪称Java开发神器，受到大量Java开发者的青睐。Java 8正式发布后，JetBrains公司也立即推出了IntelliJ IDEA 13.1版本。

下面是IntelliJ IDEA 13.1版本针对Java的一些改进：
 

• 引入了Sublime的多选编辑功能
• 自动补全Java代码中的后缀代码
• 针对JDK8 Nashorn引擎的内置调试器
• Chronon调试器
• OpenShift调试器
• 改善了重度使用XML的Spring项目的性能
• 改进了版本控制
• 改善了对AngularJS和Spy-js的支持

下载地址：http://www.jetbrains.com/idea/

一位39岁程序员的困惑：知道得越多编程越慢怎么办？

Zilk1988 年 14 岁时就开始编程，此后尝试过几种职业，最终还是在 1997 年决定成为职业程序员（又称码农），现在已经 39 岁，对此选择依然无怨无悔。

但是后来他发现一个问题，自己的经验越丰富，完成项目或任务的时间反而越长。因为他见过了太多可能会出问题的情况而对选择踌躇。比方说，假设他刚想 到要写一段写入文件的代码时，电光火石之间他就已经开始担心起下面的一系列的问题：权限、锁定、并发、原子操作、迂回 / 框架，不同的文件系统、目录中的文件数、可预测的临时文件名、PRNG（伪随机数生成器）的随机性质量够不够、操作过程中断电怎么办、API 怎么写才好理解、文档应该怎么写等等。

简而言之，他的问题已经从“怎么做”变成了“怎么做最好 / 最安全”。

结果就是他他做出来的版本坚如磐石，但是也导致他完成项目的时间比菜鸟还要长。

Zilk 说，他自己精通算法、热爱数学，享受复杂项目，专注度也没有问题。也许经验是有问题（尽管已经 39 岁了），导致害怕犯错，使得项目费时。所以他在StackExchange上邀请同行帮助他解决这个问题。

下面就是精选出来的解决方案：

Telastyn：

你完成项目并不慢。以前你认为自己的菜鸟项目做完了但实际上并没有完。你应该把质量卖给客户。“公司可以做得更快成本更低，但项目真的完成了吗？或者说你愿意花几年的时间找 bug 吗？”此外，你还应该知道并接受那句老话：“完美是好的敌人。”

sevenseacat：

“好、快、省只能 3 选 2”。以前你懂得少所以牺牲了“好”，现在你懂得多了却牺牲了“快”。

mouviciel：

似乎你的经验的确不足:)。教训：遵守需求即可，不要想其他。这样才不会实现不需要的功能。

Satish:

应考虑敏捷方法论而不是瀑布流。先交付然后迭代交付。此举有助于降低风险和成本。

DXM:

似乎你加入黑暗面：管理的时候到了。

我不是要建议你放弃编程变身经理。但从你的描述来看你的经验仅限于技术层面。写文件这么简单的事情你居然能想到 10 个方面的问题，稚嫩一点的开发者绝对是想不出来的。这不是什么坏事，但是……

黑暗面的一切都与现值有关。它要考虑的是如何用最小的投入实现最大的产出（成本效益分析）。商业上的一切事情都要归结到成本、成功几率、失败几率、潜在回报等问题。做好这方面的数学然后采取相应行动。

哪怕你是开发者也无妨：忽略权限和命名冲突的情况下建个临时文件只需 5 分钟的时间。净收益：团队其他成员可以开始依赖此文件的代码编写工作。这是不是一个完美的解决方案？当然不是。99% 呢？95%？90%？这些可能性是存在的。

还要问你一个问题：你对技术债务（注：快速解决但会增长后续维护成本的做法）感觉如 何？有人认为不应该有技术债务。我不同意。跟商业一样，技术债务 让你可以借到“金钱”和“时间”以便晚点交付某样东西。2 年做出一个完美解决方案，或者用 4 个月时间快刀斩乱麻作出客户可以使用并且购买的东西，哪一个更好？判断当然要因情况而定，但是大多数情况下如果你要让客户等两年的话，客户可能早就跟竞争 对手签约了。

关键是像管理商业债务一样管理好你的技术债务。借的钱不够的话就拿不到最佳的投资回报。但是负债太高的话利息会把你压垮。

我的建议是用番茄工作法。专注于小的时间间隔（番茄），然后为未来的工作 / 研究分配这些时间段，并且在执行的过程中不断根据事情的优先级进行调整。

Saul:

编程的一个关键是管理并控制好复杂性，这是我的最高优先级之一。忽略了复杂性管理，要么缺陷频发，要么软件的 ETA（预计到达时间）急剧增加。

软件复杂性有很多不同的管理层次和办法，好的做法可以是这样的：“任何软件项目的最高优先都是客户满意度，这是客户期望的函数。”

换言之，软件复杂性取决于你控制客户期望的水平如何。

如果你接受这个观点，那么下面两点也很显然：

1. 客户期望必须明示

2. 客户期望永远都可以改变且通过协商完成。

你举了一个很好的例子，“直接写”还是“无数的其他考虑”。考虑一下，如果有人详尽写下了此二者的需求，双方的功能描述还是一样的吗？

同样是造飞机，F16 能飞，航模也能飞，但那能一样吗？

本来我打算把所有建议都摘录出来的，但是考虑到上述的精彩见解足以解决 Zilk 的困惑，并且为了践行这些建议，本文就此打住，感兴趣者可参见完整讨论。

最后我只补充一句：

你还可以看看麦当劳理论。

我是一个女程序员，有什么想问的吗？

跻身IT外包行业已有两年半的时间了，从走出大学校门踏入社会门槛的那刻起，便走进了另外一个世界-----IT世界。这个世界说大不大、说小不小。

      其实，做IT这个行业并不是我一开始的志愿，因为本身也并非计算机或相关专业，并且对这个行业的知识也不懂，但是那年的经济危机和各种原因吧，导致了我不 得不选择了这份工作。现在回想起当初毕业的时候放弃了最后的保送研究生的机会而选择工作。心里也不知是一种什么滋味，可能真的如人所说，打翻了五味瓶的滋 味，其中滋味，只有自己才能体会得到吧。但是并没有后悔当初的选择。

      起初在工作的时候，什么都不会，那叫一个痛苦啊，工作的环境压力也大。没工作几天就快要熬不下去了。但这毕竟是自己走入社会以来的第一份工作，总要坚持一 下吧，至少当时是那么想的。由于自己的技术功底并不好，各种技术也不懂，一切的一切都得重零开始。就这样一步一步的伴着眼泪和汗水坚持到了现在。

      在这两年的外包生涯中，感悟到一个道理，自己并不属于自己，有很多的思想也并不能实现。举个例子来说吧，给别人做外包，拿到手的项目是别人分析好的，方案 给你选定，尽管你觉得有不合理的地方，你有你的想法，但是也是无济于事，并不能得到别人的采纳。刚开始的时候，也许你还能提出你自己的观点，但结果是并不 会被用到。久而久之，即便有了想法，也不想说了。就这样，一天到晚，压抑着自己的情绪。用别人的思路控制着自己的身体去工作。时间长了，疲惫不堪。

      对于人事调动这方面就更是让人悲哀了。上几天就有这么个事情，让我感触颇深，内心也深受打击。我们属于A公司。是给B公司做外包。同时给B公司做外包的还 有C、D两家公司。我们项目小组中有这四家公司的成员共同组成。一起做项目还是挺开心的。年纪相仿，沟通方便，相处融洽。可是好景不长吧。刚成立的小组不 到一年的时间。B公司就开始有了一个新的政策。可能也是新官上任三把火的缘故吧。好嘛，这三把火不打紧，就烧到我们的头上了。B公司说要减少外包人员。裁 员比例必须达到一个数字。在这里就不透露了。反正不少吧。各个小组就开始确定淘汰的名单。我们小组比较惨淡啊，被调走的调走，被裁减的裁减，有些人更是受 不了这份调动而自动的辞职的。最后就剩下寥寥无几的那么三两个人了。看着很多人的离开。让我内心巨受打击。感觉这里也不是自己的长久之地。枉费我一片工作 的热情。这份热情是不是献错地儿了呢。不知道这种无缘由的打击还会有几次。

      我不能掌控其他人的思想，但是，我可以掌控我自己的思想和行动。我可以决定我自己的去或者是留。人总要开开心心的生活，无论生活和工作给了你多么大的压 力。你只把它们当成动力变好。如果被压得喘不过起来，不开心。那么人生在世也就没有什么值得追寻的了。突然想起了前几天看到的文章，感觉很是激励人。这里 分享给大家，希望大家的人生都能够快快乐乐、实现自己的梦想。

 

再烦，也别忘微笑；再急，也要注意语气； 

再苦，也别忘坚持；再累，也要爱自己。 

低调做人，你会一次比一次 稳健；高调做事，你会一次比一次优秀。 

成功的时候不要忘记过去；失败的时候不要忘记还有未来。 

有望得到的要努力，无望得到的不介意，则无论输赢姿态都会好看。

生活不是单行线，一条路走不通，你可以转弯。 

泪水和汗水的化学成分相似，但前者只能为你换来同情，后者却可以为你赢的成功。 

变老是人生的必修课，变成熟是选修课。 

以锻炼为本，学会健康；以修进为本，学会求知； 

以进德为本，学会做人；以适应为本，学会生存。 

人生四项基本原则：懂得选择，学会放弃，耐得住寂寞，经得起诱惑。 

当所有人都低调的时候，你可以高调，但不能跑调。 

学会忘记是生活的技术，学会微笑是生活的艺术。   

什么是好工作：一不影响生活作息，二不影响家庭团聚，三能养家糊口。 

懒惰像生锈一样，比操劳更消耗身体。 

让梦想成真的最好办法就是醒来。

哲人无忧，智者常乐。并不是因为所爱的一切他都拥有了，而是所拥有的一切他都爱。 

      曾几何时，我们都会随着时光的消逝而渐渐老去。但无论何时都应该保持一颗健康快乐的心。为了你自己和身边爱护疼惜你的人们。

关于程序员开发效率的悖论

程序员看起来应该都是一帮非常高产的人。

你总能看到他们在电脑桌前噼里啪啦的敲着键盘；他们焦急的等待会议结束，希望马上能回去编程。当被问起，他们总是说没有足够的时间编写出这些程序，需要立刻开始编码，这样才能及早完成。

看来，敲代码一定是最重要的事情了，不是吗？

如果一个普通水平的程序员每天能写出50行代码。一个5万行代码的程序将会需要1000人/天来开发。把5万行代码输入电脑里，一个程序员每天能录1000行，也就需要50人/天。

那么，剩下的950天这些程序员都在干什么？

在搞清楚这个问题前，让我们先看一些简单的资料。Capers Jones研 究了数万个软件项目，他通过比较其中的各种软件开发方法（RUP，极限编程，敏捷开发，瀑布开发等等）和各种编程语言，发现，一个程序员每月平均写出的代 码大概是325行到750行，比我们上面说到的每月1000行还要少。就算是程序员不是每天只写50行代码，但下面两点是清楚的。

 

• 开发方法的差异不能解释程序员代码生产量上的不平衡
• 使用的编程语言无关程序员代码生产量上的不平衡

实际情况是，只有很小一部分的程序员的时间是花在写代码上的。如果一个程序员的所有时间都在敲代码，那他一定是在尝试不同的代码组合，直到找到好用的代码组合。
 

更准确的说法是，找到看起来是符合需求的“代码组合”——如果测试人员或业务分析师不来告知说这些代码是有问题的。

这就是为什么在把手放到键盘上前喜欢先计划代码如何写的程序员会比其他程序员效率高的原因。事实上，不仅仅只有很少数的程序员在写代码前先计划，很多即使有多年编程经验的老程序员也不知道这个道理。一项持续40年的研究表明，程序员的开发效率并不会随阅历的增加而增加。（参考No Experience Required!）

多年的编程阅历并不是必然导致高开发效率

十分有趣的是，各种强调编码前先计划的软件开发方法论都已经存在很长时间了。比如Personal Software Process（PSP）创始人Watts Humphrey根据统计数据说：
 

引用

PSP能提高21.2%的生产效率和31.2%的质量水平

 

像这样优秀的实践方法有很多。总之，就像作家动笔前先要构思好文章的结构和内容一样，程序员在按动键盘前如果不先琢磨一阵，很可能发生的情况是他的开发效率不会很高。

迷路的程序员

好久没看书的热情，好久没有完整研究过一个技术，现在天天赶业务，希望自己做出来的东西是个精品，结果在某一天，部门卖给京东了。过年的时候，阿里 打了几个电话过来，我接了其中一个，发现自己好多问题答不好。相对地，另外一个同事，他做的一个文档系统非常坑爹，编辑后代码和图片老丢失，但是他找到了 一份更高薪水的工作。我和他之间存在一个非常大的区别：他的目标不是把业务做好，而是把技术能力提升上去，把没有尝试过的东西拿来用，甚至无视组长的要 求；而我关注的是业务体验，业务功能。在组内，他绩效是B，我绩效是A。但是面对试官,他可以说出N个高大上的技术方案，而我根本无法表达出自己在业务功 能上花费的心思。

第一结论：业务不重要。
这是我最直接的想法。一个人真的好难把一个业务从默默无闻变成纵所周知，很难清晰地展现在面试官面前。面试官基本不懂你做的业务。

第二结论：清楚自己的定位。
第一结论几近脑残。其实认真思考下自己所做的和自己所追求的，是自己错了。
我是个java工程师，实际上做连产品设计、界面构建的工作都做了。去到面试官的面前，业务对他毫无意义，他要的是你的技术，处理问题的思路。我大部分时 间在考虑怎么设计让客户体验更好，怎么调优小细节，还有维护工作，怎么可能得到面试官的欢心呢。并发，JVM调优，可用性，监控，缓存，分布式等等这些非 功能非业务的需求才是我需要考虑的事情。尽管说业务还没起来，不需要这么NB的架构，但是这才是我的工作，我的追求。一心做好业务，做所谓全能选手，才是 我的悲剧。即使业务做起来了，出名了，面试管最想知道的还是你的技术，那才是你的第一品牌。

第三结论：我必须马上继续写博客，写总结。不能停留在解决问题层面，而是需要提升认识问题的深度和广度。
记得由此面试官问我问我选这个技术做这个玩意，我回答说：旁边刚好有本书，就用它了。ORZ，多老实，多可爱。如果是我同事来回答，肯定是搬出N种类似的 技术，优劣对比，业务具体分析，balabala...~实际做得好不好面试官不管，也无从验证。尽管实际上大家都知道，只要熟悉一项具体技术，都能解决 好多问题，不需要太多的对比选型，做得差只是自己水平问题。选MINA还是NETTY，选THRIFT还是PROTOBUF，选HIBERNATE还是 MYBATIS，根本无关重要。博客和工作总结停了将近一年没写，因为自己把更多的时间放在了业务功能实现，遇到问题没有像以前那样系统的研究，而是 GOOGLE后马上简单解决。大半年下来，回头望去，业务功能是做得不错，已经推广到其他小组，但是技术没啥提升。我再次回想，为何当时我要来到这里？一 是薪水，二是技术。总想着来到这里，自然而然能学到大并发，大数据，现实再次告诉我太天真了，应该是我主动学会了，再根据具体业务往上套。现在沦为一个蹩 脚设计+CRUD码农，实在太可笑了。我熟悉JS面向对象没多大用，我熟悉基本的JAVA没多大用，别人上来都问我项目的架构设计和分布式计算了。。。

第四结论：成功产品的前期，必有用心的开发，但是技术往往不厉害。我的那个同事和组长一致认为微信后台架构就只是业界常用的套路，没有创新，不过如此。
做过业务的同学都知道，把一个业务功能做好，是花费巨大心思和时间的事情，期间各种小调整小变更，大调整大变更，甚至后面功能删掉,结果2/3的时间都花在支持业务变更，剩下1/3的时间够你来技术学习和创新吗？
我觉得业务和技术肯定会经历一个过程：
1.业务起步期，用最简单的架构最简单的技术去实现,尽可能的支持业务，这个阶段用户体验和业务功能最重要(JD初期用的.net,据说当初选型原因很简单，因为刚好身边有几个人会.net)；
2.业务发展期，访问量和数据量都上来了，接入层，逻辑层，数据层面临着压力，这时候使用业界成型技术框架就进入议程了，这个阶段技术的重要性就显现出来了；
3.业务爆发期，这个时候，业界的框架觉得不行了，就搞自己独立框架来支持自己特定业务吧(淘宝是代表，研发自己的框架)。
相信大部分的互联网业务都是在第一个阶段，许多人都像我一样重复着低级的码农工作，做着没有技术含量的活儿，没有高并发、海量数据处理的经验，只能似懂非懂地看一些文章。

 

为了生存，我的内心挣扎着。每当自己写完一个CRUD，心里就多了一份沉重的羞耻感和危机感，我感觉我在浪费自己的时间，重复劳动让我恐惧。我并不 是喜欢的技术的人，只是刚好喜欢钻研。我甚至对技术有些抗拒，技术体系太庞大了，而且有时候连某一项技术的一些小细节也很难搞懂。实际上，路很多，我可以 选择更换环境，让环境推动我去做真正的技术，我也可以调节时间，学习工作暂时用不上的技术，然后写写总结，吹吹水。

唠叨完，感觉清晰多了。这段时间研究下CSS3动画 +　JAVA concurrent包吧，有兴趣的同学可以关注我的博客, 更新速度会至少赶上09的DOTA视频，而且必须是精品。

最后，总结一句: 为了生存，技术比业务重要！

一个女程序员的心酸和无奈

说实话，真的累了。
　　拼命再拼命，努力再努力，和男人们一起摸爬滚打，熬夜加班到凌晨，身心疲惫。
　　偶尔被关心，也会装作坚强的一笑，连声说没事儿，程序界里无男女。
　　和项目经理暗战了几万回合，终于熬到了主管的地位。却要时时提防甚至镇压小字辈的程序员。
　　偶尔从一堆堆方案中抬头，看着软件园里并不晴朗的天空，会想，怎么自己就学理了呢?怎么就学会勾心斗角了呢?怎么就知道培养自己小集团了呢?
　　当初那个胖乎乎傻乎乎的小妞哪去了?那个写了个学生管理系统就大肆炫耀觉得天下无敌可以进微软IBM的小菜鸟怎么就消失了呢?
　　同学朋友都劝，转行吧。相亲的对象已经发了狠话再不约会就分手。我笑，这种狠话貌似已经听了很多边，已经麻木了。
　　越来越沉默，越来越冷静。
　　上周，人事大变动。研发部只有我和技术总监沉的住气，笑看风云突起。这次人事的大调，和技术有关，又和技术无关。自己都被自己的冷静吓到了。
　　团队里只有我一个女程序员，还有一个女UI还是项目经理的人。很多时候感到孤独，面试过很多女程序员，都毫无保留的直接推荐到老总那里，却都没有通过。这真的很让我郁闷。
　　很怀念菜鸟阶段的什么都不想，很怀念那种努力向上拼搏的状态。
　　入行3年，今年是第4个年头，工资翻了3翻，心态老了3倍。
　　出差去深圳，坐在从广州到深圳的大巴上，听着歌，舒服的睡了一觉。所有的人事，所有的机制，所有的东西都离我远去，仿佛从前的一切都回来了。
　　其实，我不是一个有大出息的人。
　　只是想找个人好好谈谈恋爱。
　　只是想安安稳稳的约会逛街吃饭。
　　最近这位男友也是个程序员。搞笑的是我们在一个园区。紧挨着2座楼。中午吃饭的时候，我的程序员男友不停的讲着他目前开发的项目。有时候我看着他那张吃饭都在不停说话的嘴，总是忍不住怀疑他是不是做销售的。
　　我的上一任男友是学哲学的。硕士。我报着珍惜大熊猫般的心情珍惜与这位哲学硕士的交往。不为别的，只为哲学这神圣2字。我的哲学硕士男友果然不负我的期望，教会了我很多人生的哲理。有时候我都会忍不住暗下决心，一定要写一个网站，把他愤青般的哲学话语都放进去。
　　当然，我们伟大的爱情之路还是依旧毁于加班和我一有时间就睡觉的懒惰。
　　27岁，不尴不尬的年龄。
　　写了一下午的方案，头昏脑胀的突然失控。我在办公室里大声的宣布，明年一定要结婚。立刻，办公室热些沸腾。下班被老总一顿猛训。老总是一个严肃不苟言笑的人。坚信威严的重要性。
　　整天如同绑上发条般，就快断了。
　　打电话给我的程序员男友，说，咱明年结婚吧。
　　我的程序员男友很稳健的说他明年的计划是坐上技术经理的位置。最快也要后年结婚，希望我能等他。
　　女人和男人果然不同。
　　晚上和朋友去必胜客，朋友说她男友的大学同学来了青岛。报社的编辑，说改天让我过过目。
　　这就是生活。这就是人生。我想。
　　人生，没有IF ELSE

IT，技术人员的不归路

    IT，曾是技术界最亮丽的一道风景线。
    IT，由令人眼花缭乱的界面输出，变幻莫测的后台技术，出神入化的网络联系构成。产生不过几十年，但已经彻底改变了整个世界，时至今日，几乎每一项技术，都离不开IT的支持。我们无法想象，如果没有了IT技术，我们今天会是什么样子？因此有人说，IT不是技术，是一个世界。
    没人可以否认IT造就的辉煌和IT时代曾经开创的高薪神话。在dot com时代，美国一个普通的程序员也有7万美圆的年薪，在中国也曾经有40万年薪的CCIE，那时还是90年代。
但IT人员背后的光环掩盖不了他们脸上的疲惫。2006年5月28日晚，年仅25岁的华为工程师胡新宇因长期加班劳累过度，在华为的实验室永远的倒了下去。引发了人们对IT企业和IT技术人员的种种反思。
    IT技术的特点一：用户只见结果，不见过程。IT人员之间喜欢吹：看我用的技术，最尖端的Hibernate结构！看我的证书，CCIE、JCIE、MCSD......！但这只是IT人员之间通行的语言，离开了IT还有几个人听得懂？用户不认这个。用户只看我花多少钱，实现了多少事，用户只看界面是否实用漂亮，不管你是用ASP、JSP或是JAVA；用户只知道网络通还是不通、快还是不快，不管你是用Policy Routing、MPLS还是最简单的Static Routing......简单点说，用户不会问甚至不会理解技术后边的艰辛，只会对IT的效果提出越来越多的要求。
    IT技术的特点二：技术更新换代速度太快。Windows95还未用熟，Windows SR2已经在公测，接着就是Windows98；刚刚用熟VB6，又要马上开始学.net；刚熟悉了CISCO IOS12，马上又出了13。其他IT技术也大致如此，有人戏称IT是半年一代产品，几乎每代产品都和上一代略有不同，或完全不一样。
    IT技术的特点三：技术消亡太快。95年的时候，如果你熟悉Novell网，必定能找到一份不错的工作；如果你懂配置IBM的TokenRing和NSA，也很吃香；而懂得将Powerbuilder的DataWindow搬上程序，必定很牛逼。而仅过几年，这些知识除了茶余饭后作为聊资，确实一点用都没有。IT企业在更替，随之而产生的技术也不断更替，你不知道哪个企业能活得更久，自然不会知道哪样技术会在白白地耗掉你今天的时间。
    IT技术的特点四：技术几乎没有延续性。没用过window2000的人直接用Windows XP会有困难吗？没写过VB的人学写.net会有困难吗？没配置过CISCO2501的人去学习CISCO7205会有困难吗？答案都是没有或很少。因此，IT的这项特性决定了IT这个行业的竞争比任何一个传统行业都激烈。
    IT技术的特点五：总在晚上工作。因为不能干扰白天企业的正常运作，因此IT工作通常要在晚上加班做。
    IT技术的这些特性，注定了IT技术人员要不停地奔忙付出，在学习、收获、放弃中轮回。
    IT企业同样的困难，企业要生存，就要以最高端的技术为保障。别说是技术人员，就算是老总自己，都要天天去思考企业的倒闭。今年，华为终于超过CISCO，成为网络公司国际专利申请最多的企业，而每一项专利的背后，必定是IT技术人员辛勤的血汗。
    IT企业对技术人员进行绩效评估，通常只有两个指标：工作技能和工作量。简单点说技能就是对目前的知识（不是过往的，过往的对你帮助不大）你懂多少，和你干了多少活。这些都是高强度的工作所构成的，不管你当前的技术有多高，经验有多深，只要你一个月不学或不干，你就严重落伍。
    在我认识的IT技术人员中，不论年纪高低，不论经验深浅，几乎没有一个不累的。管理人员安排了工作可以去休息，销售人员完成了指标也可以去玩，而IT技术人员，似乎只有不停的工作在等待他。
这就是现状。

关于工作效率的心得分享

这是去年11月底在小组里分享过的工作效率心得，在这里也跟大家分享一下工作“快”感哈哈。我相信大家应该都有过工作效率的些许烦恼。而这个效率啊 伴随我很长时间的痛苦。每每到PDI的时候领导必提效率有木有？自认为快是不算的，必须领导和客户方说了算，对于当年校招进来的毛驴，是一件泪崩漫长的提 升过程。整天琢磨如何快，多快的速度才算快，恨不得快到连参照物都变得动感模糊。时间是把杀猪刀，不仅催人老还得与它赛跑，经过这几年的自残式磨练，也早 该总结总结。

一、 懂得整理需求

效率是先把重要的事情优先排序来完成，好的整理习惯是可以提高效率的。当需求很多的时候是可以通过整理需求有条不紊的进行。只要了解哪些是重要和紧 急的事情，就能轻松的决定先处理什么。这个相当于是做项目管理的事情，要善于管理自己的工作。建议学习佐藤可士和的《整理术》。

例如：本周产品经理们提了很多需求：@#￥……&%……&%……

可这样做:

1、列出所有需求

ABCBBD

2、归纳类型

ABBBCD

3、了解份量

A（传输功能设计)：总办需求

BBB（图标类设计）: 迭代需求，排一起绘制

C（新增界面设计）: 迭代需求，需较多时间设计

D（功能宣传图）：迭代需求，版本发布的新功能宣传

4、明确期限

假如级别为High、Mid、Low…

A（传输功能设计)：总办需求—非常紧急（今天）—High

D（功能宣传图）：迭代需求，版本发布的新功能宣传—周三—Mid

C（新增界面设计）: 迭代需求，需较多时间设计—本周—Mid

BBB（图标类设计）: 迭代需求，需较多时间设计—本周—Low

需求从散到整，从大到小，从繁到简，从紧急到迭代这样去处理就会变得清晰可观。

二、要有探究需求真相的精神

可能很多人也曾拿到需求就马上画稿，孰不知是不断重来的经历。表面应付需求是无法解决问题的，要先了解用户或老板的核心诉求，找出诉求的背后真相， 才能够有合适的方案去解决，才能快刀斩乱麻。本质问题得到解决便不会有重复工作量而拖延了本来的交付期限。还有就是有一些需求根本不是需求，比如老板只是 随便几个建议。所以要思于前，行于后。

三、练好刀工才能游刃有余

技能的熟练会提升工作效率。就像切土豆丝，要切成厚薄、细条一致又要快，那是必须有一双好刀手。做图也一样，就像画图标，要好质量的呈现，你明确了所有要注意的细节，绘制的时候会非常快速准确的完成，一步到位。要使车子走得快，就得给轮子勤上油。

四、在高速重复工作中提取模版

模型套用会提升工作效率。在工作中一定会有很多重复式工作，比如标注规范和切图这样必不可少但却繁琐没营养的工作，可以提取模型工具去 套用快速完成。规范标注，可以根据同类窗口、内容统一规范而不要再差异设计和重复标注。切图可以利用软件工具输出，比如slicy或PS插件，这是要善于 把所有图标控件整理成库，规范好命名，便可一键批量切图。还有比如tips弹窗界面，根据目前所有情况，做典型1~2个模版，其他直接套用，之后可不再经过设计，开发根据模版直接实现。

五、学会聚焦与屏蔽

1）专心致志做事

2）屏蔽干扰消息

早上应该是比较难聚焦做事情的时间段，到办公室第一件事往往不是开始工作。比如没睡醒，各种早上新闻，查看昨天消息等。 工作时被很多信息干扰，群消息，邮件，微信，弹窗广告等，包括自己有事没事的逛微博、各路网站，很容易被外界风吹草动的影响而分心，一天班下来才发现其实 本应该上午就可以完成的工作，还得加班或干脆拖到明天。这都是懒惰病和拖延病，得治。所以要先学会屏蔽杂七八，然后全身心聚焦到工作的内容里，最后你会发 现提前完成了很多工作。聚焦利于把需求思考得深一些，把工作做得精细些，得出的加分项就是完成的质量随高。

六、多任务处理

能够有全神贯注的状态，也能够有“一心多用”的功能。这个要求比较高，我也好难描述。拿一个妇女做例子，她可以一边炒菜一边看管在旁边玩耍的孩子， 一边打电话给闺蜜聊去哪里逛街和去哪里美甲，所以女人是一心多用的高手，灵活性非常高。我也常是一心多用的处理我非常繁多且接踵而来的任务，不然总觉得时 间不够用，或者为了省下后面的事情做些自己想做的事，比如思考、总结，或不用加班。但是建议在做非常繁多、零碎又不需要深度思考的需求时可以使用这招。最 好不要持续这样高度紧张的一心多用，长期只会感觉越来越累，而且打乱节奏，所以要懂得变化各种技巧。

七、敏捷响应

紧急需求时，能够快速响应，敏捷处理。这个时候是最能影响客户方的感受。还有一些几乎每天都会有的临时小小需求和bug，只要是合理的，就去免讨论 部分，快速输出也是可以的。有一次解决的小需求从修改到输出给产品只花了28秒，帅呆了自己惊呆了客户，这就是在日常中慢慢积累的效率好评。

八、拍板与结论的必要性

1）需要一个有力决策的人

2）控制范围并迅速得出结论

一个有力决策的人可以提高工作效率。由于评审层级关系的复杂流程，需求确认要漫长时间是家常便饭，所以如果有机会碰到老大们都在一起，有些事情能抓 住时机沟通和拍定的机会就迅速做。但不一定老大拍板这个事情就一定是对的，有些复杂的事情安排在会议上拿出来大家讨论，但是一定要有靠谱结论，如果没有意 识的控制，没完没了的讨论就是低效率，要善于控制范围、节奏又能迅速总结的人，能提高解决问题的效率。

九、当自己的事情做

只有当作是自己的事情做，意愿才会更强，而且也会有一些自己的想法，想着这件事情是有自己的成绩在里面的，就会更有动力。换位思考，当作是锻炼的机会。

十、保持健康和清醒

健康的身体状态，健康的作息，健康的工作频率是效率的革命前提。关于清醒的办事用歌德的一句话：在今天和明天之间，有一段很长的时间，趁你还有精神的时候，学习迅速地办事。

总结：

效率是由综合因素影响的，但跟个人办事风格有很大关系。其实效率是可以量化，也可进阶式自我考察，比如接手一个界面风格设计从要花1个月，到半个 月、1周、两天就可以完成；码一周代码变成1天就可码完。这就能看到效率的有效提升。前两年长期搭档的几位即通产品经理，给我封了个快刀手称号，开发也说 我以快著称，才慢慢发现自己这方面的成长与进步。希望这点经验总结能够给新人带来帮助，终极祝福永不改稿永不加班！

    最近发起了最代码的推广活动，希望每个支持zuidaima的都可以帮忙推广下，活动地址：最代码推广活动，有你参与更牛币。
    最代码每周都很精彩，有你会更精彩，请访问http://www.zuidaima.com。欢迎转载分享该文章, 欢迎推荐给身边的小伙伴们
    欢迎关注最代码的官方微信账号zuidaima，最代码官方新浪微博：http://weibo.com/zuidaima,最代码官方腾讯微博：http://t.qq.com/zuidaima

    欢迎转载该文章并提供出处。

    淘宝店铺： http://www.zuidaima.com/taobao.htm
    博客地址：http://www.zuidaima.com/blog/1760355924921344.htm