1号~15号技术

1、 WinOMeter(免费)软件 记录每天的软件生活
    记录的主要是鼠标每天的运行轨迹

2、 改良程序需要的11个技巧
    有很多理由都能说明为什么我们应该写出清晰、可读性好的程序。最重要的一点，程序你只写一次，但以后会无数次的阅读。当你第二天回头来看你的代码时，你就要开始阅读它了。当你把代码拿给其他人看时，他必须阅读你的代码。因此，在编写时多花一点时间，你会在阅读它时节省大量的时间。（--摘录首段的目的是为了借鉴他这种写作方式）


    让我们看一些基本的编程技巧：


   1. 尽量保持方法简短

   2. 永远永远不要把同一个变量用于多个不同的目的

   3. 使用自描述的变量名和方法名

   4. 尽可能的把变量定义在靠近使用它的地方

   5. 拒绝神秘数字

   6. 友好的对待你的语言

   7. 不要逆常规而行

   8. 警惕过早优化

   9. 积极重构测试过的程序

  10. 不要过度沉迷于技巧（主要谈到了设计模式的问题）

  11. 通过习例学习新知
对于第4点我就比较纠结一点了， 我的习惯是将所有的变量定义在类的最顶端
 
   其中个人体会比较深的有第2、3、4点
一个变量应该始终只为一个目的服务。通过使变量常量化(C++里的const， Java里的final)，使得编译器能够优化编译，而且使你的代码醒目表达这个变量是不能改变的，你的程序的可读性会变得更好。

   如果你认为描述性的名称并不是那么有价值，请对比一下n, ns, nsisd 和 numTeamMembers, seatCount, numSeatsInStadium。
   盖房子时，你可不希望把锤子放到别人的院子里。你希望把它们放的离手头越近越好。定义变量也是同样的道理。

int foo = 3;

int bar = 5;

// 一大段使用“bar”的代码，

// 但没用到“foo”

// ...


baz(foo);


这段代码可以简单的重构成


int bar = 5;

// 一大段使用“bar”的代码，

// 但没用到“foo”

// ...


int foo = 3;

baz(foo);


当你把变量的声明和第一次用到它的地方间隔太远时(距离超过一个屏幕)，这确实会成为一个问题。记住上下文关系会变得困难，你需要滚动屏幕去找哪来的这个变量。
  学习新语言是一种很有乐趣的事情，你能学到一种新的完成任务的途径。当一个对一种语言已经很专业的人去学习另一种语言时，会出现一种很大的负面效应。比如说你是一个Java开发者，试图去学习Ruby。你应该学会用Ruby的方式解决问题，而不是沿用Java的解决问题的思想。


3、 开发与研发的区别很大
    .开发
————苦闷的开发工程师
如果一个开发工程师对自己做的东西没有荣誉感和认同感，那么他坚守自己的岗位要么是因为公司给的钱多，要么是因为他还没有找到下家。

   我个人认为，做开发最大的一个好处就是可以亲手实现一个“自己的作品”，就算平时很累，但最后完成它的时候也还是会无比满足，这点被剥夺了之后，和饭店打工的服务员有什么两样？不一样是为了糊口吗？

————发展方向
我个人认为，国内的开发工程师大概有三个发展方向：1.做管理。 2. 去做架构等与产品关系不那么紧密的研发。3. 提升其它方面的能力，做 “A+ Player”，然后自己创业。
.为什么要关注代码之外的事情

   如果你只会埋头写代码，那么代码写得再好也可能不会是一个好的开发工程师。做开发不是做学术研究，你的任务不是去钻研技术，而是利用自己的技术把产品做出来。尽管技术能力是基础，但如果无法把能力很好地应用到开发当中，那么你在团队中就没什么价值。举个例子，如果你不能很好地理解产品需求，那么就会根据自己的理解去做技术方面的架构和编码，等到后来发现了再去修改就特别麻烦，这个时候技术能力强反而成了坏事，南辕北辙的故事我想大家都听说过。

  很多开发工程师属于那种“很本分”的人，从来不会提出意见，不关心产品形态和细节，只是去做产品经理提出的需求。我觉得别人把工程师叫做“代码民工”也就算了，但是工程师对自己做的东西完全没有看法，那就是甘心沦落为民工了。这也有文化的原因，国内的公司都喜欢那些不爱抱怨的员工，因为他们听话而且符合中国传统的价值观，但我更喜欢那些爱抱怨并且抱怨得有道理的人，因为国内（不只是互联网上面）粗制滥造的东西实在太他妈的多了，不抱怨才不正常，有不满才会去思考如何做得更好。

   曾经听到有人谈论如何管理技术人员的时候说：“管理技术人员很简单，找一个比他们都牛的人就行了。” 这个人很了解工程师的脾气。工程师去判断其他工程师的时候，往往只看他的技术能力，觉得谁的技术好谁就最牛，其它的都无所谓。没错，技术牛的工程师写的代码质量很高，但这只是一个方面而已，判断一个人在团队中是不是“很牛”要看他对团队对产品的整体贡献，而不是他的个人能力。他能很好地理解产品需求吗？能很好地理解设计师的意图吗？和团队其他成员沟通顺利吗？写出的代码方便测试吗？会对产品提出好的建议吗？……这些都是判断一个开发工程师的标准，整体素质越高在团队中的价值也就越大。

   所以要想做一个好的开发工程师，就要在写好代码的同时努力提高其它方面的能力。我知道大部分的工程师都喜欢和机器而不是和人打交道，所以遇到和产品经理、设计师以及 QA 等部门协调沟通的时候就皱眉头。协调沟通确实是一件闹心的事情，但从另一方面来说，这是开发工程师的一个得天独厚的优势：你可以深入接触产品生产线上的所有环节。需求评审的时候，你可以了解产品设计；开发界面的时候，你可以了解到视觉和交互设计；测试的时候，你可以了解到产品测试的细节；上线的时候，你也可以多观察 Ops 同事的操作。如果你可以在协调沟通的时候学会换位思考，多从对方的角度看问题，多想一下“他为什么要这么做”，那么不知不觉就会对各个领域有一些了解，进而发现原来每个领域都大有学问，就不会因为周围那些学艺不精的人而轻视他们所在的领域。

————学习设计
对于工程师来说，测试和上线都是技术性的工作，和开发有很多相通的地方，而产品设计、交互设计和视觉设计等设计领域则比较陌生。对于自己不了解的东西，我们的看法往往会趋于两个极端：要么是看得高深莫测，要么是看得一文不值。其实对于大部分的东西，只要不笨并且愿意下功夫学习，总是可以学会的。尽管达到大师的水平可能需要传说中的“天赋”，但做到中等水平并不是特别困难。关于设计领域我一直在断断续续地在学习，到现在可能连略窥门径也算不上，这里只是说一下我个人对设计的理解和心得，供大家参考。

————产品设计
产品设计看上去比较简单，因为只要清楚自己想要做什么，那么自然可以慢慢勾勒出产品的形态和功能。要做好产品设计，就需要平时多下一些功夫，多研究一下互联网上那些已有的产品，另外还需要多看一些诸如社会学、历史等“闲书”，举个例子，假如你想开发一款针对台湾用户的产品，那么了解一下台湾的文化肯定是有必要的。总之，学习产品设计是慢功夫，没有什么速成的捷径，只有一点一滴地不断积累才能培养出敏锐的产品意识和深刻的洞察力。

工程师学习产品设计有一个优势，那就是设计出来的产品是自己亲手实现的，你可以在实现的过程中不断重新反思原来的设计，然后加以修改和完善。这就好像写文章一样，很多时候你写东西的时候并不清楚自己具体要写什么，但只要是下笔开始写，写着写着就会发现新的想法，写作的过程同时也是思考的过程。写作和写代码很像，它们不仅可以表达想法，还可以创造想法。

————视觉设计
很多工程师听到视觉设计会立刻退避三舍，觉得自己“不会画画”、“不懂配色”是不可能学习视觉设计的。诚然，视觉设计是需要更多艺术方面的基本功，要完全掌握需要长期的训练，但我们还是可以从简单的学起，慢慢培养对设计的感觉。我个人在这方面所知非常有限，但是对视觉设计中的完美主义印象深刻。

编程的时候，如果你的某行代码多了一个空行可能不会有什么问题，但在视觉设计中差了 1 个像素或者 10% 的透明度就是不可容忍的，很多设计师要求的都是 “Pixel-Perfect”——像素级别的完美。如果你不苛刻地追求完美，几个这样的“小瑕疵”就可以把整个作品毁掉。在我没有接触过视觉设计的时候很难理解这一点，切页面的时候并不会特别仔细地去看设计图，而且为了降低技术难度会想当然地篡改设计师的意图，比如把一些微小的渐变用纯色代替，这是很无知的做法。所以当设计师要求你做一个 1px 的修改的时候，即使会花掉你几个小时的时间也要听他的——只有这样才可以把界面做到百分之一百的完美。当然，设计师自己做不到完美另当别论。

此外，作为一个页面设计师，从职位名称上来看他的最终作品应该是页面，而不只是视觉效果图。所以我觉得页面设计师应该精通 CSS，只有自己才可以精确实现自己的设计意图。对于那些没有受过设计训练的工程师来说，很难注意到页面上色彩、字体和渐变的细节，让他们精确实现一个设计师的意图几乎是不可能的。精通 CSS 对于页面设计师来说并不算一个过分的要求，很多国外的设计师甚至可以自己用 PHP 写出产品原型，相比之下，国内的页面设计师进化得实在太慢了。

-------交互设计
交互设计是有关行为的设计，它更关注如何让产品更好用。举个例子，网页中一般都有很多超链接，当你把鼠标移动到超链接上的时候，鼠标形状会变成手型，暗示它是可以点击的，而且访问过的超链接和普通超链接的颜色是不同的，这样就很好地引导了用户行为。

之前我一直把设计和“视觉设计”等同起来，但在深入了解了之后发现，对于互联网产品来说，交互设计要比视觉设计重要得多，而且交互设计相对于视觉设计也更加有迹可循，对“感觉”要求没那么高，工程师完全可以把重点放在交互设计上。如果交互设计做得好，视觉设计遵循一些标准，那么完全可以做出一款“不难看并且好用”的产品。没有人特别夸赞 Google 的产品“好看”，但它们都特别好用，Google 注重的是易用、快速，用户体验是很棒的。

互联网行业的大部分页面设计师（Web Designer）都是学习平面设计出身的，但我觉得网页和软件设计更像是“显示器里面的工业设计”。很多平面设计师设计出的页面很好看，好像海报一样，非常适合打印出来，但往往对交互方面重视不够。不太好看影响不会很大，但不好用就没有办法留住用户，而且有时候太注重外观的视觉效果反而会分散用户的注意力进而影响产品的使用，这种 “eye candy” 是糟糕的设计。现在专门培养交互设计师的机构不多，我很希望对互联网有兴趣的工业设计师们到这个行业中来。

关于设计我就说这么多，以后有机会再另外撰文专门探讨这些主题。值得一提的是，没有人可以真正把设计和开发全部精通，如果深入到细节，无论设计和开发都会占用你大量的时间和脑力。单从设计来说，需要掌握的就有颜色、字体排印（Typography）、排版(Layout)、交互设计等，其中每一种技能又涵盖无数细节，真的是要皓首穷经才可以在其中的某个领域成为大师。不过，即使你对这些知识只是有一个大致的了解，以后在看一款产品的时候也可以从功能、交互、排版、页面代码、整体性能以及URL语义化等各个方面进行全面而细致的分析，明白它哪里做得好，哪里做得不好，而不是在那里想当然地说“真酷” 或者“狗屎”。真正了解什么是好的什么是差的，自己做东西的时候才会心很多人可能会说：“一个人要是可以把所有事情都搞定，那还要其他人干嘛？我更相信团队的力量。” 没错，一个人就算从设计到开发都精通，如果只有他一个人做东西，开发效率也不会高。但是若你真的花心思去了解那些“与代码无关的事情”，你就会在写代码的时候更多考虑到产品经理/设计师的想法，对产品经理/设计师疏忽的地方也可以及时提醒，让自己真正地融入整个团队。目标并不一定要实现，它是用来指明方向的。开发工程师提高自己的产品意识和设计能力绝对不会是白费心血，不然的话你就只是一个实现产品的工具。你只会回答别人提出的问题，而好的问题要比好的答案有价值得多。

当你各方面能力提高得差不多的时候，应该就可以出来创业了（注意，我说的是创业，不是去创业公司打工）。因为对各个领域都有一定的了解，平时也经常接触到各个领域的人，那么在创业的时候你就很清楚自己需要什么样的产品经理/设计师，知道具有什么样能力的产品经理/设计师才是最好的，这样就可以从一开始就保证团队的质量和气质。很多互联网的业界前辈都说过“要招聘最好的人”，但问题是你如何判断一个人是不是该领域最好的呢？如果一个人对程序和设计一窍不通，满脑子都是商业运作，你觉得他有可能找出最好的工程师和设计师吗？有一次和一个创业公司的CEO聊天，他和我讲他们“只招聘 Geek”，后来我才发现他其实根本不知道什么是 Geek，只是不知道从那里听到 Geek 这个词，他真正想要的应该是那种只知道写代码愿意没日没夜任劳任怨给他当牛做马的人。国内大部分的创业公司就是这样，老大们喊着技术密集型的口号，实际上做着劳动密集型的事情，金玉其外，败絮其中。你可以和他们不一样。

我自己并没有创业的经历，也没有创业的打算，所以对创业的理解可能很片面而且天真。但是我相信，找到最好的人永远都是关键，不然即便后来成功了，也不过是多了一家靠人数取胜的血汗工厂。假如你选择成为移动互联网的独立开发者，对一个产品各个环节的全局把握也是有必要的。如果一个团队的每个人都能独当一面并且可以很好地理解其他人的意图和专业技能，就算最后在商业上失败了，那也会是一个幸福的团队，比那些除了盈利之外找不到任何亮点的团队好太多。


——————对产品经理的偏见

在“开发”这个小节的最后，我想多说一点自己对产品经理这个角色的看法。在国内绝大多数公司，开发工程师的作用就是把产品经理的想法以代码的方式写出来，“代码民工”这个称呼倒是很恰当。我对互联网行业的产品经理们一直感到很奇怪：他们没有能力把自己的想法实现出来，但是却几乎总是认为自己比其他人更理解产品；当工程师对产品提出自己的意见的时候，他们往往会心中不屑但尽量保持礼貌挤出微笑说一句：“呵呵，工程师不是普通用户”。一个产品本来就是需要很多人齐心协力一起完成的，产品经理和工程师的地位也是平等的，但是由于产品经理在工作流的上游，所以情况往往演变成工程师在为产品经理工作。如果产品经理真的对产品负责也就罢了，可惜的是大公司的产品经理大部分是对KPI负责，小公司的产品经理大部分是对老板的个人好恶负责，结果就是工程师跟在产品经理屁股后面做一些莫名其妙的事情。我接触到的几乎所有开发工程师都对他们的产品经理头疼不已，据他们说，好的产品经理就像真正的爱情，是极为稀有和可遇不可求的。

按照现在大部分公司的分工方式，产品经理是产品的总负责人。根据我个人的理解，产品经理之于产品，应该相当于导演之于电影，建筑师之于建筑。一个导演如果对拍摄一窍不通，那么就很难控制镜头的表现力；一个建筑师如果对建筑材料和结构一无所知，就不可能把握建筑整体的感觉。那为什么那么多人会觉得产品经理可以不懂技术不懂视觉设计，只需要写好文档画个框图然后交给别人去做就可以做出好的产品呢？本来是一个需要对各个领域融会贯通最难做得好的角色，现在反而被很多人视为清闲的差事，不爱干活的人纷纷想要转去做产品经理，实在是可悲至极。

我一直坚信好的工程师是不需要产品经理的。如果一个产品非要有一个什么产品经理的话，Google 的很多产品都不会出现，DropBox 这种只招聘工程师的公司也早就完蛋了。很多伟大的产品都是几个工程师想到一个点子然后慢慢做出来的，比如 Paypal 和 Google. 但需要说明的是，我讨厌产品经理并不是说我推崇“技术导向”——无论怎样产品都应该是让用户使用的，而不是用来炫耀技术的，只不过工程师不需要产品经理也可以设计好一个产品并且实现它。产品设计不是产品经理的专利。

想知道懂得设计的工程师没有产品经理的时候可以做出什么东西吗？去看一下 Livid 做的 V2EX 就知道了。在国内，设计和代码都有品味的网站可不多，我觉得 Livid 同学真是开发工程师的典范。

————————codeProject一类

4、 http://www.programmer.com.cn/4573/
    说服力很重要， 说服的一些手段：
数据、用户声音，都很有帮助。实在没有资源，就需要我们去描述使用场景，让其他人觉得自己就是现实的用户，进入到我们描述的使用场景里去，我们把这个说服的方式叫做讲故事。
    .产品定位
    .行业特征
    .用户是谁
    .用户特征
    .设计方案

5、 RedHat企业版推出了6.0版
    后生使用ubuntu的居多

6、 geek/ feedora/ 
    .E-Learning：Electronic Learning

7、 成为优秀的开发人员，可以没有数学技能，但成为卓越的开发人员，不能没有