1 写工作日志。

我一直有大量写笔记的习惯。编程的时候，也经常遇到一些麻烦的问题，思路转瞬即逝，于是把所有这些思路记录下来，会在以后的搜索中成为重要的灵感来源。

我的工作日志里通常以项目为单位，包含四个重要的章节：

简介
设计
项目
日志

1.1简介

记录一个项目的概要性信息，举几个例子：

项目的负责人是谁？关联方都有哪些人？以便我遇到问题时可以迅速找到对应的人，尤其是大厂经常有跨部门合作，不认识的关联方很多，不记录一下是很难的
服务器连接信息，比如测试服务器的地址，访问URL，数据库，MQ，各种常见的调试用入口都是值得记录一下的
技术文档入口，比如公司的wiki里跟项目相关的wiki的URL

1.2设计

用来记录各种设计思路。包括把项目的各个部分进行拆解后的大模块，模块之间的接口，架构设计等等。

多个小节里记录各个部分的设计思路。尤其是经常有多种设计，可以再分一级目录来记录。每种设计都会有自己的特点，还可以开个表格做对比。比如某个方案的实现速度快，另一个方案可以利用成熟的设施，还一个方案的风险很小，一个方案很炫酷适合以后做分享等等。

这些设计的细节，使得以后寻求代码以外的思路时可以迅速的找到当初的思路。毕竟，很多技术细节，并不是仅仅依靠代码就能看懂的。

1.3 项目

项目进度管理用的，我会做个树形图，把每个工作都分拆的足够细致。并用颜色记录每个工作的完成程度。白色标识未开始，黄色是进行中，绿色完成，红色失败。有些带有一定技术风险的项目，同一个功能模块可能有几个技术方案备选，其中一些方案失败也是常态。

尤其是我用SVG图来整理整个树形图，每个节点都是可点击，通过HTML铆点到页面内工作项的具体卡片，来看这个工作项的具体描述。比如更详细的设计思路，实现过程，调研结论等等。

用树形图的方法，也就是项目管理领域常见的WBS方法。

经常是一个项目部署后还会有各个阶段的开发目标。比如功能修改。那么就可以每次子项目开一个小节，记录一下此次的需求方，需求内容等等。这样到年底要整理一年做过的事情时，就会非常有条理。

1.4日志

记录每一天的工作内容。每天一个小节，以日期为标题。

有时候做实验较多，就会在一天中开多个卡片，每个卡片对应一次实验的过程。前面是控制变量，中间是实验结果，后面是对实验结果的简单分析，以便下次实验改进。

格式与搜索
熟悉我的朋友知道，我的笔记格式是reStructuredText，编译工具是一个只有2MB的docutils。生成HTML页面，而源码通过git管理。这样整个笔记库都可以通过grep来进行高效率的搜索。这可比那些源文件是专有格式的方便太多了。

2在开始编码之前先规划和组织代码

在项目的开始阶段，不要上手直接写代码，一定要先确定代码的分层和架构。该分层和架构在一定程度上决定了未来整个项目的代码风格和维护性，对于项目的长期维护，代码架构的设计是一件非常重要的事情。
代码架构可以提供更好的可读性和可维护性。

2.1避免大块重复代码，小块也不行

一个非常好的编程习惯是确保为代码创建函数或类，以便有时重用。当你的编码过程中多次出现重复的代码块，这样很臃肿、很鸡肋，你就应该想他们是否应该封装成一个函数或类。
专门为可以反复使用的功能构建专用文件。例如，数据库调用（例如打开数据库连接，选择数据，插入数据，更新数据，删除数据和关闭连接）都应该转换为函数。通过不必重写冗余代码行，也会使你的工作变得更加容易。你需要做的就是调用该函数，简单、清洁、而且容易。

2.2使用易于阅读的命名约定

无论你正在开发什么类型的代码，命名约定都很重要。你创建的变量名称，函数名称，类名称和任何其他程序名称越人性化，你后续的开发和引用就会越容易。因为所有代码并不都是同一天写的，而且一个项目往往由很多人共同参与，好的命名约定可以大大提高编码效率，还可以降低你在同事心中的傻逼程度。

2.3注释所有代码，即使它看起来很明显

就算它写在脸上，也一定要注释、注释、注释。因为当你正在处理代码的时候，它肯定是易懂的，不然你也写不出来这样的代码。

2.4在构建时测试和调试代码

每次创建代码块时，都应该对其进行测试和调试，以确保它正常工作。不要蒙头就是写，然后写完了之后在调试，避免为了找到错误而筛选数百或数千行代码。不仅需要在构建代码时测试和调试代码，还需要确保打开所有错误报告，以便在实际操作中实际查看错误。比如PHP，你还需要确保在php.ini文件或user.ini文件中打开这些设置，该文件通常位于根目录中。