今天一早发现Ubuntu 12.04坏掉了，于是用了大半天对其做了修复，修复过程十分坎坷，但结果还不错，遂记之以备忘。

* 毁掉Ubuntu

Ubuntu坏掉完全是由于我的错误决策。昨天一天Ubuntu桌面右上方的状态拦一直有一个红色的错误提示符，提示系统包冲突，建议执行sudo apt-get install -f解决。apt-get也提示索引冲突，无法卸载和安装任何包。于是执行了sudo apt-get install -f，虽然我不知道这个命令对系统做了哪些更改。但结果是那个错误提示符的确不见了。

不过等到晚上回家启动电脑后才发现笔记本的快捷键都不好用了。比如无法通过fn+f6 or f7对屏幕亮度进行调节（默认启动时是最大亮度，太刺眼，每次都要调）。更要命的是声音快捷键居然不好用了，而且其为关闭状态。并且状态栏上到小喇叭也无 法点击，“系统设置->声音”也根本打不开。没有声音，如何听歌看电影啊，于是乎想到了upgrade。

执行upgrade，有400多M的包要升级，于是让电脑自己升级，我去睡觉去了。今天早上起来发现Ubuntu upgrade ok了。重启、引导，似乎一切似乎很正常。但输入密码登录后，画面就始终停留在墙纸背景上了。啥都没有出现。快捷键依旧无法使用，反复重启几次均如此，超 级杯具了！

* 重装Ubuntu

上班后，试图用livecd引导修复Ubuntu，但ubuntu没有修复菜单选项，要么删除当前已经安装的ubuntu 12.04.2并重新安装，丢弃HOME路径下的数据；要么就是保持现有版本OS不动，新安装一个OS，原OS HOME路径下的数据不会有损失。我只能选择后者。这时我才发现，livecd在我的笔记本中发现的已有OS版本居然变成了ubuntu 12.10！靠，upgrade居然直接将12.04.2升级到了12.10。

原12.04.2安装在/dev/sda1分区，livecd将该分区拆分成两个分区，有点类似于Win7高级磁盘分区工具中对大分区的压缩，压缩后变成安装了老系统的/dev/sda1和新分区/dev/sda10，livecd在/dev/sda10上面安装新系统。

新Ubuntu很快就安装好了，重启后顺利的进入了桌面，一切正常。接下来又是老一套，恢复数据+装软件。

* 自动挂接各分区

由于采用的是默认安装，没有自定义挂接点，于是需要手工编写/etc/fstab文件，将诸多分区做自定义挂接，使之能在系统启动时自动挂接。
首先执行sudo blkid，查看各分区信息：

$> sudo blkid
/dev/sda1: UUID="d0d1424b-e3a8-43d9-887a-1c58c64ecff3" TYPE="ext3"
/dev/sda5: UUID="8bda8d60-b5cb-43aa-b408-dd6ce4957923" TYPE="ext3"
/dev/sda6: UUID="c415cf1c-624c-42ce-a8a6-6c072b5ee232" TYPE="ext3"
/dev/sda7: UUID="b8f6c810-bbb0-458c-8306-7b4a834ad726" TYPE="swap"
/dev/sda8: UUID="E208-E865" TYPE="vfat"
/dev/sda9: UUID="6BB3-FA39" TYPE="vfat"
/dev/sda10: UUID="1477776e-fe68-40f6-9804-c752b5efb149" TYPE="ext4"

接下来编辑/etc/fstab，该文件中swap分区以及前面的分区是系统安装时就设置好的。后面三个是我自己设置的：

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    nodev,noexec,nosuid 0       0
# / was on /dev/sda10 during installation
UUID=1477776e-fe68-40f6-9804-c752b5efb149 /               ext4    errors=remount-ro 0       1
# swap was on /dev/sda7 during installation
UUID=b8f6c810-bbb0-458c-8306-7b4a834ad726 none            swap    sw              0       0
UUID=8bda8d60-b5cb-43aa-b408-dd6ce4957923 /home1          ext3    defaults        0       0
UUID=c415cf1c-624c-42ce-a8a6-6c072b5ee232 /home2          ext3    defaults        0       0
UUID=d0d1424b-e3a8-43d9-887a-1c58c64ecff3 /oldlinux       ext3    defaults        0       0

重启后，就会发现，根目录下自动挂载了/home1、/home2和/oldlinux三个分区。别忘了对这几个挂载点做一下chown操作，这样你的用户才能对这些路径有写权限。

* 恢复用户数据

主要是迁移原home目录下的数据。在原系统中，我单独将一个分区挂接到/home路径上，其中的/home/tonybai设置为HOME路径。重装 os后，系统在/dev/sda10分区建立了/home/tonybai作为HOME目录。而之前的那个存放HOME路径的数据分区被我映射为 /home1了，但其中的数据完好无损。我于是打开/etc/passwd，将我的用户到home路径由/home/tonybai改为/home1 /tonybai，这样重新登录后，我又回到了熟悉的HOME环境中了。不过一些原先为/home/tonybai路径的配置需要修改为/home1 /tonybai了。

剩下的就是安装各种软件了。

* 问题再现，有惊无险

经过大半天的折腾，工作环境基本得以恢复。晚上回到家里，打算再补一些软件。结果刚进入Ubuntu就发现了异常：触控板失灵、无线网卡失灵、静音并无法 调节、指点杆失灵、所有快捷键失灵等。并且总是弹出对话框，提示系统错误，建议重启。重启若干次依旧是老样子。靠！这不又回到了最初的问题状态了吗。难道 还得推倒重来？

死马当活马医。试着执行一下sudo apt-get install -f，居然提示：用"sudo dpkg –configure -a"可以解决。遂按照后面的命令执行了一下。命令的效果是系统在重新配置包 – 所有包。执行完毕后，注销登录，发现大不相同了。重启后再看一下，一切恢复正常。估计又是我装了什么软件导致包依赖异常导致的。如果早知道dpkg –configure -a可以解决问题，我这大半天时间就可以专注于其他事情了，唉。

生命也许就在于折腾^_^！！！

再次提醒：用Ubuntu的童鞋apt-get update/install要谨慎，upgrade尽量就不要做了，成功率低得很！

一直在纠结要不要就这个话题写点什么，之前梳理过一些思路，但感觉这个题目似乎没什么大意义。不过将东西憋在肚子里的滋味总是不好受的，最终我还是选择写出来一些，即便它真的没有什么意义^_^。

事情缘于近期领导让我负责的一个内部任务：制定组织内的代码行统计标准并实现标准化的工具。就是这个任务促使了我对代码行统计重新做了一番考量。

对代码行统计的理解

代码行统计这个活动不是软件开发过程中的关键路径活动，它对代码质量、开发进度以及软件价格几乎产生不了什么影响，应该算是个可有可无的东西。

就代码行统计这个活动本身而言，我个人的观点是没有代码行统计不表明不能开发出好软件；有了代码行统计，就一定能开发出高质量软件吗？

不过有一种观点认为：世界的本质是数据。通过数据我们可以发现事物运行的规律。代码行统计则是软件工程中对“数据”要求的产物。过程的好坏需要有数据支 撑，因此代码行统计这个活动成为了人们实现“用数据说话”的一柄利器。在“数据为王”的今天，我们无论如何都不能忽视数据的作用。人们通过数据来反映软件 开发过程中的一些规律性的东西本身也没有什么不妥。另外代码是软件开发过程的最重要成果物，因此围绕着代码的性态，我们用工具做诸多分析，期望从得到的数 据中找寻出一些可以指导和改善我们后续工作的蛛丝马迹。代码行统计提供的多是基础数据，在与其他过程基础数据结合分析后，我们能得到更多的信息。

合理地使用场合

个人觉得下面几个场合对代码行统计的需求是合理的：

* 统计代码总规模
   某个项目、某个模块或又某个版本的代码总规模。

* 代码“成分”统计
   统计空行、注释、代码的行数及占比、重复代码行数及占比等。

* 版本间代码变更差异统计
   两个有关联版本的数据对比统计，获取版本间的有效变更数据情况并作为基础数据提供给后续分析。

一些过程质量指标，诸如千行代码缺陷率等均是以上面这些代码行统计输出的基础数据为基础的。

“误用”

有合理的使用，就有“不合理”的使用 – “误用”。之所以加上引号，是因为至今人们对此见仁见智，尚无定论。以下列举两典型的“误用”。

* 通过代码行统计评估进度

有些组织在项目开始初期，就对成果的规模做了估计，比如10w行代码。然后在过程中使用代码统计工具对项目当前已实现的规模进行统计，并用统计出的数据与 初值的比值作为项目进度的评估参考。个人认为这是种典型的误用。盖茨说过：“用代码行数来衡量编程的进度，就如同用航空器零件的重量来衡量航空飞机的制造 进度一样”。且不提初期的估值有多么的不准确，就代码的行数本身而言，也受到各种因素的影响，比如设计方案、实现者的功力以及编码习惯等。同一个功能，A 实现需要100行代码；换成B就需要10行。

* 通过代码行统计评估程序员绩效

在一些外包公司或外包项目里，尤其是日本人的外包项目里，通过编写代码行的多少来评估程序员绩效的作法是很有市场的。我不能完全否定这种方法的正确性，因 为在日本外包项目中变态的日本人对代码的审核极其严格，并且有着苛刻的编码标准和风格，因此一些胡乱堆砌代码或使用奇技淫巧的代码都会被驳回，因此所有项 目开发者的效率似乎被约束到了一个平均线上。在这个前提下，产出的代码越多，似乎的确表明了这个开发者超出了平均效率，或至少牺牲了不少个人时间来完成项 目中的任务，精神可嘉，绩效被评高似乎也是合情合理的。但除此之外，用代码行多寡来评估程序员绩效显然是不受待见的。

考虑这个“误用”时，我也想模仿盖茨的话做个形象且深刻比喻，最初我写下的是这句话：“用代码行数多少来评估程序员的绩效，就好比用曲子的长短来评估音乐 家的水平，或又好比用画幅的大小来衡量画家的水准，或又好比用电影的时长 来掂量导演的功力！”。但仔细揣摩后发现这句话看起来挺像那么回事，但实际上却是不恰当的。什么是水准、水平或功力，这是衡量人的水平高低的；而绩效则是 一段时间范畴内工作成果的评估； 一个是长期的肯定，一个是阶段性的成绩。我显然是将水平和绩效(阶段性成绩)混为一谈了。高水平的开发者不一定每个周期都会取得高绩效，低水平的开发者也 不是无法取得高绩效的。因此这句话似乎应该改成：“用代码行数多少来评估程序员的绩效，就好比用这首曲子的长短来评估音乐家在这个阶段的水平，或又好比用 画幅的大小来衡量画家的这个阶段水准，或又 好比用电影的时长来掂量导演在这部电影上的功力！”。是不是读起来很别扭啊，反正我是这么觉得的。程序员的成果物是代码，代码好坏优劣对程序员绩效有着直 接影响（虽非充分必要条件），我们不妨替换一下本体来换种说法：“用代码行数多少来评估代码实现的好坏，就好比用曲子的长短来评估曲子的优劣，或又好比用 画幅的大小来衡量画作的高低，或又好比用电影的时长来掂量影片的良莠”！

对用代码行数多少来评估程序员绩效这种事情，我是很反感的，但在国内许多公司里，这种现象却又屡见不鲜。但这种行为背后的动机何在呢？传统工厂中，衡量一 个worker的绩效是相对容易量化，也比较客观的，比如制鞋厂可以用制成鞋子的数量来确定 worker绩效；在汽车组装车间，组装汽车的数量可以作为作为工人们的绩效；在炼钢厂，班组炼出的钢铁的吨数可作为班组成员绩效等等。将代码行数作为程 序员绩效的参考指标也许是一个无奈的方法。之所以想用代码行数，是因为程序员工作中能量化的东西不多，代码行数首当其冲。组织为了尽量减少绩效评定时主观 的成分，增加客观的评价，代码行统计从此被误用了。

代码行统计的高效使用

* 标准统一，工具一致

代码行统计工具有很多，因此执行这个活动时会出现不同人使用的代码行统计工具不一致的情况；并且不同工具对一些指标的定义也许有不同，这会导致收集到的数据存在含义不一致，精确度差的问题。因此高效使用代码行统计工具的一个前提就是（统计）标准统一，工具一致。

* 零干扰

一些传统的代码行统计方法是配置负责人收到统计任务时，将任务分发给各个模块的负责人，由各个模块负责人各自统计，然后反馈给配置负责人汇总。这种方式显 然不那么高效，而且容易引起一些对统计任务的反感情绪。高效的代码行统计最好能做到对开发人员“零干扰”。配置负责人可以通过“自动化”的静默方式收集代 码行数据。当然这需要对一些现成的开源工具做一些包装或二次开发才能做到，个人觉得这种投入是值得的，同时也能避免标准不一，工具不一致的情况。