如何成为一个程序老手，新手必知的40个小技巧

Answer 1

老鸟和新手的一个很大区别来自于debug的能力。其中最主要又可以从两方面看出来：

从高层往底层找错。

科学方法。

0.

很多新手遇到程序执行结果不对（尤其是图形程序员），先认为是机器毛病（浮点精度、硬件故障），然后认为是驱动有错，再认为是系统有错，最后才开始排查自己的程序。其实99%的情况下是自己程序有错，然后那1%里面的99%是系统有bug，再接着那1%里的99%是驱动有bug，最后到硬件问题，已经微乎其微了。应该从高层往底层查，而不是反过来。

1.

debug一般来说是知道现象，但原因未知。这一点和很多自然科学的情况一样，所以完全也可以用科学的方法来：

提假说->根据假说做出预言->做实验肯定或否定预言。

对应于debug，那就是假设是某个地方有问题，那么推断它一定会导致除了你看到的现象之外的其他现象，运行程序看你的推断是否成立。

掌握这个方法后debug不在变成瞎找瞎试，而是有迹可循有系统可依赖的方法。

40条新手小技巧

0.重构是程序员的主力技能。

工作日志能提升脑容量。

先用profiler调查，才有脸谈优化。

注释贵精不贵多。杜绝大姨妈般的“例注”。漫山遍野的碎碎念注释，实际就是背景噪音。

普通程序员+google=超级程序员。

单元测试总是合算的。

不要先写框架再写实现。最好反过来，从原型中提炼框架。

代码结构清晰，其它问题都不算事儿。

好的项目作风硬派，一键测试，一键发布，一键部署; 烂的项目生性猥琐，口口相传，不立文字，神神秘秘。

编码不要畏惧变化，要拥抱变化。

常充电。程序员只有一种死法：土死的。

编程之事，隔离是方向，起名是关键，测试是主角，调试是补充，版本控制是后悔药。

一行代码一个兵。形成建制才能有战斗力。单位规模不宜过大，千人班，万人排易成万人坑。

重构/优化/修复Bug，同时只能作一件。

简单模块注意封装，复杂模块注意分层。

人脑性能有限，整洁胜于杂乱。读不懂的代码，尝试整理下格式;  不好用的接口，尝试重新封装下。

迭代速度决定工作强度。想多快好省，就从简化开发流程，加快迭代速度开始。

忘掉优化写代码。过早优化等同恶意破坏；忘掉代码作优化。优化要基于性能测试，而不是纠结于字里行间。

最好的工具是纸笔;其次好的是markdown。

leader问任务时间，若答不上来，可能是任务拆分还不够细。

宁可多算一周，不可少估一天。过于“乐观”容易让boss受惊吓。

最有用的语言是English。其次的可能是Python。

百闻不如一见。画出结果，一目了然。调试耗时将大大缩短。

资源、代码应一道受版本管理。资源匹配错误远比代码匹配错误更难排查。

不要基于想象开发， 要基于原型开发。原型的价值是快速验证想法，帮大家节省时间。

序列化首选明文文本 。诸如二进制、混淆、加密、压缩等等有需要时再加。

编译器永远比你懂微观优化。只能向它不擅长的方向努力。

不要定过大、过远、过细的计划。即使定了也没有用。

至少半数时间将花在集成上。时间，时间，时间总是不够。

与主流意见/方法/风格/习惯相悖时，先检讨自己最可靠。

出现bug主动查，不管是不是你的。这能让你业务能力猛涨、个人形象飙升; 如果你的bug被别人揪出来.....呵呵，那你会很被动～≧﹏≦

不知怎么选技术书时就挑薄的。起码不会太贵，且你能看完。

git是最棒的。简单，可靠，免费。

仅对“可预测的非理性”抛断言。

Log要写时间与分类。并且要能重定向输出。

注释是稍差的文档。更好的是清晰的命名。让代码讲自己的故事。

造轮子是很好的锻炼方法。前提是你见过别的轮子。

code review最好以小组/结对的形式。对业务有一定了解，建议会更有价值（但不绝对）。而且不会成为负担。管理员个人review则很容易成team的瓶颈。

提问前先做调研。问不到点上既被鄙视，又浪费自己的时间。

永远别小看程序媛(╯3╰)!

Answer 2

1.积极大胆地谷歌。你得知道如何有效地组织搜索关键字，查阅别人写的代码，然后合理地用在代码里，从而解决问题。

　　2.拥抱变化，坚持不懈。老手程序员在接触新技术时，能欣然接受像个初学者一样处处受挫，并总能在完成工作的同时自学成才。

　　3.承认细节的重要性。例如变量和函数的命名、CSS 属性的命名、该用哈希还是用数组，以及其他看起来微不足道，但可能对项目有深远影响的事情。

　　4.承认大多数的“重要决定”其实并没有那么重要。一般的开发者经常在技术选型等“重大问题”上陷入唇枪舌战，而程序员老鸟们会避免浪费时间在骂战中。这一点上，他们就像禅宗大师一样（zen-like）。

　　5.选择合适的工具解决问题。网上有无数的开源库、工具和框架，让人眼花缭乱。而老手们清楚地知道针对怎样的问题，应该用什么样的工具。

　　6.明白代码「不值钱」（该删就删）。你必须习惯于删掉几百行代码来重写程序的某一部分，毫不留情。

　　7.在评估技术的时候要全面。例如，我一直在鼓吹Elixir。它语法优美，社区完善，有很大的潜力。但Elixir诞生的时间太短，所以如果要构建复杂的功能，可能会难以找到能帮你提高效率的开源工具。因此，在评估要不要选择使用一项技术时，你得把所有这些因素都考虑在内。

　　8.学会说“我不知道”。没有比拒绝承认自己不知道更能浪费一个开发者的时间了。

　　9. 仔细分析错误信息里的线索。传统教育告诉我们：失败是坏事。报错信息这种东西也经常被跟失败联系起来，然而优秀程序员明白，这些错误消息里其实隐藏着能将你指向最终正确解决方案的线索。

　　10. 了解过早优化和必要的“炫技式”优化的区别。老手们清楚在什么时候需要写一些看上去没那么好懂，但会让程序运行更快的代码。

　　11.每个人都会犯错，为自己的过失负责。而尤其在团队里，把责任推来推去没有任何意义，因为错误的发生往往不只是一方的因素造成的。

　　12. 成为你所用的开发工具的重度用户。如果长期在某个开发环境下有相当比例的开发工作，那你应该去掌握使用它的细节。

　　13. 学会用Vim（至少会一点）。 你至少应该在这个编辑器里学会勉强地移动和翻页。

　　14. 不要接陌生技术领域的私活。个人做自由职业项目，其中很大一部分挑战就是评估项目时间。不要规划自己未知领域的事情，那会让你处于想当尴尬的境地。

　　15. 不要数你干活花了几个小时。技术大牛会把时间花在有深度的工作上，并且他们清楚花了多少时间完全不重要。

　　16. 学会坦然接受批评。当你的代码因为各种原因四分五裂时，你需要培养用理性和逻辑的方式来应对（而不是情绪化处理）。

　　17. 同有更多经验的人结对编程。没有比这个更高效的编程学习方式了。

　　18. 一定要先自己做一遍代码审查。当你在GitHub上发起一个pull request之前，先把代码当成别人写的，自己先审查一遍。

　　19. 认识到做自由职业的难点不是写代码，而是其余的所有事情。销售、推广、客户支持，质量保证以及产品管理，所有这些都会花费大量时间。

　　20. 发现并解决更大的问题。优秀的程序员不拘泥于眼前的问题，而是清楚如何用更长远的方式彻底的解决这一类问题。

　　21. 深入了解一些大型开源项目的核心能让你开发时如虎添翼。如果你知道如何给你的项目打猴子补丁(Monkey Patch), 那么你将无所不能。

　　22. 跳过多数的会议。你的公司雇你是来写代码的，而不是谈代码的。当会议多到失控的时候，不去参加也没有任何问题。而且一旦你开始这样做，别人会更珍惜你的时间。

　　23.知道什么时候开始回馈。到了某个时候你需要将你的技能和经验传授给年轻的开发人员，就像你的导师当时教授你一样。

　　24. 能写烂代码。有时候可以当一当“胶带式程序员”。关键是随着时间推移，你需要弄清楚什么时候可以走捷径，什么时候必须走捷径。这其实是最难掌握的技能之一。

　　25. 礼貌地告诉别人你工作到很晚。如果你是办公室里最后一个，可以发一封简短的汇报邮件。别人一般会注意到邮件上的时间戳的。

　　26. 像一个领导者(Leader)一样做事，而不是老板(Boss)。老板是让别人为他工作的人，领导者是人们追随的人。做个领导者。

　　27. 去打打桌上足球。从长期来看，同其他开发者（或不同岗位上的同事）建立联系会比在紧巴巴的期限里交付一个功能更有价值。

　　28. 在压力下学习。你需要知道如何应对像系统宕机而你要负责将它复原的情况，即使一开始你完全没有头绪。