忧郁的大能猫

好奇的探索者，理性的思考者，踏实的行动者。

Table of Contents:

程序员的心理疾病

无自知之明

由于程序员的工作最近几年比较容易找，工资还不错，所以很多程序员往往只看到自己的肚脐眼，看不到自己在整个社会里的位置其实并不是那么的关键和重要。很多程序员除了自己会的那点东西，几乎对其它领域和事情完全不感兴趣，看不起其他人。
这就是为什么我的前同事 TJ 作为一个资深的天体物理学家，在一个软件公司里面那么卑微。貌似会写点 node.js，iOS 软件的人都可以对他趾高气昂的样子，而其实这些东西的价值哪里可能跟 TJ 知道的物理知识相提并论。很多科学家其实都可以轻而易举的掌握程序员知道的那点东西。

垃圾当宝贝

其实软件里面有少数永恒的珍宝，可惜很少有人理解和尊重它们的价值。由于没有科学作为理论的基础，没有实验作为检验它们的标准，软件行业的很多东西就像现代艺术一样，丑陋无比的垃圾还能摆在外表堂皇的“现代艺术博物馆”里面，被人当成传世大作一样膜拜。

以语言取人

你的软件是什么语言写的，告诉别人的时候是千万要小心的，不到万不得已最好不要说。因为十有八九，对方会立即在心里对你的软件的价值做出判断，光凭你用的是什么语言。
在这样一个行业里，你会很难找到一个只把程序语言或者技术当成是工具的人。如果有人问你对某个语言或者技术的评价，是非常尴尬甚至危险的事情，所以最可靠的办法就是不做评论，什么都不要说。

分清精髓知识和表面知识，不要太拿经验当回事

在任何领域，都只有少数知识是精髓的，另外大部分都是表面的，肤浅的，是从精髓知识衍生出来的。精髓知识和表面知识都是有用的，然而它们的分量和重要性却是不一样的。所以必须区分精髓知识和表面知识，不能混为一谈，对待它们的态度应该是不一样的。由于表面知识基本是死的，而且很容易从精髓知识推导衍生出来。我们不应该因为自己知道很多表面知识，就自以为比掌握了精髓知识的人还要强。不应该因为别人不知道某些表面知识，就以为自己高人一等。

IT公司经常有这样的人，以为精通一些看似复杂的命令行，或者某些难用的程序语言就很了不起似的。

不要嚷着要别人写测试

在很多程序员的脑子里，所谓的“流程”和“测试”，比真正解决问题的代码还重要。他们跟你说起这些，那真的叫正儿八经，义正言辞啊！所以有时候你很迷惑，这些人除了遵守这些按部就班的规矩，还知道些什么。大概没有能力的人都喜欢追究各种规矩吧，这样可以显得自己“没有功劳有苦劳”。这些人自己写的代码很平庸，不知道如何简单有效地解决困难的问题，却喜欢在别人提交代码让他review的时候叫喊：“测试很重要！覆盖很重要！你要再加一些测试才能通过我的review！”

杂项

名言

• If it's not tested, it doesn't work.
• Just because you wrote it doesn't mean you own it — don't be offended if someone else on your team has to change your code.
• Don't reinvent the wheel, library code is there to help.
• Code that's hard to understand is hard to maintain.
• Code that's hard to maintain is next to useless.
• The neater your code layout, the easier it is to read. The easier it is to read, the easier it is to understand and maintain.
• Code is not self documenting. Help others by adding comments to guide them. You may understand it now but what about in 5 years time?
• Bad Code can and will come back to haunt you.
• Magic numbers are bad.
• If there is a bug, the user will find it.
• It's not the quantity of code that matters, it's the quality. Any idiot can bang out 40kloc but that doesn't make it fit for purpose.
• The true cost of poorly written code is in the maintenance.
• Bad architecture causes more problems than bad code.
• You will spend more time thinking than coding.
• The best programmers are always building things.
• There's always a better way.
• Code reviews by your peers will make all of you better.
• Fewer features for better code is always the right answer in the end.
• If you want to feel important as a software developer, work at a tech company

编码实践

• "有效的程序员不应该浪费很多时间用于程序调试，他们应该一开始就不要把故障引入。----Dijkstra"
• "程序测试是表明存在故障的非常有效的方法，但对于证明没有故障，调试是很无能为力的。-----Dijkstra"
• 代码应写一点测一点。便于调试。先简单再复杂，循环迭代。
• 时刻备份。
• 建一个专用于测试的文件，小的函数，对象可在此测试，因为在大项目中不好看到其效果。
• 案头准备几本便签用于记录。a、工作计划  b、关于项目的笔记本 c、编写代码的草稿本 d、关于知识的笔记本
• 文件的编码要注意
• • 创建项目时要先设置字符集，这是一个好习惯
• sql语句用之前先试一试，字符型的要加引号，numeric fields should not be enclosed in quotes:
• 研究源代码时，碰到非常复杂的，可以用简单的代码进行测试。
• 网上的一些技术文章有的是过时的，想了解最新的就得去官网上看，英文的也要看
• 有的时候页面改了之后还是没变化，可增加输出强制刷新，添个alert
• 写前端代码时出现奇怪的现象了就多用几个浏览器试试，可能是浏览器的问题
• 写代码时可能会配合的画一些流程图之类的图，注意不同图形不同符号要代表不同的含义
• 代码的边界处很容易出错，要多加注意
• php手册中有很多用户的代码的例子，很好，可作为一种代码资源
• 使用软件一定要查看其版本，以及版本之间的兼容性
• 编程的一个思路（数据结构加算法）：分析程序需要哪些数据，比如展示给用户的数据，得以让程序运行的数据，标记数据，等。再去想用什么形式结构去储存数据。
• sql语句在写的时候注意在适当的位置断行，以增加可读性。
• 看似复杂的东西，若一步一步分析，其实也没那末难，要抓住主要逻辑，细枝末节的可适当忽略
• 改的代码和显示的程序不一致，代码在怎么改也是没有用的，此种情况出现过好几次，要长记性。此种情况多出现在打开了多了编辑器最后都不知道自己改的是那个脚本程序了。
• 工程里要有一个测试的目录
• 用数字如 1 未使用  2 使用中  3 已使用  数字一不小心就会出错，还是用单词一看意思就明白好
• 接口要有扩展性，意思是需求变了又需要新的数据，此时接口依然能再添加数据
• 数据库改动了程序也会出问题，所以大的改动一定要通知其他人
• 代码中重要的输出可以打印出来
• 要杜绝出现这种 1  2，等毫无意义的数字，尤其是在判断里if params[:sid] == "all" && @gm_order.server_all == 0 || params[:sid] != "all" && @gm_order.server_all == 2
• 用自己了解的技术+巧妙的方法去解决未知的问题，比用自己不了解的技术（不知道实现原理，难以操控，）要好
• 废除的功能的代码要及时的删除，或把废弃的代码放到文件的最底部。数据库的废弃字段也要及时清理掉，要不到后期代码会走向无序的状态。这丫的是技术债务
• 程序的前置检查（包括格式，空，有悖逻辑的等等），这样就可以在程序的源头排除一些不必要的bug，就像在编译时的那样，有错误的编译就不能通过
• 有边界情况的时候，想到后就处理掉，或用注释记录起来，要不过后就可能忘掉了
• 程序肯定会用到一些全局变量，对象，这些变量可能是配置，开关，某个全局的功能等等，而且有些十分重要。怎么维护这个全局变量就是一个问题了，最好弄个文档，按类别划分这些全局变量，以便项目参与者能更快速的了解一些全局变量
• 时刻考虑边界情况和异常情况，比如数组是否越界，被除数是否为0
• 文档说明相关：应该在服务器的根目录下弄一个文件，文件中放着一个readme文件，文件记录了服务器安装了那些软件，软件的位置，和一些有用的目录的存放的位置
• 从小事做起，然后再扩展，我一边开发一边学习，同时新掌握的信息还可以用于解决方案中。复杂系统总是源于简单系统的演化
• 尽早地添加日志记录和错误处理。在开发新系统时，我做的第一件事就是添加日志和错误处理，因为这两者从一开始就非常有用。如果系统不能照常工作，那么你就需要知道程序中发生了什么——这是日志的作用。错误处理也是如此——错误和异常越早处理越好。

一个好的后台程序需要具备哪些功能

• 记录错误，并通知到相关人员
• 监控
• 重启
• 有整个的日志

错误的容忍度的处理

编程面对的问题

编程要能通过计算机解决实际问题，比如使用什么数据结构和算法，即问题模式。
编程是人，而且是大量人来进行的，所以它还必须解决语言代码模式和复用能力的问题。即软工问题。即设计模式。
再者，编程跟语言有关，所以它必须首先解决语言复杂度问题，即语言的语法；比如 OO，即代码模式。

软件复杂度

对于软件的复杂度，唯一有效的推测方法是依据经验。而且还不是时时都好用。作为一个程序员，我知道，根据我之前开发过的相似的功能特征，我可以估计出现在的这些功能特征各自要多少开发时间。然后，我把总时间加起来，这就得到了完成整个项目需要的大致时间。然而，事实情况中，每个项目在开发过程中都遇到二、三个瓶颈。这些瓶颈会肆意的消耗程序员的大量时间，你在遇到它们之前根本不会有所预见。它们会拖住整个项目，致使工期延后数周甚至数月。
这篇经典论文的核心论述通常被解释为复杂的软件工程问题无法靠简单的答案来解决。

次要和必要复杂度
在该论述当中，讨论到了次要和必要复杂度的差异。
所谓次要复杂度是指由人们本身所产生的问题，而这类型的问题是可以被解决的。譬如说，撰写和最佳化组合语言的复杂度就是属于次要的，它可以借由高阶程序语言如Java来取代。

必要复杂度则是从软件本身要解决的问题衍生而来，并无法被移除。如果软件需要提供三十个不同的功能，那么这三十个功能都是必要的，这些功能都必须被实作出来。
软件工程面临的问题在于我们已经清除了大部分的次要复杂度，而剩余的（主要复杂度）都无法改变。
在移除次要复杂度中最大的进展也许要算是高阶语言的诞生，像是Fortran和Java。

在欧洲中世纪的传说中，有一种叫"人狼"的妖怪，就是人面狼身。它们会讲人话，专在月圆之夜去袭击人类。而且传说中对"人狼"用一般的枪弹是不起作用的，普通子弹都伤不到也打不死它，只有一种用银子作成的特殊子弹才能把它杀死。Brooks在他最著名的随笔文章《No Silver Bullet》里引用了这个典故 ，说明在软件开发过程里是没有万能的终杀性武器的，只有各种方法综合运用，才是解决之道。而各种声称如何如何神奇的理论或方法，都不是能杀死"软件危机"这头人狼的银弹。他当时大胆声称并预言方法学家们10年之内绝找不到什么极好的的神奇银弹。他的文章发表后，被广泛引用，后来他的随笔结集成书，《人月神话》。从此，在软件界，银弹（Silver Bullet）成了一个通用的比拟流行开来。1975年所出版的《人月神话》—被称为软件工程圣经。

技术债务

僵尸代码就因为各种原因如（有可能是程序库升级，老的接口不再使用。有可能是需求调整）导致的没用的、但却留在程序库中的代码。这样的代码没有任何其它程序会调用它，没有任何函数、对象引用它。
死代码是应该删除的代码。没有用的代码也就是没有人维护的代码。最后将变成没有人知道它是有什么用处的代码。后来的人也开始不敢删除这样的代码，怕万一什么地方需要用到它。于是这样的死代码积累的越来越多。技术债务越来越重。健康的项目慢慢腐烂变质。最终没有人能维护。
死代码应该及时大胆清除。即使错误了也是svn呢

源码阅读

不懂一套源程序的主要原因

• 程序的业务逻辑不清楚
• 抽象惯用法
• 语法的惯用法
• 你不知道普通的语句是体现什么样的数据结构
• 你不知道普通的语句是体现什么样的算法
• 如何向现实问题靠近抽象并设计的

源码阅读的一些技巧、方法

• 有文档的先看文档，通过看文档文章了解每个文件是干什么用的
• 如果是c的项目，可以先看看makefile或cmake文件是咋写的，以及main函数的入口在哪里
• 先找到整个项目的入口，main函数
• 总体原则，自上而下的阅读步骤
• 不知道某个函数是如何被调用的，可以打个断点，然后查看调用堆栈
• 了解代码文件的结构和用途
• 刚开始时切记一行一行的读，这样会浪费大量的时间，而且只是看懂一小块的代码，应该抓住主要的点来看，看思路，看总体流程，不要拘泥于细节
• if 的各个分支点
• 所循环的对象是什么
• 那些代码是处理错误用的，处理的又是什么错误
• 对一些函数，类，方法名可以望文生义，尽量的去猜他的含义，好的命名就应该这样的，这样可以快速提高阅读速度
• 抓住代码中的核心的 对象、变量，并跟踪其在代码中的变化
• 追踪的代码的层数不要太深，有时你只需知道这个黑箱的功能是什么，而不需要知道他的内部结构
• 追踪的代码时可以配合着程序的打印，这样可以知道代码都执行到哪里，执行了那些函数
• 断点跟踪也是一个很好的方法
• 打印关键的变量，数据结构，对象等
• 看似很长的代码可能其核心的算法和步骤就那么点，只要搞清楚核心的步骤就算读懂了大部分的代码

很多人以为看大型项目可以提升自己，而没有看到大型项目不过是几十行核心代码的扩展，很多部分是低水平重复。几十行平庸甚至晦涩的代码，重复一万次，就成了几十万行。看那些低水平重复的部分，是得不到什么提升的。造就我今天的编程能力和洞察力的，不是几百万行的大型项目，而是小到几行，几十行之短的练习。不要小看了这些短小的代码，它们就是编程最精髓的东西。反反复复琢磨这些短小的代码，不断改进和提炼里面的结构，磨砺自己的思维。逐渐的，你的认识水平就超越了这些几百万行，让人头痛的项目。

c、c++

• 若代码中出现大量的宏定义，多半是用来批量生成格式性代码的，此时只需知道宏的输入和输出是什么就行。可以通过gcc -E预编译的方法查看宏生成的内容是什么
• 阅读类的时候，先看起继承关系，然后再看起构造函数，一般构造函数中都可以得到计较重要的东西

其他小经验

3个人搭档做一个模块，每天要抽出一点时间来跟其他两位阐述自己的代码，这样可以使这三个人更加了解这个模块，也可以顺便再梳理下自己的思路，及相互监督的作用，以及完成之后可以让任何一个人来维护这个模块

项目是在原来的系统上开发的要问清客户原来的系统的优缺点，因为顾客会在新旧系统之间计较，不爽的地方会即刻发现

测试

一个函数的实现要调用另一个没用完成对函数，可以写一个假的函数来模拟

Error codes should also be accompanied by descriptive error messages. However, only in rare circumstances should the error message try to predict why the error occurred. It should simply relate what happened

开发功能的要点

主要逻辑
疑问处
数据库
程序文件
配置文件
注意点
UI
未完成
已通过
收获
线上出的问题
gm命令
时间富裕的情况下的优化
测试要点