有哪些新手程序员不知道的小技巧？ 第1页

1. 程序不等于数据结构加算法，而等于搜索引擎加英语。

2. 技术群是萌新的搜索引擎，同时也是老鸟的效率陷阱。很奇怪，喜爱社交的手艺人技术总是不咋地。

3. 遇到匪夷所思的Bug时，不要信邪，错误一定出在你自己身上。要坚信，引擎、类库以及语言本身，就像你的女友或老婆一样，永远正确。同样，所谓“运行效率低”也是一样。

4. 推荐一本技术书：《逻辑学导论》。

5. 魅力低的人能力总是被低估，团队中不善言辞以及长得丑的人值得留意。反之也成立，“你长得真好看”，“你给人的感觉很不错”，可以作为“你丫技术真烂”的委婉说辞。

6. 同事骂策划或产品傻逼，自己跟着骂骂就得了，千万别真的那么想，否则会降低你的可合作性。可合作性是项很重要的能力。

7. 《设计模式》、《人月神话》、《人件》、《我的编程感悟》等业内知名度很高的书，其实没什么卵用，但依然推荐阅读，可以用来和同行聊天时装逼。尤其是和写Java的程序员聊设计模式，能把人给唬跪了。但不要和用C系列语言的程序员聊这个。

8. 自动识别是IDE的标配，因此匈牙利命名法除了降低编码效率之外没什么别的好处。除非你用记事本敲代码，你长得真好看，你牛逼。

9. iOS开发真的是……非常简单，连初中小孩都学得会。招人难只不过因为Mac电脑普及率低。推荐给不明前途的新人。

10. 新人如果面试iOS，记得花一小时把斯坦福大学的某节有关MVC的公开课看明白，面试时候使劲讲。对面主程草包一点的话，没准会觉得醍醐灌顶，终于找到了之前遇到的一些奇葩问题的根源。

11. 有一种傻逼，总是嫌弃别人造的轮子不够圆，非要自己亲手造个方轮子。这种傻逼到处都是。以现成的类库坑多为由不用，非要自己写，不过是避开了现有的坑，转而亲手挖坑亲自跳。

12. H5真的没什么前途，那概念是用来忽悠傻钱的，始作俑者是李开复大大。新人可别被坑了。

13. cocos真是好啊！大家都快去用！Unity真垃圾！一大堆坑而且闭源没法改！千万别用！做游戏的都快去用cocos去！触控靠谱！cocos大法好！都别用Unity嗯。都别用才好。

14. 翻译官方文档是通向“业界大拿”的捷径。

15. 以极客自居的，多为极品。

16. 语言之间的隔阂，不过是要花一周熟悉下语法。勤奋点三天就够了。技术是技术，语言是语言，一门技术可以跨多门语言，程序员以技术分，而非以语言分。只有外行和新人才混为一谈。当然有不少写了多年程序依然停留在语法层面的老新人也分不清这个。

把觉得不靠谱的需求放到最后做。

很可能到时候需求就变了。

需求来了，切莫急着编码；

不明确不清晰的需求不要急着写，很可能最后不需要写；

先搭架子，后写实现，架子是思路，想不清细节可以先放个函数名在那里；

疲惫或者感觉自己脑子不够用，或者进了死胡同，就回家睡觉，不要死磕；

读好书，垃圾书会浪费你时间；

功夫在业余时间，业余时间多学习；

效率不高的时候，不要死撑，出去玩，低效的努力不过是欺骗自己；

多陪孩子和家人。

我有一个学习的小技巧，就是学习新技术的时候，多看看“官方文档”。

多年来的学习和工作经历，让我比较深刻认识到一点：看“官方文档”非常重要。

我们很多的问题和技术细节，其实，只要我们认真将官方文档过一遍，会发觉大部分的问题和认识模糊的地方都消失了。甚至，你还能发现自己之前通过搜索获得的到一些资料，可能是不准确或者已经过时的。官方文档是真正的好东西，因为编写文档的人群，通常就是这些技术或者软件的开发者，他们才是对这些东西最了解的人，因此，他们写的文档质量是很高的，通常也是最新的。

官方文档的不足的地方，大概是中文版本不多，看起来可能会比较吃力。不过，请相信我，下载一个翻译辅助软件，慢慢看还是可以的。另一方面，就是这些文档编写者，通常是技术界大牛，他们编写文档有时候是基于他们自己的技术认知水平，跳过了很多基础概念，也增加了阅读难度。不过，这个我们也可以通过多查资料，慢慢看来解决，并且通常会带来额外的学习收获。

版本管理工具是你最好的拐杖。代码要早提交，勤提交，越勤越好，只要改进一点点（哪怕只是改了一行代码，甚至只是改了注释中的拼写错误），测试通过了，立马提交。没有提交的代码就等于没写。

调试的要点在于代码孤立和隔离——每次只修改一处代码；因为如果同时改动多处代码，你不知道到底是哪个改动造成了关键性的变化。勤提交可以帮你很好地做代码隔离。老手的做法是改一点，不成功，立即在版本管理里放弃当前改动，回滚到上一个提交的版本，然后再改；但新手会在本地版本里改，不提交，不行了再手动改回来。但靠记忆手动改回常常有问题，比如新声明的变量忘了去掉，或者改错了，或者偷懒干脆不改回，继续改其他部分。这样改动越积越多，越搞越没头绪，最后往往得整个放弃从头再来（如果之前的新功能代码也没有提交的话，可能会一起搞砸，效率更低）。还有一种情况是瞎猫碰到死老鼠，改七改八能运行了，但之后发现其它工作的部分又出问题了，于是再去拆东墙补西墙。其实解决方案很简单：勤提交。一旦不行，立即回滚。

勤提交的好处除了回滚方便以外，还有利于快速自我代码审查——在提交之前瞟一眼diff，勤提交改动小，许多显而易见的错误，或者一些垃圾改动，比如增加了空白行，没有用到的声明变量等等容易被看到，此时就可以把这些改动放弃，有利于避免代码质量劣化。

----

P.S. 关于提交的频率，新功能／BUG修复的提交单位是branch而不是commit。对应的，团队代码审核（如果有的话）的基本单位也是branch PULL request而不是单个commit。那些认为只有完成了一个新功能或者修复了一整个bug才能commit的，本座建议你重新审视一下自己作为程序员的基本素养。

----

Q：公司还在用SVN怎么办？

A：赶快换到GIT。

Q：想用GIT但做不了主怎么办？

A：忍着。

Q：GIT本地完整拷贝太大了，硬盘装不下怎么办？

A：买2T的硬盘。

Q：买不起怎么办？

A：500块的硬盘都买不起你做毛的开发？

二分法找bug

-----

（强行把自己带入新手程序员的一些评论我就都不回复了，只是单纯分享个小技巧，知道的人知道就好，不知道的人记住就好。）