Table of Contents:

学习时注意细节：包括推论的关键步骤，单词的拼写，代码的格式，

名言

 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"
 代码应写一点测一点。便于调试。先简单再复杂，循环迭代。
 var_dump对调试打印复杂类型很有用。
 时刻备份。
 建一个专用于测试的文件，小的函数，对象可在此测试，因为在大项目中不好看到其效果。
 案头准备几本便签用于记录。a、工作计划  b、关于项目的笔记本 c、编写代码的草稿本 d、关于知识的笔记本
 文件的编码要注意
 sql语句用之前先试一试，字符型的要加引号，numeric fields should not be enclosed in quotes:
 研究源代码时，碰到非常复杂的，可以用简单的代码进行测试。
 网上的一些技术文章有的是过时的，想了解最新的就得去官网上看，英文的也要看
 有的时候页面改了之后还是没变化，可增加输出强制刷新，添个alert
 写前端代码时出现奇怪的现象了就多用几个浏览器试试，可能是浏览器的问题
 写代码时可能会配合的画一些流程图之类的图，注意不同图形不同符号要代表不同的含义
 代码的边界处很容易出错，要多加注意
 php手册中有很多用户的代码的例子，很好，可作为一种代码资源
 使用软件一定要查看其版本，以及版本之间的兼容性
 编程的一个思路（数据结构加算法）：分析程序需要哪些数据，比如展示给用户的数据，得以让程序运行的数据，标记数据，等。再去想用什么形式结构去储存数据。
* 用php获得用户ip光用 $_SEVER['REMOTE_ADDR'];可能是不行的。还需考虑其他很多情况。
 sql语句在写的时候注意在适当的位置断行，以增加可读性。
 phpmyadmin有次变的非常的慢，最后才知道原来是xdebug安装之后才变的这么慢，去掉之后就好了，结论，xdebug很耗性能
 看似复杂的东西，若一步一步分析，其实也没那末难，要抓住主要逻辑，细枝末节的可适当忽略
 改的代码和显示的程序不一致，代码在怎么改也是没有用的，此种情况出现过好几次，要长记性。此种情况多出现在打开了多了编辑器最后都不知道自己改的是那个脚本程序了。
 创建项目时要先设置字符集，这是一个好习惯
 工程里要有一个测试的目录
 用数字如 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个人搭档做一个模块，每天要抽出一点时间来跟其他两位阐述自己的代码，这样可以使这三个人更加了解这个模块，也可以顺便再梳理下自己的思路，及相互监督的作用，以及完成之后可以让任何一个人来维护这个模块

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