江边闲话集

03/29/2017

人最重要的能力是什么?

Filed under: 闲情逸致 — 张太国 @ 14:27

最近因为在做performance review这件事情,让我再一次去评估整个团队。这引申出另外要给话题,到底人最重要的能力是什么呢?

带着这个问题思考了很久,这个答案终于我在心里越来越清晰。

是的,我的答案是主动,就是这个词。

刚开始我想了许多答案,例如学习能力,态度等,但是最终我觉得主动这个词挺能概括的。

 

人需要保持相当的主动。

举个例子,当自己一个住时,从起床到晚上睡觉发生的各种事情,是随心而欲呢,还是能够按照计划。说起床和睡觉,可能有些人因为周末睡个懒觉什么的,也许因为今天电视上正在播映一个好看的节目或是和朋友聊天太晚,导致晚睡。或是午饭时,觉得是自己一个人做饭没意思,所以随便吃一点。是的,各种各样的事情,当自己一个人时,能和平常做的一样好吗?我们能克制住自己吗?

现在几乎每个人都有微信,我们看看生活的周围大都是低头族。有人也意识到做低头族不好,但是如何才能做到呢?我们能克制住自己吗?

很多人做事情有时候是和心情有关的,当心情相反时,我们能主动的去做事情吗?

在工作时,工作不仅仅是工作,也是一件实现人生价值的事情,我们会主动认识到这一点吗?

在生活上,面对悲欢离合,我们能坦然面对,积极面对,难道这不是主动的表现形式吗?

 

主动,如果理解成主动学习,主动工作等,那就意味着把这个词看的太狭隘了,我们应该更高的理解它。

主动,首先是一种对人的心态的表现。同时,它也代表我们对生活以及工作的一种认知。

当我们在某件事情上获得成功时,我们需要让自己在喜悦的同时保持冷静。

当我们在某件事情上碰到问题时,我们需要让自己不要太悲观,分析问题,解决问题。

有人在工作上保持成功,同时我们也应该在生活上追求理想。

 

主动会让人追求一些更远大的目标,而不是一直停留在这里。也许有人在一个舒适区待了很久,但是不愿意突破。隔一段时间反省一下当前生活,舒适区?是否有冲动?当想清楚之后,想着去突破吗?

人的本性其实是懒散的,如何主动,那是一种境界。

 

现在的我也是有一些阅人的能力,基本上能简单看出谁主动,其实说白了就是考虑这个人在工作和生活上能达到我认为的高度。

当然,看其他人容易,但是看自己难。我认为最难的事就是如何清晰的看清自己。

03/14/2017

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

Filed under: 闲情逸致 — 张太国 @ 12:50

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

北京采用英文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号出口则非常大。

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

 

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

 

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

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

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

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

03/10/2017

一图

Filed under: 闲情逸致 — 张太国 @ 01:03

03/08/2017

软件开发规则

Filed under: 一技之长 — 张太国 @ 14:26
最后版本: 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

Powered by WordPress