标签：htm xpl 查询 think 公司 问题 一个 字符 sam
1.需求
没有明确的需求不要急着开始干，在需求不明确的前提下，基本上是越早开发坑越多。
2.设计稿
在此应该说是原型图，再好的需求文字描述也不如一张完整的设计图，对于后端开发，没有设计图没关系，主要是要有原型图，在原型图的设计指导下，后端开发人员可以明确接口的调用，数据库的设计，字段的返回以及逻辑的设计，这一点十分的重要。。
以上两点主要是设计和PM的职责，接下来主要说说程序员的工作
3.环境
新的软件系统是部署在新的服务器上还是旧的服务器上，新的服务器，给了你更大的控件，你可以选择更高版本的PHP开发环境，选择新的框架；但是对于旧环境来说，框架就要受限制了，同时也受PHP版本的限制。
4.数据库设计
良好的数据库设计是一个系统成功的一半，首先开始表的设计。
1. 在数据表的设计过程中，首先是表的引擎。是用MyISAM呢，还是Innodb？你知道这两个表的区别吗？——我选择了Innodb【有事务操作的选该引擎】，当数据表主要是以搜索查询为主的话，优先选择MyISAM引擎。
2. 表结构，字段的类型，如状态字段的类型选择，我选择了tinyint(1)
3. 表的命名和字段的命名，都需要按照一定的规则
4. 索引。在测试的时候经常使用explain来查看查询的效率如何
5. 备注，建表的时候写备注，方便客户端查看
5.开发
5.1 优雅的代码
框架：能让你的代码结构很整齐，我用的是Thinkphp，也是第一次使用。先找到官方的文档，记住不要一次性想把整个文档看完，我是边用边看的方式进行的。开始阶段主要看的地方是：mvc结构；
优雅的命名：不要用自己习惯的命名方式，要以框架的命名方式去编码，要不然其他coder也习惯用自己的命名方式去coding，那么代码看起来就没那么干净了。
5.2 参数校验
通过业务，你要确认，你的系统将会接受什么样的参数？
int型的是最让我舒服的，不会引起什么SQL注入，XSS问题，直接用intval强类型转换。
最让人头痛的就是字符型，考虑很多方面，SQL注入，XSS攻击等。对于SQL注入，我仔细看了一下Thinkphp的文档，只要你用数组传递参数给指定的类，你就不用担心SQL注入的问题（这也是用框架的好处）。xss攻击：利用php的htmlspecialchars， 把字符转成html结构的字符。
防止SQL注入，只需要对SQL语句进行预处理就行了。
5.3 数据库操作
1、事务:优点是插入和更新时保证数据的一致性、原子性、隔离性、持久性；但是也有一个问题，会有锁行记录的问题。
2、在更新和插入之前，你做了查询吗？就是判断是否有这条记录。
5.4 日志
1、线上代码出问题，你是怎么定位问题的？很多时候，有些问题，你是无法在开发机和测试机器上复现出来的。我的办法就是日志。
2、安全性：你的日志是否有安全漏洞（把公司内部的信息暴漏到日志里）？那你怎么控制的？——一个办法就是设置日志级别，thinkphp框架自身就有日志级别。
3、方便性：你的日志打出来之后，你能找到问题吗？
原来的做法：程序读到日志断点的位置的时候，就把日志追加到日志文件里。——问题来了，当有一些并发的时候，日志里会把很多请求的日志交错的打到文件里，查询问题非常不方便。
thinkphp给出的做法（不错的做法）：本身也有上面的做法（原来的做法）；新学到的招数是，把日志内容一行一行的放到内存里，最后结束的时候，一次性打到日志文件里。
4、错误码；
你的错误码是什么样的？你设计过吗？是否成功就0，错误就<0，错误码挨着往下出溜。最好有个统一的规范。
5.5 开发文档
你有写文档的习惯吗？很多程序员跟我说，写文档太费时间了，我个人是习惯边写代码边写文档.你的文档用什么写？我早期习惯在公司的系统上写，但是发现速度很慢，而且查某个点的时候，比较麻烦，所以我习惯用word编写。
文档有什么用?
1>是容易让我理解代码;
2>是后期维护方便;这系统不是写完了就了事的，后期还需要你维护，或者给别的程序员维护。
标签：htm xpl 查询 think 公司 问题 一个 字符 sam
原文地址：http://www.cnblogs.com/xs-yqz/p/7454743.html
