httpd.conf配置文件中加载了mod_rewrite.so模块
AllowOverride None 将None改为 All
把下面的内容保存为.htaccess文件放到应用入口文件的同级目录下
<IfModule mod_rewrite.c> RewriteEngine on RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*)$ index.php/$1 [QSA,PT,L] </IfModule> |
特别应该注意第二点，如果配置了虚拟目录，则虚拟目录也需要做同样修改，否则无法使用
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
在头文件中定义了很多POSIX.1和XSI的符号。但是除了POSIX.1和XSI的定义之外，大多数实现在这些头文件中也加上了它们自己的定义。如果在编译一个程序时，希望它只使用POSIX定义而不使用任何实现自己定义的限制，那么就需要定义常量_POSIX_C_SOURCE。所有POSIX.1头文件中都使用此常量。当定义该常量时，就能排除任何实现专有的定义。
注：POSIX.1标准的以前版本都定义了_POSIX_SOURCE常量。在POSIX.1的2001版中，它被替换为_POSIX_C_SOURCE。
常量_POSIX_C_SOURCE及_XOPEN_SOURCE被称为
功能测试宏（feature
test macro）。所有功能测试宏都以下划线开始。当要使用它们时，通常在cc命令行中以下列方式定义：
cc -D_POSIX_C_SOURCE=200112 file.c
这使得C程序包括任何头文件之前，定义了功能测试宏。如果我们仅想使用POSIX.1定义，那么也可将源文件的第一行设置为：
#define _POSIX_C_SOURCE 200112
为使Single UNIX Specification v3的功能可由应用程序使用，需将常量_XOPEN_SOURCE定义为600。
Single UNIX Specification将c99实用程序定义为C编译环境的接口。随之，就可以用如下方式编译文件：
c99 -D_XOPEN_SOURCE=600 file.c -o file
为了在gcc C编译器中启用1999 ISO C扩展，可以使用-std = c99选项，如下所示：
gcc -D_XOPEN_SOURCE=600 -std=c99 file.c -o file
另一个功能测试宏是：__STDC__,它由符合ISO C标准的C编译器自动定义。这样就允许我们编写ISO C编译器和非ISO C编译器都能编译的程序。例如，为了利用ISO C原型功能（如果支持），一个头文件可能包含：
#ifdef __STDC__ void *myfunc( const char *, int ); #else void *myfunc(); #endif |
虽然，当今的大多数C编译器都支持ISO C标准，但在很多头文件中仍旧使用__STDC__功能测试宏。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
一、至少熟悉一种嵌入式芯片架构
最适合初学者的就是arm芯片
二、uboot的使用与移植
首先要了解uboot的启动流程，根据启动顺序，进行代码的修改、编译与移植
主要参考两本书：《Linux设备驱动程序》 《Linux设备驱动开发详解》
第一本书讲理论，第二本讲实践。
在学驱动开发的时候，会涉及许多内核知识（例如内核定时器、内核链表、并发等），首先先学会使用，千万不要去看它们的实现。并且在看驱动的时候，用到那部分知识，再去查看相关的运用。
四、linux内核
此部分在学习驱动半年后，对驱动十分熟悉的情况下，再去专门的研究内核。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
网上已经有部分关于
Linux下定期备份mysql的方法，但是很多步骤不够详细，不适合新手，自己琢磨了很久，终于搞定了。
1.Linux服务器一般是ssh协议，如果本地也是Linux环境，可以直接通过shell连接，命令： ssh -l root -p 8080 202.***.***.***
其中root为用户名，一般为root，8080为端口，202.***.***.***为服务器ip地址；
接下来会提示你输入密码，输入正确后即可进入服务器；
mkdir /mysql/mysqldata_bakeup
/mysql/mysqldata_bakeup为创建的路径，可以自定义；
3.创建并编辑文件在路径 /usr/sbin/bakmysql，命令：
vi /usr/sbin/bakmysql
此时会在/usr/sbin/路径下创建bakmysql文件，并进入bakmysql编辑状态，接着输入；
fn = ` date +%Y%m%d `
tar zcvf /mysql/mysqldata_bakeup/mysql$fn.tar.gz /mysql/data
或
mysqldump -u root -ppassword /mysql/data/yourdatabase > /mysql/mysqldata_bakeup/mysql$fn.sql
find /mysql/mysqldata_bakeup/ -type f -mtime +7 -exec rm -f {} \;
/mysql/mysqldata_bakeup/为备份数据保存路径，msql$fn.tar.gz为备份数据根据日期编号的名称，/mysql/data为服务器数据库的数据路径，yourdatabase为你要备份的数据库名；
注意其中第一句命令不是单引号，而是tab键上面的符号，且date前后需要有空格；
第二句命令有两种方法，第一种直接备份并压缩数据库数据源文件，第二种是利用mysql自带命令mysqldump导出数据库yourdatabase的sql文件；
第三句是删除7天前的备份文件,mtime是文件修改时间，如果没有修改过，则为创建时间；
4.修改文件bakmysql属性，使其可执行;
chmod +x /usr/sbin/bakmysql
5.修改/etc/crontab:
vi /etc/crontab
进入编辑状态，在最下面添加：
01 3 * * * root /usr/sbin/bakmysql
01 3 是每天凌晨3:01执行 bakmysql文件；
6.关于重启有时候并不需要，如果服务器在/etc/rc.d/init.d/路径下有crond服务，可以选择重启crond，命令：
/etc/rc.d/init.d/crond restart
7.最后退出服务器命令：exit
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
数据库系统是一种管理数据的系统，首先设计到数据，谈到数据就要从数据管理的历史来看数据库系统的发展。其中，达到数据库阶段后，我们开始来讨论我们这门课程。
先来看应用部分：
1、分析数据
设计使用数据库，首先要对问题进行分析。那么数据库世界中的问题不就围绕数据开展的嘛！所以先从数据开始分析。
数据分析时，由于人们往往不能对问题的解决一步到位。所以人们对数据库的分析也是一般从宏观到微观，采用抽象的办法来对数据进行逐步细化的分析。人们在对数据抽象过程中对数据抽象不同阶段得到四种模型。
由于人们在得到四种模型过程中是通过不断细化得到的，所以这些模型也自然形成了一种层次关系。这种层次关系各自解决不同层次的问题，层次之间通过映射来联系。这种数据库结构分析好之后就该动手设计了。
2、设计数据库
要设计数据库，先整体规划好，然后弄清楚需求。有了一个比较清晰的需求，下面针对各个模型进行具体的设计。
在概念模型设计中，一个比较重要的工具是E-R图，通过E-R图可以比较直观地了解将要开发的系统。如果一个好的系统设计出来，那么自然要上手尝试一下它的魅力。
3、使用
数据库的使用最基本的是
SQL语言，单独来说SQL语言其实就是对表的增删改查。而对SQL语言扩充之后的T-SQL也就是增加了一些流程控制。数据库语言的使用学会之后，就要学会对数据库的管理了。
4、管理
使用数据库系统的前提是该系统能保证数据的正确性和安全性，要能保证这些离不开对数据库系统的管理。数据正确性最直接的是使用约束，限制数据范围。其次是通过事务机制来保证随着系统运行，数据不会发生意外损失。系统中多个事务并行进行，就要对系统进行并行控制。最后最糟糕的情况，就一定能保证恢复原来的状态。
保证了数据的正确性仍然不能满足人们的需要，因为对数据的操作是有权限的，正如我们在程序设计中使用访问控制符来限定对数据操作一样。我们要对数据的安全进行管理，防止非法的操作及意外故障对系统的破坏。
再看理论部分：
应用总是要有相应的理论来支持和指导的，这里我们按照顺序从建表的理论开始
学习，在表设计中总要有个好坏的标准吧，盲目地建表会产生许多麻烦的问题，这就提出了范式。建表有了统一的标准后，接下来就是用表了即操作表，对表有许多的操作，你讲不出为什么能这么做总不行吧。所以下面就针对表的操作来研究这些操作的理论。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
1、 对子查询的优化表现不佳。
2、 对复杂查询的处理较弱
3、 查询优化器不够成熟
4、 性能优化工具与度量信息不足
5、 审计功能相对较弱
6、 安全功能不成熟，甚至可以说很粗糙。没有用户组与角色的概念，没有回收权限的功能(仅仅可以授予权限)。当一个用户从不同的主机/网络以同样地用户名/密码登录之后，可能被当作完全不同的用户来处理。没有类似于
Oracle的内置的加密功能。
7、身份验证功能是完全内置的。不支持LDAP，Active Directory以及其它类似的外部身份验证功能。
8、
Mysql Cluster可能与你的想象有较大差异。
9、存储过程与触发器的功能有限。
10、垂直扩展性较弱。
11、不支持MPP(大规模并行处理)。
12、支持SMP(对称多处理器)，但是如果每个处理器超过4或8个核(core)时，Mysql的扩展性表现较差。
13、对于时间、日期、间隔等时间类型没有秒以下级别的存储类型。
14、可用来编写存储过程、触发器、计划事件以及存储函数的语言功能较弱。
15、没有基于回滚(roll-back)的恢复功能，只有前滚(roll-forward)的恢复功能。
16、不支持快照功能。
17、不支持
数据库链(database link)。有一种叫做Federated的存储引擎可以作为一个中转将查询语句传递到远程服务器的一个表上，不过，它功能很粗糙并且漏洞很多。
18、数据完整性检查非常薄弱，即使是基本的完整性约束，也往往不能执行。
19、优化查询语句执行计划的优化器提示非常少。
20、只有一种表连接类型：嵌套循环连接(nested-loop)，不支持排序-合并连接(sort-merge join)与散列连接(hash join)。
21、大部分查询只能使用表上的单一索引;在某些情况下，会存在使用多个索引的查询，但是查询优化器通常会低估其成本，它们常常比表扫描还要慢。
22、不支持位图索引(bitmap index)。每种存储引擎都支持不同类型的索引。大部分存储引擎都支持B-Tree索引。
23、管理工具较少，功能也不够成熟。
24、没有成熟能够令人满意的IDE工具与调试程序。可能不得不在文本编辑器中编写存储过程，并且通过往表(调试日志表)中插入记录的方式来做调试。
25、每个表都可以使用一种不同的存储引擎。
26、每个存储引擎在行为表现、特性以及功能上都可能有很大差异。
27、大部分存储引擎都不支持外键。
28、默认的存储引擎(MyISAM)不支持事务，并且很容易损坏。
29、最先进最流行的存储引擎InnoDB由Oracle拥有。
30、有些执行计划只支持特定的存储引擎。特定类型的Count查询，在这种存储引擎中执行很快，在另外一种存储引擎中可能会很慢。
31、执行计划并不是全局共享的，，仅仅在连接内部是共享的。
32、全文搜索功能有限， 只适用于非事务性存储引擎。 Ditto用于地理信息系统/空间类型和查询。
33、没有资源控制。一个完全未经授权的用户可以毫不费力地耗尽服务器的所有内存并使其崩溃，或者可以耗尽所有CPU资源。
34、没有集成商业智能(business intelligence)， OLAP 多维数据集等软件包。
35、没有与Grid Control类似的工具(http://solutions.mysql.com/go.php?id=1296&t=s)
36、没有类似于RAC的功能。如果你问”如何使用Mysql来构造RAC”，只能说你问错了问题。
37、不支持用户自定义类型或域(domain)。
38、 每个查询支持的连接的数量最大为61。
39、MySQL支持的
SQL语法(ANSI SQL标准)的很小一部分。不支持递归查询、通用表表达式（Oracle的with 语句）或者窗口函数（分析函数）。支持部分类似于Merge或者类似特性的SQL语法扩展，不过相对于Oracle来讲功能非常简单。
40、 不支持功能列(基于计算或者表达式的列，Oracle11g 开始支持计算列，以及早期版本就支持虚列(rownum，rowid))。
41、不支持函数索引，只能在创建基于具体列的索引。
42、不支持物化视图。
43、不同的存储引擎之间，统计信息差别很大，并且所有的存储引擎支持的统计信息都只支持简单的基数(cardinality)与一定范围内的记录数(rows-in-a-range)。 换句话说，数据分布统计信息是有限的。更新统计信息的机制也不多。
44、没有内置的负载均衡与故障切换机制。
45、复制(Replication)功能是异步的，并且有很大的局限性。例如，它是单线程的(single-threaded)，因此一个处理能力更强的Slave的恢复速度也很难跟上处理能力相对较慢的Master。
46、 Cluster并不如想象的那么完美。或许我已经提过这一点，但是这一点值得再说一遍。
47、数据字典(INFORMATION_SCHEMA)功能很有限，并且访问速度很慢(在繁忙的系统上还很容易发生崩溃)。
48、不支持在线的Alter Table操作。
49、不支持Sequence。
50、类似于ALTER TABLE或CREATE TABLE一类的操作都是非事务性的。它们会提交未提交的事务，并且不能回滚也不能做灾难恢复。Schame被保存在文件系统上，这一点与它使用的存储引擎无关。
我本人比较关心的几点:
1、对子查询的优化表现不佳
2、对复杂查询的处理较弱
4、性能优化工具与度量信息不足
12、支持SMP(对称多处理器)，但是如果每个处理器超过4或8个核(core)时，Mysql的扩展性表现较差。
15、没有基于回滚(roll-back)的恢复功能，只有前滚(roll-forward)的恢复功能。
18、数据完整性检查非常薄弱，即使是基本的完整性约束，也往往不能执行。
20、只有一种表连接类型:嵌套循环连接(nested-loop)，不支持排序-合并连接(sort-merge join)与散列连接(hash join)。
21、大部分查询只能使用表上的单一索引；在某些情况下，会存在使用多个索引的查询，但是查询优化器通常会低估其成本，它们常常比表扫描还要慢。
26、每个存储引擎在行为表现、特性以及功能上都可能有很大差异。
28、默认的存储引擎(MyISAM)不支持事务，并且很容易损坏。
30、有些执行计划只支持特定的存储引擎。特定类型的Count查询，在这种存储引擎中执行很快，在另外一种存储引擎中可能会很慢。
31、执行计划并不是全局共享的，仅仅在连接内部是共享的。
33、没有资源控制。一个完全未经授权的用户可以毫不费力地耗尽服务器的所有内存并使其崩溃，或者可以耗尽所有CPU资源。
45、复制(Replication)功能是异步的，并且有很大的局限性。例如，它是单线程的(single-threaded)，因此一个处理能力更强的Slave的恢复速度也很难跟上处理能力相对较慢的Master。
46、Cluster并不如想象的那么完美。或许我已经提过这一点，但是这一点值得再说一遍。
47、数据字典(INFORMATION_SCHEMA)功能很有限，并且访问速度很慢(在繁忙的系统上还很容易发生崩溃)。
48、不支持在线的Alter Table操作。
50、类似于ALTER TABLE或CREATE TABLE一类的操作都是非事务性的。它们会提交未提交的事务，并且不能回滚也不能做灾难恢复。Schame被保存在文件系统上，这一点与它使用的存储引擎无关。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
有时候为了方便操作程序的开发，需要将汉字转为拼音等操作。下面这个是自己结合网上的资料，加上自己在公司项目中的亲自实践。完整的实现了将汉字转为拼音的操作。这个Demo只是负责将其转换，在main方法中
测试，在实际需要中，只需要调用这个类中的方法即可。
首先贴出测试结果：
测试参数：
汉字转换为拼音
汉字转换为拼音
main测试方法的代码：
1 public static void main(String[] args) {
2 System.out.println(ToFirstChar("汉字转换为拼音").toUpperCase()); //转为首字母大写
3 System.out.println(ToPinyin("汉字转换为拼音"));
4 }
本功能的实现时利用
java开源库，开发此程序需要一个jar包。本人用的是pinyin4j-2.5.0.jar。网上可以直接下载，也可以在其官网进行下载。在此不祥述。如果实在不乐意，可以点击下载将进行这个jar包的下载。
贴出实现该Demo的源码：
1 package com.red.test; 2 3 import net.sourceforge.pinyin4j.PinyinHelper; 4 import net.sourceforge.pinyin4j.format.HanyuPinyinCaseType; 5 import net.sourceforge.pinyin4j.format.HanyuPinyinOutputFormat; 6 import net.sourceforge.pinyin4j.format.HanyuPinyinToneType; 7 import net.sourceforge.pinyin4j.format.exception.BadHanyuPinyinOutputFormatCombination; 8 9 /** 10 * 汉字转换为拼音 11 * @author Red 12 */ 13 public class PinyinDemo { 14 /** 15 * 测试main方法 16 * @param args 17 */ 18 public static void main(String[] args) { 19 System.out.println(ToFirstChar("汉字转换为拼音").toUpperCase()); //转为首字母大写 20 System.out.println(ToPinyin("汉字转换为拼音")); 21 } 22 /** 23 * 获取字符串拼音的第一个字母 24 * @param chinese 25 * @return 26 */ 27 public static String ToFirstChar(String chinese){ 28 String pinyinStr = ""; 29 char[] newChar = chinese.toCharArray(); //转为单个字符 30 HanyuPinyinOutputFormat defaultFormat = new HanyuPinyinOutputFormat(); 31 defaultFormat.setCaseType(HanyuPinyinCaseType.LOWERCASE); 32 defaultFormat.setToneType(HanyuPinyinToneType.WITHOUT_TONE); 33 for (int i = 0; i < newChar.length; i++) { 34 if (newChar[i] > 128) { 35 try { 36 pinyinStr += PinyinHelper.toHanyuPinyinStringArray(newChar[i], defaultFormat)[0].charAt(0); 37 } catch (BadHanyuPinyinOutputFormatCombination e) { 38 e.printStackTrace(); 39 } 40 }else{ 41 pinyinStr += newChar[i]; 42 } 43 } 44 return pinyinStr; 45 } 46 47 /** 48 * 汉字转为拼音 49 * @param chinese 50 * @return 51 */ 52 public static String ToPinyin(String chinese){ 53 String pinyinStr = ""; 54 char[] newChar = chinese.toCharArray(); 55 HanyuPinyinOutputFormat defaultFormat = new HanyuPinyinOutputFormat(); 56 defaultFormat.setCaseType(HanyuPinyinCaseType.LOWERCASE); 57 defaultFormat.setToneType(HanyuPinyinToneType.WITHOUT_TONE); 58 for (int i = 0; i < newChar.length; i++) { 59 if (newChar[i] > 128) { 60 try { 61 pinyinStr += PinyinHelper.toHanyuPinyinStringArray(newChar[i], defaultFormat)[0]; 62 } catch (BadHanyuPinyinOutputFormatCombination e) { 63 e.printStackTrace(); 64 } 65 }else{ 66 pinyinStr += newChar[i]; 67 } 68 } 69 return pinyinStr; 70 } 71 } |
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
因为不想导入Log4j的jar，项目只是
测试一些东西，因此选用了JDK 自带的Logging，这对于一些小的项目或者自己测试一些东西是比较好的选择。
Log4j中是通过log4j.properties这个配置文件控制日志的输出，
java logging中是通过logging.properties文件完成类似的功能。
Logging.properties文件位于JDK安装路径的 jre/lib/目录下,直接上配置文件:
handlers= java.util.logging.ConsoleHandler .level= INFO java.util.logging.FileHandler.pattern = %h/java%u.log java.util.logging.FileHandler.limit = 50000 java.util.logging.FileHandler.count = 1 java.util.logging.FileHandler.formatter = java.util.logging.XMLFormatter java.util.logging.ConsoleHandler.level = INFO java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter |
既想要输入在控制台，又想要收入在文件中，如下进行设置。
handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler
log文件的格式要求设置如下行:
java.util.logging.FileHandler.pattern = %h/java%u.log
具体的表示如何定义，可以查看java logging format api 进行设置。
通过上述设置就可以实现将日志输入到指定文件的要求了。但是有时候只是希望某些类的文件输出到制定，这样调试起来更清晰些，为了实现个要求还要再进行些设置。
com.jason.logger.LoggerDemo.level = ALL
com.spt.logger.LoggerDemo.handlers = java.util.logging.FileHandler
“com.spt.logger.LoggerDemo”是“Logger”的名字，它要和代码中指定的Logger相匹配。
c程序使用中，代码如下:
private static Logger log = Logger.getLogger(LoggerDemo.class.getName());
对了，还忘记了logging 的几个级别做一下介绍:
SEVERE (最高级别)
WARNING
INFO
CONFIG
FINE
FINER
FINEST (最低级别)
简单的使用这些已经足够了，再复杂的使用，个人感觉就要上log4j 了。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
最近在与一位总经理交流的时候，他谈到他们公司的软件研发管理，说：“我们公司最大的问题是项目不能按时完成，总要一拖再拖。”他问我有什么办法能改变这个境况。从这样一个问题开始，在随后的交谈中，又引出他一连串在软件研发管理中的遇到的问题，包括：
. 现有代码质量不高，新来的开发人员接手时宁愿重写，也不愿意看别人留下的“烂”代码，怎么办？
. 重构会造成回退，怎样避免？
. 有些开发人员水平相对不高，如何保证他们的代码质量？
. 软件研发到底需不需要文档？
. 要求提交代码前做Code Review，而开发人员不做，或敷衍了事，怎么办？
. 当有开发人员在开发过程中遇到难题，
工作无法继续，因而拖延进度，怎么解决？
. 如何提高开发人员的主观能动性？
其实，每个软件研发团队的管理者都面临着或曾经面临过这些问题，也都有着自己的管理“套路”来应对这些问题。我把我的“套路”再此絮叨絮叨。
1. 项目不能按时完成，总要一拖再拖，怎么改变？
找解决办法前，当然要先知道问题为什么会出现。这位总经理说：“总会不断地有需求要改变和新需求提出来，使原来的开发计划不得不延长。”原来如此。知道根源，当然解决办法也就有了，那就是“
敏捷”。敏捷开发因其迭代（Iterative）和增量（Incremental）的思想与实践，正好适合“需求经常变化和增加”的项目和产品。在我讲述了敏捷的一些概念，特别是Scrum的框架后，总经理也表示了对“敏捷”的认同。
其实仔细想想，这里面还有一个非常普遍的问题。对于产品的交付时间或项目的完成时间，往往由高级管理层根据市场情况决策和确定。在很多软件企业中，这些决策者在决策时往往忽略了一个重要的参数，那就是团队的生产率（Velocity）。生产率需要量化，而不是“拍脑门子”感觉出来的。敏捷开发中有关于如何估算生产率的方法。所以使用敏捷，在估算产品交付时间或项目完成时间时，是相对较准确的。Scrum创始人之一的Jeff Sutherland说，他在一个风险投资团队做敏捷教练时，团队中的资深合伙人会向所有的待投资企业问同一个问题：“你们是否清楚团队的生产率？”而这些企业都很难做出明确的答复。软件企业要想给产品定一个较实际的交付日期，就首先要弄清楚自己的软件生产率。
2. 现有代码质量不高，新来的开发人员接手时宁愿重写，也不愿意看别人留下的“烂”代码，怎么办？
这可能是很多
软件开发工程师都有过的体验，在接手别人的代码时，看不懂、无法加新功能，读代码读的头疼。这说明什么？排除接手人个人水平的因素，这说明旧代码可读性、可扩展性比较差。怎么办？这时，也许重构是一种两全其美的办法。接手人重构代码，既能改善旧代码的可读性和可扩展性，又不至于因重写代码带来的时间上的风险。
从接手人心理的角度看，重构还有一个好的副作用，就是代码重构之后，接手人觉得那些原来的“烂”代码被修改成为自己引以自豪的新成就。《Scrum敏捷软件开发》的作者Mike Cohn写到过：“我的女儿们画了一幅特别令人赞叹的杰作后，她们会将它从学校带回家，并想把它展示在一个明显的位置，也就是冰箱上面。有一天，在工作中，我用C++代码实现了某个特别有用的策略模式的程序。因为我认定冰箱门适合展示我们引以为豪的任何东西，所以我就将它放上去了。如果我们一直对自己工作的质量特别自豪，可以骄傲地将它和孩子的艺术品一样展示在冰箱上，那不是很好吗？”所以这个积极的促进作用，将使得接手人感觉修改的代码是自己的了，而且期望能够找到更多的可以重构的东西。
3. 重构会造成回退，怎样避免？
重构确实很容易造成回退（Regression）。这时，重构会起到与其初衷相反的作用。所以我们应该尽可能多地增加
单元测试。有些老产品，旧代码，可能没有或者没有那么多的单元测试。但我们至少要在重构前，增加对要重构部分代码的单元测试。基于重构目的的单元测试，应该遵循以下的原则（见《重构》第4章：构筑测试体系）：
- 编写未臻完善的测试并实际运行，好过对完美测试的无尽等待。测试应该是一种风险驱动行为，所以不要去测试那些仅仅读写一个值域的访问函数，应为它们太简单了，不大可能出错。
- 考虑可能出错的边界条件，把测试火力集中在哪儿。扮演“程序公敌”，纵容你心智中比较促狭的那一部分，积极思考如何破坏代码。
- 当事情被公认应该会出错时，别忘了检查是否有异常如期被抛出。
- 不要因为“测试无法捕捉所有
Bug”，就不撰写测试代码，因为测试的确可以捕捉到大多数Bug。
- “花合理时间抓出大多数Bug”要好过“穷尽一生抓出所有Bug”。因为当测试数量达到一定程度之后，测试效益就会呈现递减态势，而非持续递增。
说到《重构》这本书，其实在每个重构方法中都有“作法（Mechanics）”一段，在重构的实践中按照上面所述的步骤进行是比较稳妥的，同时也能避免很多不经意间制造的回退出现。 4. 要求提交代码前做Code Review，而开发人员不做，或敷衍了事，怎么办？
如果每个开发人员都是积极主动的，Code Review的作用能落到实处。但如果不是呢？团队管理者需要一些手段促使其有效地进行Code Review。首先，我们采用的Code Review有2种形式，一是Over-the-shoulder，也就是2个人座在一起，一个人讲，另一个人审查。二是用工具Code Collaborator来进行。无论哪种形式，在提交代码时，必须注明关于审查的信息，比如：审查者（Reviewer）的名字或审查号（Review ID，Code Collaborator自动生成），每天由一名专职人员来检查Checklist中的每一条，看是否有人漏写这些信息，如果发现会提醒提交的人补上。另外，某段提交的代码出问题，提交者和审查者都要一起来解决出现的问题，以最大限度避免审查过程敷衍了事。
博主Inovy在某个评论说的很形象：“木（没）有赏罚的制度，就是带到厕所的报纸，看完就可以用来擦屁股了。”没有奖惩制度作保证，当然上面的要求没有什么效力。所以，当有人经常不审查就提交，或审查时不负责任，它的绩效评定就会因此低一点，而绩效的评分是跟每年工资涨落挂钩的。说白了，可能某个人会因为多次被查出没有做Code Review就提交代码，而到年底加薪时比别人少涨500块钱。
5. 软件研发到底需不需要文档？
软件研发需要文档的起原可能有2种，一是比较原始的，需要文档是为了当开发人员离职后，企业需要接手的人能根据文档了解他所接手的代码或模块的设计。二是较高层次的，企业遵从ISO9001质量管理体系或CMMI。
对于第一种，根源可能来自于两个方面：
- 原开发人员设计编码水平不高，其代码可读性较差。
- 设计思想和代码只有一个人了解，此人一旦离职，无人知道其细节。
在编码前写一些简单的设计文档，有助于理清思路，尤其是辅以一些UML图，在交流时也是有好处的。但同时，我们也应该提高开发人员的编码水平增加其代码的可读性，比如增强其变量命名的可读性、用一些被大家所了解的设计模式来替代按自己某些独特思路编写的代码、增加和改进注释等等，以减少不必要的文档。另外推行代码的集体所有权（Collective Ownership），避免某些代码只被一个人了解，这样可以减少以此为目的而编写的文档。
对于第二种，情况有些复杂。接触过敏捷开发的人都知道《敏捷宣言》中的“可以工作的软件胜于面面俱到的文档”。接触过CMMI开发或者ISO9001质量管理体系的人知道它们对文档的要求是多么的高。它们看起来水火不相容。但是，它们的宗旨是一致的，即：构建高质量的产品。
对于敏捷，使用手写用户故事来记录需求和优先级的方法，以及在白板上写画的非正式设计，是不能通过ISO9001的审核的，但当把它们复印、拍照、增加序号、保存后，可以通过审核。每次都是成功的Daily Build和Auto Test报告无法证明它们是否真正被执行并真正成功，所以不能通过ISO9001的审核。但添加一个断言失败（类似assert(false)的断言）的测试后，则可以通过审核。
CMMI与敏捷也是互补的，前者告诉组织在总体条款上做什么，但是没有说如何去做，后者是一套最佳实践。SCRUM之类的敏捷方法也被引入过那些已通过CMMI5级评估的组织。很多企业忘记了最终目标是改进他们构建软件及递交产品的方式，相反，它们关注于填写按照CMMI文档描述的假想的缺陷，却不关心这些变化是否能改进过程或产品。
所以敏捷开发在过程中只编写够用的文档，和以“信息的沟通、符合性的证据以及知识共享”作为主要目标的质量体系文档要求并不矛盾。在实践中，我们可以按以下方法做，在实现SCRUM的同时，符合审核和评估的要求：
- 制作格式良好的、被细化的、被保存的和能跟踪的Backlog。复印和照片同样有效。
- 将监管需要的文档工作也放入Backlog。除了可以确保它们不被忘记，还能使监管要求的成本是可见的。
- 使用检查列表，以向审核员或评估员证明活动已执行。团队对“完成”的定义(Definition of “Done”)可以很容易转变为一份检查列表。
- 使用敏捷项目管理工具。它其实就是开发程序和记录的电子呈现方式。
总而言之，软件研发需要文档（但文档的形式可以是多种多样的，用Word写的文字式的文件是文档，用Visio画的UML图也是文档，保存在Quality Center中的测试用例也是文档），同时我们只需写够用的文档。
6. 当有开发人员在开发过程中遇到难题，工作无法继续，因而拖延进度，怎么解决？
这也是个常遇到的问题。如果管理者对于某个工程师的具体问题进行指导，就会陷入过度微观管理的境地。我们需要找到宏观解决办法。一，我们基于Scrum的“团队有共同的目标”这一规则，利用前面提到的集体所有权，当出现这些问题时，用团队中所有可以使用的力量来帮助其摆脱困境，而不是任其他人袖手旁观。当然这里会牵扯到绩效评定的问题，比如：提供帮助的人会觉得，他的帮助无助于自己绩效评定的提高，为什么要提供帮助。这需要人力资源部门在使用Scrum开发的团队的绩效评估中，尽量消除那些倾向个人的因素，还要包含团队协作的因素，广泛听取个方面的意见，更频繁地评估绩效等等。
二，即使动用所有可以使用的力量，如果某个难题真的无法逾越，为了减少不能按时交付的风险，产品负责人应当站出来，并有所作为。要么重新评估Backlog的优先级，使无法继续的Backlog迟一点交付，先做一些相对较低优先级的Backlog，以保证整体交付时间不至于延长；要么减少部分功能，给出更多的时间去攻克难题。总之逾越技术上难关会使团队的生产率下降，产品负责人必须作出取舍。
7. 有些开发人员水平相对不高，如何保证他们的代码质量？
当然首先让较有经验的人Review其要提交的代码，这几乎是所有管理者会做的事。除此之外，管理者有责任帮助这些人（也包括水平较高的人）提高水平，他们可以看一些书，上网看资料，读别人的代码等等，途经还是很多的。但问题是你如何去衡量其是否真正有所收获。我们的经验是，在每年大约3月份为每个工程师制定整个年度的目标，每个人的目标包括产品上的，技术上的，个人能力上的等4到5项。半年后和一年后，要做两次Performance Review，目标是否实现，也会跟绩效评定挂钩。我们在制定目标时，遵循SMART原则，即：
Specific（明确的）：目标应该按照明确的结果和成效表述。
Measurable（可衡量的）：目标的完成情况应该可以衡量和验证。
Aligned（结盟的）：目标应该与公司的商业策略保持一致。
Realistic（现实的）：目标虽然应具挑战性，但更应该能在给定的条件和环境下实现。
Time-Bound（有时限的）：目标应该包括一个实现的具体时间。
比如：某个人制定了“初步掌握本地化技术”的目标，他要确定实现时间，要描述学习的途经和步骤，要通过将技术施加到公司现有的产品中，为公司产品的本地化/国际化/全球化作一些探索，并制作Presentation给团队演示他的成果，并准备回答其他人提出的问题。团队还为了配合其实现目标，组织Tech Talk的活动，供大家分享每个人的学习成果。通过这些手段，提高开发人员的自学兴趣，并逐步提高开发人员的技术水平。
8. 如何提高开发人员的主观能动性？
提高开发人员的主观能动性，少不了激励机制。不能让开发人员感到，5年以后的他和现在比不会有什么进步。你要让他感到他所从事的是一个职业（Career），而不只是一份工作（Job）。否则，他们是不会主动投入到工作中的。我们的经验是提供一套职业发展的框架。框架制定了2类发展道路，管理类（Managerial Path）和技术类（Technical Path），6个职业级别（1-3级是Entry/Associate，Intermediate，Senior。4级管理类是Manager/Senior Manager，技术类是Principal/Senior Principal。5级管理类是Director/Senior Director，技术类是Fellow/Architect。6级是Executive Management）。每个级别都有13个方面的具体要求，包括：范围（Scope）、跨职能（Cross Functional）、层次（Level）、知识（Knowledge）、指导（Guidance）、问题解决（Problem Solving）、递交成果（Delivering Result）、责任感（Responsbility）、导师（Mentoring）、交流（Communication）、自学（Self-Learning），运作监督（Operational Oversight），客户响应（Customer Responsiveness）。每年有2次提高级别的机会，开发人员一旦具备了升级的条件，他的Supervisor将会提出申请，一旦批准，他的头衔随之提高，薪水也会有相对较大提高。从而使每个开发人员觉得“有奔头”，自然他们的主观能动性也就提高了。
上面的“套路”涉及了软件研发团队管理中的研发过程、技术实践、文档管理、激励机制等一些方面。但只是九牛一毛，研发团队管理涵盖的内容还有很多很多，还需要管理者在不断探索和实践的道路上学习和掌握。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters
软件产品的质量定义始终都是满足要求和适合使用，高质量和高等级是有区别的。软件质量目标应该来源于商业目标驱动，商业目标决定了软件的价值。提高软件质量的目标仍然是为了盈利和创造更大的效益，而不是创造完美无缺的产品。
软件产品质量不是靠
测试和评审出来的，而是靠设计出来的。关注软件项目中的好质量成本和坏质量成本可以宏观的看到项目软件
质量管理的水平。对于软件项目COQ一般在35%-55%，而坏质量成本一般在8-15%，这也说明我们要尽量减少返工，争取第一次就把事情做对。
1.软件的质量属性和质量要素
PMBOK中质量的定义是符合要求和适合使用。CMM对质量的定义是一个系统，组件或过程符合客户或用户的要求或期望的程度。因此可以讲质量更多不是研发者说的，而是用户的最终感受。
通过类比，我们这样理解软件质量：软件质量是许多质量属性的综合体现，各种质量属性反映了软件质量的方方面面。人们通过改善软件的各种质量属性，从而提高软件的整体质量（否则无从下手）。
软件的质量属性很多，如正确性、精确性，健壮性、可靠性、容错性、性能、易用性、安全性、可扩展性、可复用性、兼容性、可移植性、可测试性、可维护性、灵活性等。这些质量属性又可以分为功能性和非功能性两大类。
功能性质量要素:正确性，健壮性，可靠性
非功能性质量因素：性能，易用性，安全性，可扩展性，兼容性，可移植性
a.正确性:第一重要，机器不会欺骗人，软件运行错误都是人为造成的。
b.健壮性:包括容错能力和恢复能力，开发过程中应该充分考虑各种异常和边界。
c.可靠性:可靠性是指在一定的环境下，在给定的时间内，系统不发生故障的概率。
d.性能：性能通常是指软件的“时间-空间”效率，而不仅是指软件的运行速度。(性能问题解决根本还是算法和程序的优化，而不是期待硬件的更高配置)
e.易用性:易用性是指用户使用软件的容易程度。(界面友好仅仅是一方面，还包括人机工程很多内容)
f.安全性:安全性是指防止系统被非法入侵的能力
g.扩展性:反映了软件应对变化的能力
h.兼容性:对硬件的兼容，对软件的兼容
非功能性需求是软件质量重要组成，是架构设计和软件产品化的重要考虑，但往往容易被忽视。特别是在开发通用性的产品的时候，非功能性质量要素必须要考虑全面。
什么是质量要素，应该理解为能够提高用户满意度和提高产品核心竞争力和价值的质量属性。如果某些质量属性并不能产生显著的经济效益，我们可以忽略它们，把精力用在对经济效益贡献最大的质量要素上。简而言之，只有质量要素才值得开发人员下功夫去改善。
2.商业目标决定质量目标
重视软件质量是应该的，但是“质量越高越好”并不是普适的真理。只有极少数软件应该追求“零缺陷”，对绝大多数软件而言，商业目标决定了质量目标，而不该把质量目标凌驾于商业目标之上。
企业的根本目标是为了获取尽可能多的利润，而不是生产完美无缺的产品。如果企业销售出去的软件的质量比较差，轻则挨骂，重则被退货甚至被索赔，因此为了提高用户对产品的满意度，企业必须提高产品的质量。但是企业不可能为了追求完美的质量而不惜一切代价，当企业为提高质量所付出的代价超过销售收益时，这个产品已经没有商业价值了，还不如不开发。
企业必须权衡质量、效率和成本，产品质量太低了或者太高了，都不利于企业获取利润。企业理想的质量目标不是“零缺陷”，而是恰好让广大用户满意，并且将提高质量所付出的代价控制在预算之内。
3.质量保证能够保证质量吗
软件质量保证（Quality Assurance）的目的是为管理者提供有关软件过程和产品的适当的可视性。它包括评审和审核软件产品及其活动，以验证其是否遵守既定的规程和标准，并向有关负责人汇报评审和审核的结果。
简而言之，质量保证活动就是检查软件项目的“
工作过程和工作成果”是否符合既定的规范。如此简单的活动为什么被冠以“质量保证”这等份量的术语呢？没有历史典故，经我考究，猜想是源于一个天真的假设：
过程质量与产品质量存在某种程度的因果关系，通常“好的过程”产生“好的产品”，而“差的过程”将产生“差的产品”。假设企业已经制定了软件过程规范，如果质量保证人员发现某些项目的“工作过程以及工作成果”不符合既定的规范，那么马上可以断定产品存在缺陷。反之，如果质量保证人员没有发现不符合既定规范的东西，那么也可以断定产品是合格的。
符合既定规范的东西并不意味着质量一定合格，仅靠规范无法识别出产品中可能存在的大量缺陷.
4.全面软件质量管理模型
提高软件质量最好的办法是：在开发过程中有效地防止工作成果产生缺陷，将高质量内建于开发过程之中。主要措施是“不断地提高技术水平，不断地提高规范化水平”，其实就是练内功，通称为“软件过程改进”。
其次方法是当工作成果刚刚产生时马上进行质量检查，及时找出并消除工作成果中的缺陷。这种方式效果比较好，人们一般都能学会。最常用的方法是技术评审、
软件测试和过程检查，已经被企业广泛采用并取得了成效。
最差的是在软件交付之前，没有及时消除缺陷。当软件交付给用户后，用着用着就出错了，赶紧请开发者来补救。可笑的是，当软件系统在用户那里出故障了，那些现场补救成功的人倒成了英雄，好心用户甚至还寄来感谢信。
谁对软件质量负责？是全员负责。任何与软件开发、管理工作相关的人员都对质量产生影响，都要对质量负责。所以人们不要把质量问题全部推出质量人员或测试人员。
谁对软件质量负最大的责任？谁的权利越大，他所负的质量责任就越大。质量人员是成天与质量打交道的人，但他个人并不对产品质量产生最大的影响，所以也不负最大的责任。
质量人员的主要职责：
1.负责制定质量计划（很重要但是工作量比较少）；
2.负责过程检查（类似于CMM中的质量保证），约占个人工作量的20%；
3.参与技术评审，约占个人工作量的30%；
4.参与软件测试，约占个人工作量的30%；
5.参与软件过程改进（面向整个机构），约占个人工作量的20%；
质量管理计划的主要内容（模板见word文件）：
1. 质量要素分析
2. 质量目标
3. 人员与职责
4. 过程检查计划
5. 技术评审计划
6. 软件测试计划
7. 缺陷跟踪工具
8. 审批意见
5.技术评审
技术评审（Technical Review, TR）的目的是尽早地发现工作成果中的缺陷，并帮助开发人员及时消除缺陷，从而有效地提高产品的质量。技术评审最初是由IBM公司为了提高软件质量和提高程序员生产率而倡导的。技术评审方法已经被业界广泛采用并收到了很好的效果，它被普遍认为是软件开发的最佳实践之一。
技术评审的主要好处有：
1.通过消除工作成果的缺陷而提高产品的质量；
2.技术评审可以在任何开发阶段执行，不必等到软件可以运行之际，越早消除缺陷就越能降低开发成本；
3.开发人员能够及时地得到同行专家的帮助和指导，无疑会加深对工作成果的理解，更好地预防缺陷，一定程度上提高了开发生产率。
技术评审有两种基本类型：
1.正式技术评审FTR。FTR比较严格，需要举行评审会议多。
2.非正式技术评审ITR。ITR的形式比较灵活，通常在同伴之间开展，不必举行评审会
技术评审和软件测试的目的都是为了消除软件的缺陷，两者的主要区别是：
1.前者无需运行软件，评审人员和作者把工作成果摆放在桌面上讨论；
2.而后者一定要运行软件来查找缺陷。技术评审在软件测试之前执行，尤其是在需求开发和系统设计阶段。
相比而言，软件测试的工作量通常比技术评审的大，发现的缺陷也更多。在制定质量计划的时候，已经确定了本项目的主要测试活动、时间和负责人，之后再考虑软件测试的详细计划和测试用例。
如果机构没有专职的软件测试人员的话，那么开发人员可以兼职做测试工作。当项目开发到后期，过程检查和技术评审都已经没有多少意义了，开发小组急需有人帮助他们测试软件，如果质量人员参与软件测试，对开发小组而言简直就是“雪中送炭”。
强调：质量人员一定要参与软件测试（大约占其工作量的30％左右），只有这样他才能深入地了解软件的质量问题，而且给予开发小组强有力地帮助。
CMM和ISO9001所述的软件质量保证，实质就是过程检查，即检查软件项目的“工作过程和工作成果”是否符合既定的规范。
“过程检查”这个词虽然没有质量保证那么动听，但是其含义直接明了，不会让人误解。为了避免人们误以为“质量保证”能够“保证质量”，我提议用“过程检查”取代质量保证这个术语。
虽然本章批判了“质量保证”的浮夸，但是并没有全盘否定质量保证的好处。过程检查对提高软件质量是有帮助的，只是它的好处没有象质量保证鼓吹的那么好而已。
符合规范的工作成果不见得就是高质量的，但是明显不符合规范的工作成果十有八九是质量不合格的。例如版本控制检查,再例如，机构制定了重要工作成果的文档模板（例如需求规格说明书、设计报告等），要求开发人员写的文档尽可能符合模板。如果质量人员发现开发人员写的文档与机构的模板差异非常大，那么就要搞清楚究竟是模板不合适？还是开发人员偷工减料？
过程检查的要点是：找出明显不符合规范的工作过程和工作成果，及时指导开发人员纠正问题，切勿吹毛求疵或者在无关痛痒的地方查来查去。
不少机构的质量人员并没有真正理解过程检查的意义，老是对照规范，查找错别字、标点符号、排版格式等问题，迷失了方向，这样只有疲劳没有功劳，而且让开发人员很厌烦。
对于中小型项目而言，过程检查工作由质量人员一个人负责就够了，约占其20％的工作量，让质量人员抽出更多的时间从事技术评审和软件测试工作。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters