T上西北

上海和北京地铁的出口标示

今天无意在地图上看见北京和上海这两个城市的地铁出口标示采用了不同的方案。

北京采用英文A,B,C,D…,而上海则采用数字,例如1,2,3,…

对此,我表现除了强烈的好奇心。这两种方案,到底哪一种好呢?如果我是地铁的设计人员,我应该如何设计?

针对此问题,我在微信上发了一条朋友圈,看看到底大家怎么说。

下面我试图站在设计者的角度去思考这个问题。

 

首先,出口的编号在我们的平常的生活种起到什么作用呢?考虑一下几种情景:

情景1: 我坐地铁去拜访一个朋友,这个朋友在地铁站外等我,打电话说让我在某某口见面。

情景2:我父母来北京或上海,我去接站,我跟父母电话说在某某口见面。

情景3:有位中学生坐地铁去北京站(或上海虹桥站),到站之后,问服务人员坐火车到那个口出。

情景3:有位从农村来的爷爷奶奶坐地铁去北京站(或上海虹桥站),到了站之后,问服务人员坐火车到那个口出。

以上的几种情景主要体现在沟通上,在这里沟通成本取决于文化程度,文化程度越高,对于字母识别率越高,沟通成本越低。基于此,看看这两种方案的沟通成本:

方案 高文化程度 低文化程度
数字标示 简单 简单
字母标示 简单

即便是字母,对于我们来说沟通费劲,例如B和D,很多时候教育程度高的人都要确认。数字好的多,暂时由4和10的区别,好多南方人10发布出来了。

 

再尝试考虑以下情景:

情景4: 有位从美国来的外国游客

情景5: 有位从俄罗斯来的外国游客。

上面的2种情景主要是考虑到外国游客,因为地铁是公共服务。显而易见,只有数字接口更易懂一些。毕竟数字全世界的人认识,而英文字母并不是全世界的人都认识。

 

再考虑下面情景:

情景6:如果有个站口超过26个出口,怎么办?

首先这种可能性非常容易出现,看看上海的徐家汇站,人民广场站,出站口还是蛮多。如果要是用字母表示,很显然不够用,数字相对来说好很多。但是北京现在也开始考虑字母+数字组合,例如A1,A2出口,这应该给交流带来更多灾难。

 

根据以上,我觉得数字方案会更好一些。但是这里有个问题,因为国内的地铁线都是1号线,2号线体现,如何在出口处将地铁线的数字标号和出口数字标示清晰分清楚?

显然,如果这个问题不解决,将会是灾难性的设计,导致人们根本不知道数字到底是地铁线或是出口。

看上海怎么解决的?

上海每条线都有非常清晰,可识别性非常高的颜色。

根据上图,数字标识的是地铁线或是出口还是容易识别,看右图的10号线,数字10 的矩形底色,而6号出口则非常大。

就我个人而言,这种挑战性还是比较大的,所以风险很大,如果做不好会适得其反

 

无论是哪种方案都是要解决沟通问题,不同颜色代表不同地铁线是这样,数字标示还是字母标示也是这个目的,就看谁把这个问题解决的更好一些。

 

看看国内的城市分别用什么呢?

数字:上海,苏州,南京,长沙,重庆

字母:北京,杭州,西安,武汉,广州,深圳,香港,昆明,郑州,沈阳,大连,天津

看起来大部分城市都是用字母。

一图

软件开发规则

最后版本: rev 5
最后更新: 2017-04-21

设计

  1. 注重软件设计。
  2. High Available需要考虑。
  3. Geo Redundancy也需要考虑,如果设计web的话。
  4. 考虑软件的需求,有无可能复杂化,定制化,这决定了软件架构,
  5. 将需求详细化,但实现时简单化。
  6. 数据库主从结构,Replication,数据一直等。
  7. web的安全性方面是必须考虑的。
  8. 软件都是逐步迭代的,为了让后期迭代的成本更小,起点最好高一些。
  9. 事先定义软件的版本管理。
  10. 站在使用者的角度去思考。
  11. 解放思想,考虑问题站在高一点的位置。
  12. 防止过度设计。


Coding

  1. 一个文件代码不要太多,1K行左右,一个函数也不同太多,100行左右,如果太多的话,就应该考虑如何去分拆了。
  2. 代码一开始就要考虑模块化。
  3. 代码可重用性。
  4. 代码不能太耦合。
  5. 对于异常case务必写日志,不要认为捕获了就OK了。
  6. 良好的代码目录结构。
  7. 对于SQL等一些reserved keywords建议用大写,例如SELECT * FROM <tbl-name> WHERE field1=v AND field2 = v2
  8. 代码格式上须易于阅读,空格,空行等是必要的。Java有Java的代码规范,可以作为参考准则。
  9. 注释需要合理,不在于多,而在于精。对业务复杂的业务逻辑,加适当的注释会锦上添花。
  10. 代码格式可以利用一些专业化的工具进行检测,例如Sonar,JSLint等。
  11. 写代码是软件开发里非常简单的事情,但是做好不容易。基础非常重要。态度谦逊,借鉴优秀人员的代码,避免自己的不足。
  12. 一开始就要写好,不要以后面可以重构当借口。
  13. 对于web开发,安全性非常重要。可以写完后用安全扫描工具(例如AppScan等)进行扫描。掌握经验,在后面的coding种尽量去避免。
  14. 尽量将问题或需求想的全面,实现时根据实际情况可以取舍。
  15. 设计准备好了才可以写代码。
  16. 对于异常case多处理,不要认为发生的可能性不大。
  17. 尽量让代码的适应性强一些,考虑一些配置来适应未来的需求。
  18. 代码用Maven,Gradle等进行build
  19. 拼接SQL语句需要考虑的SQL安全性,SQL 的 保留关键字或字符,建议用PreparedStatement去完成。

Log

  1. 清晰的日志易于做troubleshooting
  2. 清晰的日志易于team之间的交流和学习。
  3. 日志注意拼写错误,英文合适。
  4. 日志需要将业务分步描述清楚。
  5. 建议developers多做Ops的工作,以便于了解到底什么样的日志才是优美的。
  6. 对于正常的业务也许打log,对于异常的case务必打log。常遇见的情况是正常的业务逻辑少,只有一些exception的case 才打。导致正常业务出问题没法进行troubleshooting。
  7. log的级别。什么样的信息适合什么样的log level,取决于业务。

SCM(SVN/GIT)

  1. 保证仓库里的代码是可以编译通过的。
  2. 代码尽量每天提交。
  3. 一次只提交一个功能或者bug fix代码。
  4. 提交代码时,写上comment描述当次修改。
  5. 如果是bug fix,在comment里注明bug id,如果是功能,注明requirement id。
  6. 安装合适的工具,例如Trac, Phabricator,以及Bitbucket等

Code Review

  1. 强烈建议team之间内部相互review。
  2. 条件允许的话,只有代码进行code review过了,才可以commit到仓库里。
  3. 开Code Review会议前,相关人员提前review一遍。在会议上只提问。
  4. Code Review时只提及修改的部分。
  5. Code Review可以用一些工具,例如Phabricator,ReviewBoard,以及Bitbucket等。

Test

  1. 写单元测试(Unit Test), 可以简单理解白盒测试。
  2. 写功能测试(Functional Test),可以简单黑盒测试。
  3. 一般项目都会用daily build,将单元测试和功能测试加入daily build的task中。
  4. 代码覆盖率也很重要。
  5. 代码必须测试过才可以发出去(内部或者外部)
  6. Test Cases需要详尽才可以,认真写。
  7. Test Cases不是应付,不是交代,而是软件质量的一小步。
  8. 用测试框架去Test case,。例如,在Java里,很多人有个习惯是在class里增加一个main方法去驱动测试某个函数。

 

修改历史记录

  1. 2017-03-08, 第一版起稿。
  2. 2017-03-09, 增加测试部分,以及部分coding规则。
  3. 2017-3-13,增加设计章节。增加测试部分(>=6),log部分(>=6),代码部分(>=14)等
  4. 2017-3-16,增加设计部分(>10)
  5. 2017-4-21, 增加coding 的18,19,修改Log的6