有的时候 重写比改更快

看之前写的代码就像吃屎一样难。

其实，看别人写的代码，跟吃屎差不多。

就连自己几个月之前的代码也是一样的呀。真是醉了， 有的时候，看了半天也不知道为什么的时候，干脆就别看了，直接干掉吧。改成自己的风格。真是醉了，修改以前的代码，还不如自己的直接重写来的更快呢！

不是针对你，我是说在做的各位全他妈的是垃圾！

为什么当了十年的程序员还只是初级程序员？

昨天看到一篇文章，说一个干了十年的程序员还不如两年经验的程序员？

这是为什么呢？

一篇文章说到： 高级程序员 不是说看基本编程的书籍和写几万行代码就可以做到的！

高级程序员，不仅仅是靠天赋的，更重要的是后天的努力，没有人是天生就是天才的，那种人非常至少。大多数还都是普通人！

但是，什么人才能成为大神呢？

有钻研的精神的人？凡是都要问个为什么的人？ 对什么事情都感到好奇的人。最重要的是有毅力的人。

为什么做了10年，还不如两年的呢？

因为十年的时间完全浪费了。时间的时间里面，他没有研究过真正底层的代码。很多东西： git  svn Mysql 仅仅是为了应付工作的需要，并不愿意花时间来研究，古人云只是虚长几岁而已， 闻道有先后，术业有专攻。 我是喜欢自己的钻研的人。很多的时候，我并不是很喜欢问别人，当然 浏览器除外。我是 非常喜欢使谷哥的孩子。 浏览器是一项伟大的发明。不亚于四大发明。

我用Git快半年的了，昨天，我才突然的顿悟。原来，我也仅仅只是会用而已。根本从来没有考虑过，他是怎么实现的，怎么进行数据存储和维护的，很多事情，我根本就没有深入的思考过的！

其实很多的时候，我们缺少的是耐心。我们更多的时间是本 Bug 和需求占用了，真的用来钻研技术的时间，我觉的是10经验的孩子，未必有那个2年经验的人花的时间多！

就是这样。

Stay  Foolish, Stay hungry!

我们迷茫在问题当中 GeekHades

     有的时候，当我们解决问题的时候，我们不要着急去做，而是应该先弄明白，我的问题是什么？连问题都没有搞明白，就瞎鸡巴搞， 最后你肯定无法解决问题的。因为南辕北辙，你连方向都搞错了，你又如何解决问题呢？

    今天早上，同事的五项wifi 无法链接网络了，找我帮忙。当我看到 WiFi处显示小红叉，我很自以为是的说，这肯定是网络驱动有问题的。但是，我会想起昨天，重装系统的时候没有问题呀？今天，怎么就不行了？我也是很蛋疼的。于是，我花了大概一个小时的时间来找各种驱动，包括安装驱动精灵，但是还是不行。各种重启电脑，我至少重启了五次吧，哈哈，本来嘛，解决Windows 的三大法宝，重装软件，重启，重装系统。基本上就这三种老套路。哈哈。

  一个小时还没有解决呢？ 我很是不爽，再说别人也等的着急了。于是，我有重新定位问题的存在。这回搜索的关键字是，window  wifi 显示小红叉。

  然后，很快我解决了问题，真的是醉了。原来是我的方向错了，当你的方向对的时候，你才会找到你的方案！


GO  GO GO


解决问题之前，先要思考问题，要不然 怎么解决问题呢？ 
方向的问题，一定是要确定的，要不然没法做了。

遇到问题的时候，首先不要着急着找答案，你需要分析问题，问题可能出在什么地方。要不然，你一痛乱找，花了时间也解决不了问题的。 解决问题的方法，先分析问题存在的愿意，对症下药。当你的方向选择错误的时候，你是解决不了问题的！

这个世界就是在不断的寻找规律，当你找到适合自己的规律的时候，你就可以做很多的事情！

代码的感悟

感觉自己的代码的素养，比以前好多了。因为，现在看项目的时候，发现，项目里面的代码，需要优化的地方太多了，之前是没有这种感觉的，就是感觉，别人写的代码实在是烂透了，但是，如果我来修改的话，需要很多的时间和精力，但是，我并不是很愿意投入这么多的精力去做这件事情。

思考
思考代码
思考自己的代码

现在，有个问题，就是发现需要优化的代码。我老是想立马，就去做这件事情。但是，一旦做起来，时间过的好快。但是，一开始要做的事情，就忘记了。这样很不好。

学会开始
学会结束

技术的递归

现在的技术，发展的很快。

很多的时候，我们慢慢的就落后了，如果，自己不积极进取的话。很多的时候，你就会被拍在沙滩上~

GeekHades 如何测试？

作为开发者，自己写的代码，Bug 一定是少不了的。我们在估算开发周期的时候，似乎只是估算了，写代码的时间，完全没有把，产品原型，设计和测试的时间，估算进来！

真的是醉了，开发完之后，等了好几天，马上就要发包的，这个时候，测试开始测试，一堆的问题，bug,待优化的问题，再过几个小时就发包了。这种模式，真的是折磨我的意志呀。蛋疼呀。自己的代码，要对自己的代码要负责。

测试的时间，越延迟。后面的问题，就会越多，所以，写完之后，应该尽快的让测试，进行测试，因为，问题，发现的越早越好。

自己写完的代码，就像是++的女人。真的是懒得在看一眼。如果，不是有问题，我是不会回头看的。

代码的余量，代码简洁，每个人写代码的风格是不一样的。所以，代码的风格和代码洁癖，直接导致了，各种的问题！你想重写代码的冲动，但是，代价太大了！有点让人恐惧呀！

测试，以后写完一个功能，需要立马测试，但是，每个人的又都有自己的工作，导致了测试的问题，一直在延迟，一直拖延到最后。这里的问题，从产品到开发，都有问题。最烦的莫过于，照着微信开发，往往不会给你产品原型图。这个时候，作为程序员的我就要开发创造了，不仅仅要胜任，产品经理的角色，还要做一个设计者。还有开发。我真他妈的是天才。写完之后，还要测试，真的是FullStack. 牛逼呀，小伙子！

今天，就吐到这里吧，真的是醉了，以后的问题，还有很多呢。慢慢的解决吧，这也是自己慢慢成长的而一个过程。

给自己，留一个余量。 来思考自己的代码！

今天，又给自己完了一个坑！  妈的上来就写，没有仔细的思考，预览的需求，导致了，实现的方案有问题，现在只能，从新写了，2个小时的时间白费了！

建立自己的工具库！

自己的代码规范！

最好，别让别人碰自己的代码！

思考的时间！

程序员必读的书单

个人喜欢的书单，看过的感觉很不错的推荐给大家：

1  《Refactoring》  《重构》
     Martin 大神写的，需要一定的代码量

2  《大话设计模式》  程杰
    面向对象的经典书籍，如果，你想在面向对象的路上走下去，就不用高级语言，写面向过程的代码！在这里是你对面向对象有更深的认识，提高自己的设计思维，提高自己的代码质量！

3  《代码简洁之道》
    很不错的书，交给你怎么样写出最简洁的代码，避免代码重复，代码重复是万恶之源！

面向对象的开发

我们再开的过程中，总是会遇到各种各样的问题。我是非常懒得，不喜欢多写一行代码！这就要求我们，在写之前先思考，怎么写才是最简单的，怎么样写，代码量最少！

今天我需要完成，两个界面的内容：

这两个界面是很简单的，很多初级的程序员。

1  菜鸟级别

奥，原来这么简单呀，这个很简单，就是一个布局，然后里卖弄去一个一个的实现ImageView + TextView.

这样写不好！

2  高级一点的

使用 GridView 实现， 这样可以根据数据动态的处理！ 如果这里使员工饿了 GridView, 那我们就可以重用了！

3 面向对象

   开发原则就是 单一职责原则，

   一个Activity 对应一个单独的责任和能力！

   所以，显然这里是两个Acitvity. 但是，我不愿老是重复的东西，所以，我在实现了第一个Activity之后。再去写 第二个Acitivty 就是重复的写代码。 很多人会 讲 之前写好的Activity 复制一遍。 显然我并不能这么做的！ 我也很喜欢这么做呀！

于是，我就用第二个Activity 继承自第一个完成的Activity , 抽出几个特殊的方法，定义访问权限为 protected

4  在之后

  我现在的架构，不好！    最好的方案，是抽取出一个抽象类，然后让这两个Activity 继承。 以后在家的时候，直接集成！

Execution failed for task ':app:transformResourcesWithMergeJavaResForDevDebugAndroidTest'. > com.android.build.api.transform.TransformException: com.android.builder.packaging.DuplicateFileException: Duplicate files copied in APK META-INF/maven/

I use the Android studio 2.0 vesion to run porgram:

But have the question:

I search for long time, But have the right answer
you can get answer in the link:
https://code.google.com/p/android/issues/detail?id=192835

resolve way:

packagingOptions {
    
    exclude 'META-INF/maven/com.belerweb/pinyin4j/pom.properties'    exclude 'META-INF/maven/com.belerweb/pinyin4j/pom.xml'}

I think, Because the libs infomation. I find this quesiton by myself. Because I see this:

So I know. why take this question. In the Android sutdio 2.0 version. The gradle build the program, it will scan the libs, I know this. But know. it will by the pom.properties info will ckeckout pingyin4j.jar twice in the mevanCenter. So you must in the gradle
config this code: you must know in where!

packagingOptions {
    
    exclude 'META-INF/maven/com.belerweb/pinyin4j/pom.properties'    exclude 'META-INF/maven/com.belerweb/pinyin4j/pom.xml'}

You can use gradle build this question. But when I run the program. I meet the new question:

http://stackoverflow.com/questions/33967703/unable-to-instantiate-application-com-android-tools-fd-runtime-bootstrapapplicat

Now I don't know how to reslove the new question!

But I choise a bad way to reslove the question. 
I use the stable verion android studio 1.4.0

So it is resolve! So I know The question is about the Android studio 2.0 versoion! It is not stabley!









refence link:

1  https://code.google.com/p/android/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Type%20Status%20Owner%20Summary%20Stars&groupby=&sort=&id=192835


2  https://code.google.com/p/android/issues/detail?can=2&start=0&num=100&q=&colspec=ID%20Type%20Status%20Owner%20Summary%20Stars&groupby=&sort=&id=192835

3  http://stackoverflow.com/questions/25015539/gradle-android-optimize-packagingoptions


4  http://stackoverflow.com/questions/33967703/unable-to-instantiate-application-com-android-tools-fd-runtime-bootstrapapplicat

代码优化 之 方法的提取

刚刚写了一篇关于自己心声的博客，内心有点小激动和不平静，还有就是郁闷了。


早上在地铁上，想起自己的。前几天，瑞斌曾经问我一个问题，为什么那么喜欢将代码提取出来，重用的方法提取没什么，但是很多的方法 只用了一次！

至于一点，重用的方法需要提取是没有问题。我个人是不喜欢在一个方法里面写很多行的代码的。因为，很多时候，我们会看到自己的方法里，有的时候会超过100多行。而且这个方法里会有好几个功能，我觉的，这样很不好，我喜欢单一入口的编程。把代码关系紧密的就提取一个方法，我不在乎是否被重用了，有的人可能会说这样被人看代码就会很麻烦！其实，恰恰相反。 这样提取之后，代码更加的整洁，更容易阅读了，之前，你需要一行行的阅读代码，才能读懂这段代码的含义，现在你只需要看方法的名字就可以知道 这段代码的含义。如果说看方法名字，你还是不明白，那就改换方法名字了。这就是创作者的问题，没有起一个很好的名字，

我觉的作为一个一流的开发者，需要有自己的编程风格！

Android studio checkout from project have no subverion choise?

今天 打开Android studio 然后， 发现我的Subverion 崩掉了！找了半天也没有找到为什么？

google 竟然没有相关的信息，然后我就无奈了。 我想应该是 前几天，我在编写代码的时候，突然我的Android studio 卡死。再重启的时候，我的电脑就成这样了。

解决方案:
1  我发现 intellj 没有问题， 而且 打开别的项目也是同样的问题，

2 打开别的项目也是同样的问题，这我就蛋疼了！

3  没有办法， 我 只有重新安装Android studio ， 也许应该可以的。但是我只是走了一半，并没有完全搞定。

4 然后下面的请慎重： 先备份您的sdk,  之后在处理下面的流程：针对 Mac pro

238down voteaccepted

Execute these commands from the terminal rm -Rf /Applications/Android\ Studio.app rm -Rf ~/Library/Preferences/AndroidStudio* rm ~/Library/Preferences/com.google.android.studio.plist rm -Rf ~/Library/Application\ Support/AndroidStudio* rm -Rf ~/Library/Logs/AndroidStudio* rm -Rf ~/Library/Caches/AndroidStudio*

this  将会干掉你所有的 Android studio 目录下面的所有信息。所以，要慎重，我就是因为自己的没有考虑，将自己的SDK 给干掉了。这样干掉了Android studio 的缓存设置的信息！


5  简单，重装搞定~

就为的Subverion  svn 又回到了我的怀抱，真心的开心安逸！

Why deveploer is so late for me! 为什么我开发的速度这么慢？

Because the document!

因为，缺少一个可以制定规范的人，是的，不论是谁，但是应该有一种制度与规范存在的，如果没有，那么每个人都有自己的想法，我们的开发进度为什么这么慢？为什么我们总是喜欢习惯自己的事情，不愿意去做自己不熟悉的 事情，内心是惧怕的，但是 又不愿意做 无聊的事情，就是自己的经常在做的任事情！

不成规矩 不成方圆，  在一家公司不应该有两个老大，然而我们公司确实一堆，这是非常的不合理的！

我喜欢做 程序员 的这一点，不喜欢的公司，我可以随时的走，这是非常的任性的，我喜欢就在这里，不喜欢马上就走。

 1  当你的项目过多的时候，bug 和 交互 提出优化和问题的时候，必须加上前缀，就是指明是哪一个项目的，要不知道，成员改了半天，不知道自己的在做神马！

2    在就是： 后台觉的前台是傻逼， 前台觉得后台是傻逼！
   Android  IOS 作为前台， 和 后台进行交互的唯一的 依据就是 文档，但是 后台的进度非常的慢，以至于 文档经常的不写。是的，他们写完了功能，就好了。根本不会去告诉，前段已经做完了，就算是他们想告诉，恐怕也不知道该跟谁说的！感觉现在我们公司还是小作坊是的开发，没有自己的规范。没有的自己的 文化底蕴！  
   第一时间，维护文档是开发的关键，我们不可能有那么的时间去做交流，交流应该是开始的时候 尽量的交流完全。但是，完全只是一种理想的状态，开发的过程中也会遇到各种各样的问题，我们需要做的就是 交流优先于开发，因为大家的智慧是高于自己的智慧的，大多数的情况下，因为，我们也知道不怕神一样的对手，就怕猪一样的队友！

3 足够的时间 研究自己的产品需求，有的时候，我们可能会在开发的时候，发现产品的不足，应该及时的跟产品进行交流， 我们不能老是站在自己的角度考虑问题，应该考虑别人的感受，因为我是做的Android. 所以有的时候，应该考虑IOS 的感受， 今天 对于陈颖的问题，就是 我只在自己的 方面，没有考虑她得。 在就是自己是没有话语权的，没有话语权的时候 最好是闭嘴！

4 话语权问题。真的是很恶心的，因为公司只是信任，刚开始来的人，以后的人并不相信！ 这也是应该的！

5 开发的规范。
  自己的规范的文档！

  马上，我会写一篇 跟规范相关的文档的！
  是的，如果有的自己的规范的花，这样会有利于开发的进度！


以上就是这几天的感悟！

我思故我在。

有的时候我们的生活的节太快了。我们应该静下心来慢慢的思考自己现在做什么？做的什么样？怎么样才能做得更好呢？

程序员真的很穷吗？

前几天一位做市场的同事跑过来问，池老师，我有一位朋友，快30了，想转行写程序，您觉得有戏吗？我看了看满目疮痍的他说，如果是你就没戏。

30多岁转行做程序员当然可行，毕竟历史上存在一些大器晚成的案例，这些经过渲染和修饰的案例给在时间长河中苦苦挣扎的人们带来些许希望的火光，但那毕竟是火光，一阵风来过，也许就灭了。如果你真的热爱技术和编程，渴望通过自己的代码实现别人的想法，或自己的想法，为世界带来更美好的产品，那么任何时候学习编程都不晚，编程给你带来的好处绝不仅仅限于你的工作领域，关于这一点，你看看李笑来老师就可以了，有时候我觉得，他简直是个专业的程序员，兼产品经理。但是，如果你只是觉得程序员挣钱容易，那还是算了吧，因为程序员不轻松、不浪漫、不被人理解，也许，还很穷。

很多人羡慕程序员工作没几年就可以拿着看起来不错的薪水，但是，如果他们在未来的几年内技术水平没有突破性的提升，或者缺乏一点灵性和品味，那么可能在未来很长一段时间内，他们都会保持这个薪资水平，直到有一天，你不得不接受，比自己小五岁或十岁的程序员，也拿到了和自己一样薪酬。不是经常说程序员年薪百万吗？是啊，那是行业里的顶级程序员，他们为了让自己的水准达到这样的要求，经常要付出十年以上刻苦努力和练习，初春，寒冬，清晨，深夜，当你们去欧洲浪的时候，当你们去卡拉 OK 唱的时候，他们都在不停的 Practice，Practice……

大部分程序员看起来都很穷，即使是极为成功的程序员，如果你没有看到他的豪华座驾，你也会觉得对面这个带着眼镜玩手机的人是个屌丝。程序员对外在的东西鲜有追逐，鞋子、衣服，穿着舒服就够了，所以你会看到熟悉的格子衫，灰T恤，大裤衩，夹角凉鞋和永远的双肩背包，那个包，几乎是程序员的一切……偶尔见个红色耐克T恤，上书「Just do it」，抬头一看，哦，原来是罗老师。

不过，你们一定不要被程序员们的表象迷惑，他们有时候消费起来非常可怕，下死手，与宅女逛街相比毫不逊色。大部分程序员虽然对衣服不感兴趣，但是对电子设备往往缺乏免疫力，女生会花掉2万元换来一个 LV 包，程序员会花掉2万元买一台配备了 Retina 5K 显示屏的 iMac，然后双方都认为对方疯了。

事情一般是这样的，你工作了两年，写了很多代码，伴随的是没日没夜的加班，产品上线了，产品下线了，团队出发了，团队解散了，然后你会感到疲惫，生活没有希望，这样的日子什么时候是个头啊！你看了看破旧的 ThinkPad，对自己说，要不要买个 Mac 试试？然后你就有了一个 Mac，你突然发现了一个新世界，充满阳光和雨露，原来操作系统可以设计成这样……于是你觉得每过一段时间就需要阳光和雨露。你开始购买正版软件，不管多贵。你开始学习移动开发，你发现你需要两部手机，因为 iOS 和 Android 平台都值得学习。于是你有了一部 iPhone 和一部 Smartisan T1，后来你又有了 iPad 和 Kindle，然后很多硬件和软件都升级了，你有了好几台 Mac，移动的，台式的，好几部手机、平板和电子阅读器，一代的，二代的，好几代的。你的女朋友很迷惑（如果你已经有了女朋友），她会问，你买那么多手机、电脑和其他乱七八糟的东西干嘛？不都一样用嘛。你觉得很难解释，就说：你看这个新款有指纹识别功能，还有这个，从这边划入，就可以进行分屏操作……然后你的女朋友白了你一眼，默默的用你的信用卡刷了一个 LV 的包。

事情还没有结束，Google Glasses 走了，Kinect Box 来了，Oculus VR 还在路上，无人机已经飞起来了。「嗯，听说喷气背包能让人飞起来？要不要试试」，「我身体不好，去跑步了」。跑步应该需要一套好的装备才不会受伤，于是你把自己装配的比专业马拉松选手还酷，另外，你似乎还需要一块 Apple Watch。如果这个最初玩 Mac 的程序员———你，竟然鬼使神差迷上了单反，那将是一场更大的灾难，据说一个徕卡相机要8万多元，镜头就不要再提起……

需求是没有止境的，就像产品经理的需求一样。程序员们虽然挣得不少，但他们花的也多啊。所以，他们还是很穷，至少是看起来很穷……

另外，程序员在心理上也很「穷」，大部分情况下，与行业内其他角色相比，程序员地位都不是最高的，待遇不是最好的，连加班都不是最多的。最惨的情况是：哦，程序员只是我们实现想法的工具！程序员很少一战成名，当年百度贴吧风头最劲的时候，人们只知道这个互联网产品是一个叫做李明远的年轻人做的，没人知道前端工程师是谁，后端架构师是谁，即使你通过一己之力完成的技术架构抗住了每天数以亿计的流量，那又怎么样呢，没有用户知道嘛。什么时候会知道呢？当你去极客邦的 QCon 技术大会上讲「构建高并发系统之百度贴吧实战」的时候，大家才会知道，喔，原来也有你一份功劳呀，然后转身就去找李明远签名去了。

程序员比较烦的是半瓶子醋的技术领导，或自以为懂了点技术的产品经理。关于商业模式，关于产品，关于用户体验，每个人都可以头头是道的说两句，比如我曾经看到无数的用户要为锤子手机、App、云服务、官网、电商提各种建议，还有一些创业失败的年轻人觉得锤科最大的问题是战略和商业模式，愿意免费为老罗提供战略咨询，等等。这都可以理解，但是谈到技术，懂就是懂，不懂就是不懂，界线是很明显的。

有些产品经理与技术人员打交道多年，多少也了解了一些技术架构和实现思路，这时候与程序员们聊天就要非常小心了。如果你顺嘴溜达出一些开源技术和架构名词，程序员们就会围上来笑嘻嘻的说「哇，你很懂技术嘛」，这时你要赶紧装作一脸无知的样子说「我懂个屁啊，也就知道个概念，我特么连 Hello World 都不会写」，然后程序员们就会放下手里的板砖，安心去编程了。

和程序员交流的正确方式是什么？当一个程序遇到瓶颈的时候，大部分程序员会非常无辜的说，现在就是最好的解决方案，没有其他办法了。这时候别着急，拍拍他的肩膀温和地说，没事儿，你再想想，肯定有更好的解决办法。如果你本身就是做技术的，也可以提供一些实现思路供他参考。一般情况下。过一阵他就会喜滋滋的告诉你，I have a better idea！

选择了一个程序员，就去相信他！

最后，程序员们还会相互鄙视。文人相轻，程序员似乎也是如此。写汇编的鄙视写 C 的，写 C 的鄙视写 C++的，C++程序员鄙视 Java 和 C#，Java 和 C# 程序员相互鄙视，写 Python 的和写 Ruby 相互鄙视，写 Scala、JRuby、Clojure 的一起鄙视 Java 程序员。写静态语言的和写动态语言的相互鄙视，写前端的和写后端的相互鄙视，Vim 程序员和 Emacs 程序员相互鄙视，然后一起鄙视使用 IDE 的程序员。

Go 语言程序员鄙视所有其他语言的程序员，所有其他语言的程序员都鄙视 PHP 程序员。PHP 程序员说，PHP 是世界上最好的编程语言，因为 Facebook 的扎克伯格也这么说的。

总是，程序员之间的鄙视链极其复杂，估计得用一个狗屁混沌理论才能描述出来，这能怪谁呢？只能怪我们自己了，谁让那些技术先贤们发明了这么多语言和技术框架却没有制定出一个美国宪法那样的规章制度呢？毫无疑问，这个鄙视链会继续持续下去，直到程序员这个职业消失的那一天。

程序员穷，累，苦逼，加班，可能还不被理解，公司领导甚至不知道你是干嘛的，一个正常人成为伟大程序员的几率估计比飞机失事也高不了多少，那么，为什么还有这么多年轻人前赴后继加入这个群体呢？我想，是这个时代把程序员们推上了风口浪尖，当你看到自己的代码奔跑在成千上玩台服务器上的时候，当你做的 App 运行在每个人的手机上的时候，你会觉得，一切都是值得的。

我是一个程序员，我喜欢这个职业！

写了这么多，我想知道，你还想当程序员吗？

野生程序员, 应该专精

野生程序员是指仅凭对计算机开发的兴趣进入这个行业，从前端到后台一手包揽，但各方面能力都不精通的人。野生程序员有很强大的单兵作战能力，但是在编入“正规军”之后，可能会不适应新的做事方法。



遭遇“野生程序员”

腾讯公司内部的团队很多，在团队管理上有项目和专业两个维度。也就是说，有些团队是项目维度的，整个团队共同维护一个产品，成员来自不同的职业岗位；有些团队是专业维度的，比如一个组都是前端工程师，维护不同的产品。

因为前端组是设计部最接近后台技术的团队，所以团队平时的工作和技术交流分享，都不局限于前端技术领域，还包括很多服务器端或者移动端的技术。从前端到后端，一些技术问题都要我们自己来解决。

在招聘前端工程师的时候，我们对应聘者的要求是，在掌握基本前端技术的前提下，最好有更为全面的技术。这样，即使我们的项目人力结构、平台和方向发 生变化的时候，他也能够更加灵活地转移到其他角色中。而且技术的全面更能表现一个人对技术的热情以及较强的学习能力。从团队多样性来讲，多一些技术种类的 话，大家在一起也能碰撞出新的火花。

有一次，我在QQ群发布了一条简单的信息：“招聘前端工程师，全栈更佳。”随后有一个“全栈工程师”A君向我自荐。

我仔细看了他的简历：“三年工作经验，擅长PHP、MySQL数据库、jQuery、HTML和CSS，对CDN加速和网络安全也颇有研究。”他的简历让我眼前一亮，于是我跟他进行了一次简单的电话面试。

电话面试的第一个环节照例是让A君简短地介绍自己。A君在一个传统行业的小公司做IT技术支持工作，公司的3个网站项目都是他一手搭建，从架构到编 码细节他都如数家珍。他号称能解决一切技术问题，老板提出的所有需求都能完成，而且只有他能完成。随着最近公司业务量越来越大，他还招了两个下属，但是主 要的编程工作还是他在做。

我问他：“我们的职位是前端工程师，那么您有哪些前端方面的技能呢？”他回答：“我擅长HTML、CSS和JavaScript。”

“对于Web性能优化，您有哪些了解和经验吗？”他思索了一阵答道：“我们在发布项目之前压缩CSS和JavaScript源代码，这样文件体积就变小了，用户加载必要资源所花的时间也就更短了。”我继续说道，很好，还有吗？他想了半天，答不上来了。

其实关于Web性能优化，有非常多的方面可以去做，我希望应聘者能尽量多回答一些。

压缩源码和图片
JavaScript文件源代码可以采用混淆压缩的方式，CSS文件源代码进行普通压缩，JPG图片可以根据具体质量来压缩为50%到70%，PNG可以使用一些开源压缩软件来压缩，比如24色变成8色、去掉一些PNG格式信息等。
选择合适的图片格式
如果图片颜色数较多就使用JPG格式，如果图片颜色数较少就使用PNG格式，如果能够通过服务器端判断浏览器支持WebP，那么就使用WebP格式和SVG格式。
合并静态资源
包括CSS、JavaScript和小图片，减少HTTP请求。
开启服务器端的Gzip压缩
这对文本资源非常有效，对图片资源则没那么大的压缩比率。
使用CDN
或者一些公开库使用第三方提供的静态资源地址（比如jQuery、normalize.css）。一方面增加并发下载量，另一方面能够和其他网站共享缓存。
延长静态资源缓存时间
这样，频繁访问网站的访客就能够更快地访问。不过，这里要通过修改文件名的方式，确保在资源更新的时候，用户会拉取到最新的内容。
把CSS放在页面头部，把JavaScript放在页面底部
这样就不会阻塞页面渲染，让页面出现长时间的空白。
每一个条目都可以进一步深层挖掘下去。
Web性能优化分为服务器端和浏览器端两个方面。
Web性能优化分为服务器端和浏览器端两个方面。
Web性能优化分为服务器端和浏览器端两个方面。
此外，由于中文的歧义性，Web性能优化这个词既可以解读成页面加载速度（Page Speed）的优化，也可以解读成页面渲染性能（Page Performance）的优化。或者是二者的集合。所以，应聘者如果能在这个问题上多做一些分析，会有很高的加分。但是A君在网络性能方面的研究只是浅 尝辄止，停留在压缩资源方面，这说明他还没有足够理解HTTP协议本身。
关于网络性能和HTTP协议，作为大公司的前端工程师是非常看重的，因为每一个页面都会有亿万用户访问量，任何一点对服务器带宽压力都会积少成多，最终造成很大的成本。关于这方面的技术详解，我在后面会有一篇单独的文章来分析。
接着上面的故事，我想既然他对Web性能优化方面不太熟悉，可能他是一个偏后台的程序员，因而就又问道：“关于服务器端MVC架构的技术实现，您是怎样理解的？”他说：“是数据模型、视图、控制器的分离。”

我更进一步问道：“这种架构方式有什么好处？您在项目中是如何应用这一架构的？”他回答说：“MVC的架构方式会让项目可维护性更高，所有涉及界面 的代码都在视图（View）里面，所有涉及核心逻辑的代码都在模型（Model）里面，URL路由之类的代码都在控制器（Controller）里面。我 在项目中使用了MVC架构的PHP框架——CodeIgniter。”

我一边打开他的网站，一边继续跟他电话沟通。当看到网站的CSS代码都直接内嵌在HTML头部的时候，我忍不住问他：“为什么您的网站的CSS代码 都内嵌在HTML里面呢，是使用自动化工具合并进去的吗？”他支支吾吾地说：“因为在本地调试的时候，CSS文件修改经常不生效，所以就直接在HTML里 面改了，这样比较快。”

好吧，我想这是一个典型的“知易行难”的开发者，他知道采用MVC架构的项目的可维护性更高，可是在分离样式与结构上面还没有达到最基本的要求，甚 至把CSS写在HTML中。至于他说的在本地环境上发现CSS文件经常缓存，可能要看看本地服务器的缓存设置是否有问题，然后再做调试。稍微了解一点 HTTP的浏览器端缓存，这就不是难事了。我更欣赏在开发流程上花工夫去理解和优化的应聘者，而不是马马虎虎，只是以完成需求为目标的人。

我突然想到他说的“所有需求他都能完成，且只有他能完成”，于是就想问问他代码版本管理方面的问题。我说：“您们团队现在加入了两个新人，那么您们 如何进行代码版本管理？”他回答：“我们有一台测试服务器，用FTP来测试代码，如果在测试机上没有问题的话，我们就会发布到生产环境。”

我说：“等等，我不是问您们代码部署的问题，是平时您们如何管理代码版本，如何分工协作的？”他说：“我们把代码从测试服务器上拷下来，修改完了之后再传上去。”

到这里，我终于明白为什么他们团队的新人无法快速融入项目了，因为项目没有使用SVN或者Git这样的版本管理工具。团队只有一个人在写代码的时 候，缺乏版本管理工具的问题可能还不会暴露出来，但是当更多成员加入时，整个项目就会寸步难行，大家都要花大量的时间合并代码，以及找回丢失的代码。万一 出现了外网bug，版本工具也能帮我们把站点状态快速恢复到之前的时间点。在本书的后面章节，我会详细介绍版本管理工具。

最后我抱着几乎绝望的心情，问了下关系数据库设计原则方面的问题，他的回答也不是很理想。

我知道，我又遭遇了“野生程序员”。

什么是“野生程序员”

所谓“野生程序员”，就是没有计算机基础知识和相关教育经历，靠着对计算机开发的兴趣进入这个行业，虽然知识面比较广，但是各方面都一知半解的开发者。

这几年我从一个求职者，转变成一个招聘者，有一个感受就是，中国高等教育与市场需求不接轨。学校不了解市场究竟需要什么样的人才，其设立的课程和技 术往往比市场技术现状落后了5年以上。我在大学学习用ASP建站，但是现在已经几乎没有人用ASP建站了。一个直接的后果是，很多高校毕业生不能满足企业 的要求。

与此同时，中国互联网市场蓬勃发展，特别是移动互联网的发力，让中国跳过“WAP时代”，直接进入“App时代”。市场的热钱都投入到互联网行 业，“BAT”等大公司不断扩张，创业公司也如雨后春笋，整个市场对软件工程师的需求缺口巨大，所以很多公司在招人的时候，没法招聘到“专业”的计算机专 业毕业生。

在美国，因为教育与市场稳定发展了很多年，供求关系相对平衡，计算机相关专业本科已经成为基本要求。举例而言，美国的硅谷公司（如Google）绝大部分前端开发招聘岗位都有一个最低要求——本科学历，计算机相关专业。

相比而言，从中国的大公司（如腾讯）的招聘网站上可以看出，有一些前端开发岗位没有对学历的要求，也有一些要求“本科及以上学历”，少数才会要求 “本科学历，计算机相关专业”。我们的团队中就有一些成员是大专学历。许多企业在招聘的时候往往放松了对学历的要求，只看重项目和经验，而不看重学历。这 是一件好事，代表市场在高等教育的规模和质量都跟不上市场要求的情况下，给予更多有兴趣和能力的年轻人进入IT领域的机会，也填补了人才市场的空缺。

美国硅谷，是世界互联网公司的中心，是所有求职者梦寐以求的圣地。在最开始，硅谷之所以名字当中有一个“硅”字，是因为当地企业多数是从事加工制造 高浓度硅的半导体行业和电脑工业。随后，互联网公司和软件公司渐渐取代传统的硬件公司，让硅谷获得了新的生命，但硅谷这个名字保留了下来。在硅谷从诞生到 发展壮大的整个生命周期中，斯坦福大学起到了很大的作用，我认为称之为硅谷的母亲也不为过。

在中国，由于政策、环境、历史原因，还有大学教育投入上的差异，导致大学在整个互联网发展中起的作用没那么大。中美两国IT人才市场供求关系上的这些差别，也反映在整个行业文化中。

一个直观的反映就是软件工程师的“草根”化。其实很多软件工程师的收入都很高，处于中上层水平，相比金融行业的白领也毫不逊色，但是一谈起程序员， 大家的印象还是“一年四季的T恤（在行业展会上免费拿的）牛仔裤，平时也喜欢宅在家里，不会像同样收入的金融白领，平时爱好听歌剧打高尔夫球”。这种差异 一方面是外部人士对软件工程师职业的偏见，另一方面也是程序员行业的自黑习惯。在招聘时岗位要求就已经放到最低：不要求学历、上班不要求着装、上下班时间 灵活，这样才好更方便地招聘。而金融行业有意识地塑造一种“精英”文化，从学历就设置高门槛，即使有些工作根本不需要那么高的学历。

回到毕业生的话题，很多跨专业的学生发现自己兴趣在互联网和计算机方向的时候，就开始了自学之路，基本上学习方式有这样几种。

书：在计算机图书领域，技术难度跟图书销量是成反比的，从标签教起的HTML/CSS基础书籍卖得最好，其次是关于JavaScript和jQuery的书，Angular和Node.js之类的就没那么畅销了。
互联网：得益于全世界都在互联网上共享的资源，现在的学习者有了更多的选择，比如关于Web开发基础教学的W3CSchool，还有海量的技术博客。我个人喜欢订阅一些英文大站，比如Smashing Magazine、tuts+等。我在读大学的时候，Google Reader还没有永久关闭，那时候我很喜欢用RSS来关注这些站点的更新情况。Google Reader下线后，就基本上废弃了RSS阅读的习惯，转而用一些社交网站来追踪更新情况，但是有时还是会淹没在大量无用的信息里面。
社团：学校的网站社团也孕育了许多能力很强的开发者，社团经过历届的传帮带，技术有所积累，比如师兄会教师弟用Sublime编辑器，这就比还在用 Dreamweaver的同学更有优势。此外，学校社团有一些定点客户，比如学校教务处、周边商户，所以有更多的实战经验，在毕业时作品集也丰富了不少。
因为有这样一些自学渠道，所以不一定只有计算机专业毕业的学生才有机会进入互联网行业。毕业之后，这些计算机爱好者进入不同的工作岗位，不同的是，有些进入大公司，有些进入小公司。这两者的成长轨迹往往会不太一样。

小公司有很多野生程序员

流水线工作流程有诸多优点，但一般来说，大公司才需要很多专精某种技术的工程师，组成一个Web开发团队。创业公司只需要几个技术全面的人来做开发和技术支持，有时候甚至只有一两个人而已。

当然，最主要的原因就是成本和回报的问题。招聘和维持庞大的IT研发团队需要一笔不小的开支，小公司并没有那么多Web服务的需求，一般企业可能只 需要一个公司站点就可以了，现在甚至完全不需要Web站点，可以用微信公共账号或者淘宝这样的大平台来完成。如果招聘一个完整的Web研发团队，从用户研 究到交互设计、从App开发到数据库管理，直接后果就是整个团队大部分时间都空闲着，无事可做。与之相比，聘请一个或多个全栈工程师会更高效、更省钱。

第二个原因是，很多传统线下公司并不会特别依赖IT技术，有些时候线下渠道占据了公司大部分收入来源，所以公司不需要架设十分完善的线上服务。由于 线上服务的用户量少，所以Web服务对稳定性、承受压力、用户体验的要求都没有那么高。此外，由于没有太多重要的用户数据，所以异地容灾也不需要。

因为公司的开发团队小，所以网站无论出现什么问题，都需要他们去解决。从域名到服务器，从前端到后台，从设计到内容，都是一人包揽。野生程序员了解 的知识越来越多，但是样样都不精通。我认识几个小公司的程序员，他们没有明确的职称，开发者都统称为程序员，设计师都统称为美工。

在Web技术的任何方向，比如前端开发或者服务器端开发，他们既没有很强的经验，也没有明确的兴趣。那么当他想跳槽到大公司的时候，会发现大公司对岗位和职责的细分非常明确，而自己的能力达不到某个细分岗位的要求。所以他们很难在专业上继续进步，从而陷入原地踏步的窘境。

大公司还是创业公司

在许多论坛上，常常会看到毕业生提出这样的问题：现在有一个大公司和一个创业公司的机会摆在我面前，我应该选择哪一个？其实每个人有不同的想法、不 同的风险偏好，旁人没办法针对这个宽泛的问题给出标准的答案。但是既然提问者是毕业生，这种情况下我还是建议选择大公司，因为会选择创业公司的人往往有自 己的主见，已经接受创业公司的邀请去工作了，不会去发帖询问大家的意见。当然这是开玩笑，真正的原因是，在大公司的头两年，是从学生到职场人士的一个转 变，您可能会从大平台学习到一些规范的流程方法，养成一些足以影响您一生的习惯，认识更多的能对您职场有帮助的人脉。

大公司能给您的

较小的风险

每个公司都有倒闭的可能，但是，显然大公司比小公司的风险低多了。如果您的风险承受能力较低，那么不得不考虑这个因素。

技术最佳实践

在大公司，对代码质量和一致性的要求很高，所以一般在最终发布前会有代码审查（Code Review）流程和项目总结会等。如果您完成了一个任务，但是没有采用最佳实践，只是hack{![所谓hack，就是不优雅的解决方案。比如一个界面 的调整，如果采用最佳实践，需要用MVC架构来分离出界面相关的代码，并且把有可能相关的变量提取出来，合理命名并且放在合理的位置。如果是hack，可 能就不管这么多，看见哪里需要修改就原地修改了，表面上看很快解决了问题，可是这会给后面跟进的同事造成很大的困扰。]}了一下，那么其他同事可能都会指 出您的问题，并且要求您改正之后再提交。小公司或者创业公司人力比较紧张，在他们看来，快速实现和上线，比优雅地上线更重要，所以对于一些最佳实践类的问 题，只能睁一只眼闭一只眼啦。

垂直专精的技能

大公司专业分工很细，而且有更多技术沟通和沉淀的氛围，所以容易让人在垂直专精的技术方向有足够的发展。在小公司更能锻炼技术的广度，深度上缺乏锻 炼的环境。但是其实二者的利弊，都是外界的，技术人员的个人成长除了工作时间的锻炼，还要靠下班后的时间，外界只是给予一个环境或者机会。

服务海量用户的经验

同样是做一个网站，服务少数用户量和服务海量用户量时需要考虑的事情是完全不同的。小网站遇到的问题，大网站一定遇到过，而大网站遇到的问题，小网 站就不一定遇到过了。当一个网站发展到业内最强时，它的问题没有人遇到过，这时候就不能凡事问百度、Google或Stack Overflow了，而要自己去探索解决方案。

软技能

硬技能是指每个职位需要的专业技能，软技能则是通用的技能，比如沟通、影响力、项目管理和演讲等。越是大公司，越是看重影响力，所以会有很多培训教您如何提高影响力。

我在面试一些来自小公司的应聘者时，就发现他平时的工作中，周边环境很少有分享和沉淀的习惯。沉淀和总结是很重要的，在腾讯，设计师做完一次设计定 稿之后，就会把设计的思路，包括整体的设计风格、设计规范和色彩的确定等都总结成一封邮件或者PPT，发送给部门同事。每个人都要有意识地维护自己的作品 集，它在半年一次的考核、晋升面试甚至以后的跳槽中都非常有用。但是小公司的设计师不太会总结个人作品集，时间紧急是一方面原因，另一个主要原因是环境不 需要他这样做，因此就缺乏了这方面的锻炼。

人脉

每年都有不少人从大公司离职去创业，这是非常自然的事情。对于大公司出来的人来说，之前积累的人脉资源这时候会起到很大的作用，比如创业期间的一些 合作机会或者资源的互利，等等。万一创业失败，也不会很惨，因为您之前接触的人脉可以给您提供工作机会。但如果您刚毕业就选择创业，创业失败之后没有人能 给您提供工作机会。

心态

其实大公司能给予毕业生最大的优势，就是提供一个心智培育的土壤。之前参加面试官培训的时候，我大概了解过公司招聘一个毕业生投入的成本。从校园招 聘，到安排面试官面试候选人，再到封闭培训和一些课程培训，再给一段时间熟悉项目，最后3个月试用期后可能还要淘汰掉一些。如果把成本平摊到每一个人身 上，这些投入要一年才能收回来。而小公司不会有这么大的耐心去培育一个新人。如果没有足够的时间去学习和成长，可能在一两年后，员工的能力也比较全面，但 是样样都不精通，也说不清楚自己的目标是什么，于是就变成了“野生程序员”。

综合来讲，在大公司中，从硬技能到软技能都会有很多经验丰富的前辈能够教您，您会在大平台上学习到很多东西。工作几年之后，员工的选择也很多，要么走技术路线继续发展下去，做高级工程师；要么学习管理和领导力；要么出去创业。

所以，我的个人建议是，从毕业生自己前途发展的角度来看，先加入一家上市大公司是个不错的选择。

作为程序员的我每天应该思考的十个问题？

1.此处有没有模式？

研究在哪些情况下行得通，哪些情况下行不通的设计模式，能够让我们发现潜在的规则，了解看似不相关的概念和行为。为了更深层次地了解工作，你需要时不时地问问自己，“此处有没有设计模式？”。

这句话适用的不只是你的代码。在根据业务要求而变的类型变化中有没有模式？技术发展有没有模式？你是否经常看到同样类型的bug连连弹出？

理解其实就是一种感知模式。——以赛亚·伯林


2.如何让它变得简单起来？

通常作为web开发人员，我们会想着拿出复杂又可扩展的解决方案。搞点复杂的会让你觉得自己非常的高大上。问题是，你永远无法预知你的产品和业务在未来将会发生怎样的改变。

架构和编码与其说像建造，还不如说更像园艺艺术。你必须得能够适应不断变化的环境。解决方案越复杂，它的适应力就越弱。

简单才是终极的复杂。——达芬奇



3.它为什么这么工作？

知道事物能工作，与知道它为什么这么工作是两个完全不同的事情。知道一些事物的行为原因，有助于你做出显然更好的决策。

伟大的程序员，和那些只是知道一门编程语言的人之间的区别是，两者处于的知识层深度不同，前者深刻地理解其工作原理。

这也适用于修复问题的时候。“只要重新启动服务即可。”“你重启了吗？”当弹出问题的时候，我们往往会说类似于这样的话。然而，如果你这样说了，那你就失去了一次学习的黄金机会。

知道为什么会出现问题，才能从根本上修复问题，才能避免再出现这样的问题。

4.之前有人做过吗？

当你自我感觉发明了一种复杂算法的时候，可能就意味着你正在错误的道路上了。最好的方法是搜索其他人是否已经解决了这个问题。
需要写算法，以便于添加标签到最接近用户鼠标的菜单项中？别急，已经有解救方法了。想为送货车找一条最短路径？也已经有解决方法了。想找类似于用户刚刚enter的标签，那么也不用自己绞尽脑汁写了。

上面这些只是几个例子，但是相信我，你碰到的问题，别人早就碰到过了。

我能看得更远，那是因为站在巨人的肩膀上。——牛顿


5.谁第一个提出来的？

你觉得自己知道REST？

那么，你读过Roy Fielding说明REST的原始文件吗，你了解它的期望目的吗？暂且不说那个在IDE V7中使用REST API生成向导比你更有经验的博主了。

所以，告诉自己试着去阅读概念和理论的原始来源。然后通过各种方法去了解行业思想领袖给出的最新开发成果。如果你不知道是从哪里开始的，那么你怎么理解目前的发展进程呢？

6.我真的热爱我目前的工作吗？

首先让我们面对一个事实：编程很难。

即使很难，编程也在不断发展。如果用现在的标准来看，2年前的框架简直笨拙地就像一头恐龙。要想留在这一行，那么你需要终生致力于学习和研究。

如果你确实不喜欢编程，那么要想跟上那些热爱的人的步伐，希望并不大。找找你为什么对她没有兴致的原因。不要因为与市场存在差距或因为待遇还不错，就决定成为一名安全专家，不要只是因为最近的文章上面评论说，UX是高科技领域中最热门的职位，就立志成为一个UX专家。

重要的事情说三遍：做自己热爱的事情。做自己热爱的事情。做自己热爱的事情。

做自己热爱的事情，你所需要的资源也会随之而来。——彼得·麦克威廉斯



7.还可以用在哪里？

我发现web开发人员最大的局限之一就是失败的想象力。

我们在特定的情况下学习的东西，或看到某种用于解决特定问题的技术，我们往往会认为这就是它们的唯一用途。但是，这个想法基本上都是错的。每次你学到新的东西的时候，都应该问自己：“还可以用在哪里？”。

学到了一种超棒的新的定位方法来定位图形节点，那么它是不是也可以运用到在有2个维度的数据集中查找某一个数据点？发现一个越过WebSockets从客户端发送数据到服务器的很棒方法？那么它该如何应用于制定一个可扩展系列的后端服务？有时候此路不通，有时候却是可行的。

逻辑能力能让你从A到Z，但是想象力却能让你去往任何地方。—— 爱因斯坦



8.我败在哪里？

最简单的革新方法就是降低失败的成本。

游戏开发公司Valve和它的一些同行就将此当作金科玉律。这同样适用于web开发人员，如果你害怕失败，那么你将永远不会有大的突破。

勇敢地去尝试，从失败中学习，然后再试一次。

不要害怕犯错。认识失败。然后从头来过。——本杰明·富兰克林



9.如何实现这个目标？

我们生活的世界中只有很少一部分事情是真的完全不可能的。

要抱着自己想做的任何事情都是可能的这样一种想法去做事。可能你会发现你想做的事不符合当前实际，但随着世界的不断进步，它也许比你想象地更快成为了现实。

事情未成功之前，它永远是看似不可能的。——曼德拉（前南非总统）



10.我可以向谁学习？

不要在你是最聪明的地方工作。

选择那些拥有能够激励你，挑战你，让你做得更好的同事的工作和企业。不必与代码相关，在文本编辑器和命令行之外还有一个世界。学习其他领域的事情，然后应用于你的工作中。

不管如何，仅仅胜任工作是不够的。

Github 利器

接触Github 很长时间了，但是我真正的了解Github  似乎是这两天 刘强和 浮生 毛瑞斌，的提醒下。我才知道原来Github原来是这么的重要。

很多时候，我们在Github 找到自己的人生知己。

我觉的作为一个合格的程序员，必备的素质！

第一：  Google  学会描述你的问题，English

第二：  Github  因为有很多的开源的库，这绝对是招人的时候筛选人得一个重要的指标。看她得绿帽子，哈哈！我真是天才。

第三：  StackOverFlow  这绝对是全球最牛逼的Bug园地。在这里你几乎能找到任何的问题的答案！这里的大神的真的是太多了！就看你有没有发现美丽的眼睛了！

第四：  Bolgger  一个博客的园地， 我们需要分享自己的技术，说的好听一点是这样的！其实，我的博客是写给我自己看的。以后当我遇到问题的时候，我会给自己一个tips.到自己的博客找到答案！

第五：官方文档，是的这是绝对的权威。但是很多的时候，我们在文档中只能找到用法和接口，但是无法找到解决问题的方法！

Thinking in Program

代码如何去写？很多码农都是 只要实现了功能就可以了，但是真正的细节真的不是很在意的。这样，写出来的代码难以维护，世界上最烦的事情 莫过于 看别人写的代码。

1 思考如何做的更好？

 这是作为一个工程师必备的基本素养。如果你不想追求更好的技术，你只是满足于现状的话，你基本上就是混吃等死的状态。这种人在我现在的这个社会真的是太多了。他们满足现在自以为的“高薪”！其实，真的有很多这样的人，他们通过简单的培训，然后就觉得自己可以胜任任何的工作，然后在公司里面写着糟糕的代码。当实在难以维护的时候，就会跳槽，然后将这个垃圾的APP交给下一个程序员。真的是很恶心的。

2 多一流的读书

是的，如果你觉得自己不用学习的话，那说明你已经是一个菜鸟了。书籍是别人的经验是积累。有的时候书籍就是值那个价钱，不要觉得 买书太贵了。你应该想一下，当你越到问题无法解决的时候，耽误一两天的工期的时候，你的工资难道买不起那个本书籍吗？不是所有的书籍都对你有用的！

3 多逛一个优秀的网站和论坛

这个很好的，自己去发掘吧！

4 模板类

是的，我们应该抽取一些父类，讲一些共用的方法， 留一些接口供给子类使用就可以了！重构是一件很伟大的事情。不仅仅是结构的重构，代码的重构也是很不错的。关键是你要有一个重构的心。

当我们在Activity Fragment ，当我们去修改的Bug  的时候，老是回去花时间去寻找布局，一般都在 oncraete() 中找到，但是有的时候这个方法，有的人会写的很长，这个时候我会建议，在父类中提取一个方法 protexted int getLayoutId(){return R.layout.*}  这样的话符合单一性原则。

重构是一个思考的过程，没有人可以上来就可以做的很完美的。这需要一个过程的，这需要时间，需要成长的过程的！

5 自己的规范

代码的整洁，  代码的规范，自己去遵循一个自己的规范！

命名的规范：

包得结构：

xml 命名

6 我们最烦听到的就是 Bug,所以我们一概跟我们的测试人员下一种定义，不要把所有的APP的问题都定义为Bug.

其实，只要不是功能性的问题都不算是Bug,  有很多公司根本不愿意花钱招测试人员，我觉的这是非常垃圾想法，他们觉得这样可以节约成本。但是，我觉的者非常的短视，现在的创业型的公司，就得随便找几个前台和妹子，让他们玩玩APP,  Sometimes they didn't know how to describe the bug! So we have to spend a long time to communit with them,just for know what is the bug?

 

Android studio 如何关联Subversion?

之前一直被一个问题困扰： 我的Android studio 打开 SVN CheckOut 的项目 一开始的时候是没有问题的！

 But  when i close the svn project, to open the other Project.  A day later I reopen the last project.but I can't see subverion  update and  commit!  How to reslove the porplem?

fowlling this way;

1  you can choose "Enable Version Control Integration"

2  you just  choose the subverion!  that is all right!

thinking in problem?

Why is occer?  I think maybe is you use Android studio , But Android studio subverion Manager  didn't control the file, When you quit the android studio or quit cmputer but not person do it !

优秀程序员是如何处理糟糕代码的

可能你一行不好的代码也从来没有写过。这是有可能的，但在现实中又不太可能。

现实情况是，和这个星球上的其他所有程序员一样，你会产出安全漏洞、UI元素偏移，等等等等的代码。这并不能说明你是一个不好的开发人员。只是因为你是人类而已——一种不可避免会犯错的生物。

正是这种每个开发人员都有的“人性”缺陷，驱使那些优秀的开发人员敢于承担代码和底层基础架构的不足，有准备有计划地行动。下面是他们将做的事情。

假设

几年前，Netflix开源了Chaos Monkey和Simian Army的其他部分（Simian Army是一套工具，用来管理基于云的软件）。从本质上说，Chaos Monkey的范围贯穿亚马逊Web服务的基础设施，能够随意终止实例。从根本上说，它是一种通过创建最坏的可能方案来做最坏打算的方法。

正如Netflix的Cory Bennett和Ariel Tseitlin于发行之时在博客上这样写道，“代码会失败，并且你越不希望失败或一点也没有准备的时候，反而更加不可避免会出现故障。如果你的应用程序不能容忍实例故障，那么你是愿意凌晨3点被召唤呢还是在办公室里通宵？”

使用不可预测的方式来模拟故障，Netflix强迫注重基础设施的弹性。与其假设最佳的情形，还不如做一个最坏的打算。这样我们就能愉快地进入下一个进程了。

测试

上面我们说了一个提高基础设施的伟大方法，那么代码呢？

Jeff Atwood，一个程序员的答案是：“你需要折腾你的代码。”他写道：

我相信，每个专业程序员职业生涯的一个关键转折点，就在当你意识到你才是自己最大的敌人，以及减轻这种威胁的唯一办法就是接受它的时候。将自己当作最大的敌人。打破你的用户界面。打破你的代码。折腾你的软件。

在实践中，这意味着“程序员至少需要对常见错误有一定的了解，然而，很多程序员往往不会这么去做，甚至是反着来。”这意味着你作为“编程之神”的责任也包括成为“测试之神”，通过“折腾”代码积极地来消除里面的错误。

Andre Medeiros补充认为我们应该对调试“精益求精”，因为开发人员需要对他们的代码做更多的事情。

“为了防止bug，你写出来的代码得让任何程序员都觉得简单。为了修复bug，你得理解你的代码。为了精密地了解代码，你需要列举和验证你的假设，如果有必要，你还需要构建调试工具。”

贫民窟上的摩天大楼

当然，对于我们的代码，其最大的问题之一是，它继承了如此多其他的代码。特别是在已建立的企业中，我们常常构建在旧代码上，从而导致了各种后续延伸问题。

以下是Zeynep Tufekci的精彩描述：

将它比喻成造房子的话——也就说你将要在已经造好的底层基础上造二楼。但房子一开始造的时候并没有造好，没有打好地基，你也不知道哪面是承重墙。你只能尽可能地去猜，然后造好了一个楼层——用你的手指。然后你接着这样做。很多旧但控制着基础设施关键部分的软件系统就是这样运行的。在某一段时间内它也的确是可以工作，但每一个新楼层的建造意味着增加了更多的漏洞。我们正在代码中建设贫民窟上的摩天大楼——而且，还在地震区。

很显然，我们对于改善这种情况束手无策，除非我们能够致力于去除技术债务。

但也许，只是也许，在心甘情愿折腾代码的过程中，你会发现消除技术债务是如此之重要。

屌丝级别的程序员 一天中该做的事情

1  到公司 打开自己的电脑


2  查看自己的邮箱  的邮件


3  更新自己的代码和需求文档


4  浏览喜欢过的技术博客 

5  思考今天该做些什么呢？

6 想好了。揩干！