从 SVN 到 Git,找回丢失的历史

前段时间在将公司的 SVN 项目迁移到 Git 上面去,遇到一个很少见的问题: 有一个小伙伴使用 git-svn 做 rename 操作时候,将一个目录 svn mv 了, 导致新目录只存了最近几个月提交历史,丢失了历史信息。对团队开发而言, 历史提交是非常宝贵的财产,我们想了一些办法,把这些数据提取出来。

more ...

读《人件》

事情起源于动态语言和静态语言之争,最后争论焦点转移到:「相信人本身的能力重要, 还是通过语言/工具来约束人重要」。 我认为项目开发中最重要的是个人能力和团队协作能力,工具只是加分项。 如果代码质量差、监控难、性能难以优化,解决根本问题的关键还是在人身上。 并不是静态编译和工具检查就能搞定了。

我愤愤的在 QQ 对话框中写道:

我工作第一年痛苦于开发流程,阅读了《人月神话》,就开始坚信软件工程的哲学 后来痛苦与代码质量,阅读了《重构》,开始坚信代码质量决定产品质量 现在痛苦于人和语言的冲突,动态和静态的冲突,我想读《人件》了

人件

人件已经绝版,只能在找线上版,我花了两个星期把它读完。 书中给了我一部分答案,另外还有一些意外的收获。

more ...

软件开发中的角色扮演

说到软件开发的过程、环节等等,我印象里只剩下一大堆术语和一些流程的大概,但是因为缺乏正规开发的经验,所以并没有对软件开发中每个人的角色有深入理解,今天在周末 检查Delicious Temp标签时候,看到 圆木菠萝头 的这片文章,收获颇丰,现在转载与大家分享。

原文链接:软件开发中的角色扮演 - 软件开发 - 圆木菠萝罐 (我稍微调了一下格式,没有修改文章内容 ^_^)

××××××XXX分哥线XXX×××××××

商业软件开发并不是只有一个编程的人,而是可以分为不同的角色。

不同的软件公司因为规模大小性质各不相同,所以围绕软件的角色也各不相同。这就好比在重点学校里面分级很明确,每科有个老师,每个年级每个班级都有各自的老师,也有主 任书记校长支持角色。而在电影《一个都不能少》级别的学校里面,往往一个老师兼职从语文教到体育,年级从一年级到六年级。类似的说,一个大型的软件外包企业,外资企业 ,往往分工明确细致,每个人像螺丝钉一样在一起工作,让整个大机器得以运转。而在一个小型创业企业里面,往往一个人从接触客户,到开发产品到交付产品***走完,整个 产品周期就一个人,甚至几个产品周期就一个人。

所以解释角色要针对性。远的不说 …

more ...

用户权限设计的问题

问题

用户权限设计这一块,一直是一个我觉得比较难解决的问题。

以前我用了「伪继承」,虽然管理员继承了普通用户,但是数据库却是分开设计的。又或者压根没有继承关系,是两个不同的实体。

解决方案

这次在贴吧系统,有三个用户角色:普通用户、吧主、管理员,想设计的符合OO,但又要利于数据库的实现。就有几个问题需要解决:1.需要继承么;2.数据库怎么设计; 3.Hibernate怎么映射。最后参考几篇文章,设计成如下。

使用User类,Roll类,User具有一般用户属性,Roll负责角色,他们是1对1关系,最好在数据库有一张User- Roll的对应关系表。来标明这个User具有哪个Roll。

在我这个系统,Roll类有三种,分别对应三种角色:普通用户,吧主和管理员。

这种独立出Roll角色类的方法被称为基于角色的用户权限设计方法。

[caption id=“attachment_12439” align=“alignnone” width=“300” caption=“User Roll …

more ...

用户界面设计黄金原则

在《用户界面设计要素》一书(1997)中,T.Mandel提出了3条「黄金」知道规则:

  1. 让用户驾驭软件,而不是软件驾驭用户。那种在给用户的操作加上许多约束和限制的界面虽然设计容易,却往往难学难用。
  2. 尽可能减少用户的记忆。为此可建立易记的快捷键(例如Ctrl+p启动「打印」);采用演进形式显示「提示」信息,以免要用户一次记忆大量信息。
  3. 保持界面的一致性。例如在同类产品中使用相同的设计规则;尽可能不改变用户已熟悉的操作功能键(例如用Ctrl+S保存文件);设定界面的缺省状态。 最近停下了贴吧的下一步开发,恶补软件工程,为下一步开发做理论基础。

一边啃Rober C.大人写的《敏捷软件开发》。白天都浪迹在考研自习室(很是安静啊),更新变慢,勿怪。

more ...

软件自然理论

所谓软件自然理论,就是说:一个优秀的软件,他的功能模块设计,应该与用户在完全没有接触过这个系统时候所想要的功能设计一致,用户觉得他想要的功能在什么地方,应该 怎样实现,那么这个功能就是应该在那里,就是应该这样实现。

这么说感觉上会很绕口,那么举个例子。Office就是一个比较优秀的软件,如果一个用户完全没有接触过Office(当然,必须具备基本的电脑使用水平),如果该用 户想对字体进行设置,那么他就觉得字体设置属于格式,就应该在格式菜单里面,用户去点击这个菜单,就找到了自己需要的功能。

其他的,比如WinRAR,IE浏览器,都是出色的软件,他们的模块设计也都是符合用户的想法的。

如果一个软件功能过于复杂,或者说功能的安排有很多方案,那么用户往往会难于在短时间内找到自己想要的功能,就会产生对该软件的「惰性」,也就是不想用这个软件了。比 如说AutoCAD,3DMax,如果想熟练使用,往往要经过一段时间的学习的。

ps:这个理论你肯定找不到的,Google也不会有,因为….这是我編出来忽悠继烨、道哥的….很不幸,他们纷纷上当….

more ...

我在看设计模式

花了6天时间把创建型5种模式看完了,很有感触,但是感触不意味着我理解,我甚至私下里觉得OOD的设计模式不适合我现在做的那些程序,那些都是一次成型,根本谈不上 需求的改变。没有改变,就不需要OO思想。因为我这样的想法,我看起来很累。 我知道这些思想对我以后的发展很有帮助,会从思想上把我解救出来,我被这些新的设计想法激动着(虽然出来很多年,可是对于我来说完全是新的,呵呵```)。

嗯,坚持下去

这几天我也在想以后走IT哪一条路。想了好久,现在的想法是:计算机本质上是一种工具,软件的存在是为了计算机更好的服务。既然是一个工具,就要有工具的觉悟,就必须 不断适应生产力的发展,需要完善自身功能,也就是需求的变化。正是因为需求的变化,使得敏捷软件开发成为现在的主流。

我才看了几天设计模式,就说的这么狂激动了,激动了```

more ...