1. 重构是程序员的主力技能。
2. 工作日志能提升脑容量。
3. 先用profiler调查，才有脸谈优化。
4. 软件设计有两种方式：一种方式是，使软件过于简单，明显没有缺陷；另一种方式是，使软件过于复杂，没有明显的缺陷。
5. 大部分情况下，构建程序的过程本质上是对规范调试的过程。
6.注释贵精不贵多。杜绝大姨妈般的“例注”。漫山遍野的碎碎念注释，实际就是背景噪音。
7. 普通程序员+google=超级程序员。
8. 软件开发往往是这样：最开始的 90% 代码占用了开始的 90% 的开发时间；剩下 10% 代码同样需要 90% 的开发时间。
9. 单元测试总是合算的。
10. 不要先写框架再写实现。最好反过来，从原型中提炼框架。
11. 代码结构清晰，其它问题都不算事儿。
12. 用几个小时来制定计划，可以节省几周的编程时间。
13. 好的项目作风硬派，一键测试，一键发布，一键部署; 烂的项目生性猥琐，口口相传，不立文字，神神秘秘。
14. 编码不要畏惧变化，要拥抱变化。
15. 任何傻瓜都能写出计算机可以理解的代码。好的程序员能写出人能读懂的代码
16. 常充电。程序员只有一种死法：土死的。
17. 编程之事，隔离是方向，起名是关键，测试是主角，调试是补充，版本控制是后悔药。
18. C语言很容易让你犯错误；C++看起来好一些，但当你用它时，你会发现会死的更惨
19. 一行代码一个兵。形成建制才能有战斗力。单位规模不宜过大，千人班，万人排易成万人坑。
20. 如果你喜欢底层开发，千万不要勉强自己去搞VC，找到你最真实的想法，程序员最不能忍受的就是万精油。
21. 重构/优化/修复Bug，同时只能作一件。
22. 简单模块注意封装，复杂模块注意分层。
23. 人脑性能有限，整洁胜于杂乱。读不懂的代码，尝试整理下格式; 不好用的接口，尝试重新封装下。
24. 迭代速度决定工作强度。想多快好省，就从简化开发流程，加快迭代速度开始。
25. 忘掉优化写代码。过早优化等同恶意破坏;忘掉代码作优化。优化要基于性能测试，而不是纠结于字里行间。
26. 世上只有两种编程语言：一种是总是被人骂的，一种是从来没人用的
27. 最好的工具是纸笔;其次好的是markdown。
28. leader问任务时间，若答不上来，可能是任务拆分还不够细。
29. 调试一个初次见到的代码比重写代码要困难两倍。
30. 宁可多算一周，不可少估一天。过于“乐观”容易让boss受惊吓。
31. 当你试图解决一个你不理解的问题时，复杂化就产成了。
32. 最有用的语言是English。其次的可能是Python。
33. 百闻不如一见。画出结果，一目了然。调试耗时将大大缩短。
34. 质量、速度、廉价，选择其中两个。
35. 资源、代码应一道受版本管理。资源匹配错误远比代码匹配错误更难排查。
36. 不要基于想象开发，要基于原型开发。原型的价值是快速验证想法，帮大家节省时间。
37. 生命太短暂，不要去做一些根本没有人想要的东西。
38. 序列化首选明文文本。诸如二进制、混淆、加密、压缩等等有需要时再加。
39. 高质量的代码就是对程序本身最好的注释。
40. 编译器永远比你懂微观优化。只能向它不擅长的方向努力。
41. 你们中大多数人都熟悉程序员的美德，有三种：那就是懒惰、急躁和傲慢
42. 不要定过大、过远、过细的计划。即使定了也没有用。
43. 至少半数时间将花在集成上。时间，时间，时间总是不够。
44. 靠代码行数来衡量开发进度，就像是凭重量来衡量飞机制造的进度。
45. 作为一个程序员，郁闷的事情是，面对一个代码块，却不敢去修改。更糟糕的是，这个代码块还是自己写的。
46. 与主流意见/方法/风格/习惯相悖时，先检讨自己最可靠。
47. 出现bug主动查，不管是不是你的。这能让你业务能力猛涨、个人形象飙升; 如果你的bug被别人揪出来…..呵呵，那你会很被动～
48. 能说算不上什么，有本事就把你的代码给我看看
49. 不知怎么选技术书时就挑薄的。起码不会太贵，且你能看完。
50. 你选择了一种语言，意味着你还选择了一组技术、一个社区。
51. git是最棒的。简单，可靠，免费。
52. 仅对“可预测的非理性”抛断言。
53. 没有什么代码的执行速度比空代码更快。
54. UNIX很简单。但需要有一定天赋的人才能理解这种简单。
55. Log要写时间与分类。并且要能重定向输出。
56. 注释是稍差的文档。更好的是清晰的命名。让代码讲自己的故事。
57. 软件在能够复用前必须先能用。
58. 当你想在你的代码中找到一个错误时，这很难；当你认为你的代码是不会有错误时，这就更难了。
59. 造轮子是很好的锻炼方法。前提是你见过别的轮子。
60. 我们这个世界的一个问题是，蠢人信誓旦旦，智人满腹狐疑。
61. C程序员永远不会灭亡。他们只是cast成了void。
62. 你要么要软件质量，要么要指针算法；两者不可兼得。
63. code review最好以小组/结对的形式。对业务有一定了解，建议会更有价值(但不绝对)。而且不会成为负担。管理员个人review则很容易成team的瓶颈。
64. 如果debugging是一种消灭bug的过程，那编程就一定是把bug放进去的过程。
65. 提问前先做调研。问不到点上既被鄙视，又浪费自己的时间。
66.软件工程的目标是控制复杂度，而不是增加复杂性。
67. 控制复杂性是计算机编程的本质
68. 计算机科学领域的所有问题都可以通过其他方式间接解决。
69. 这不是一个 bug，这只是一个未列出来的特性。
70. 永远别小看程序媛
编程学习资料获取方式：
转发文章+私信【资料】获取领取方式