我的2016技术回顾
发布于 20 小时前 作者 mkatsoho 454 次浏览 来自 分享

Retrospection-2016

A retrospection of technical failures expericeced in 2016 (2016年技术回顾)

Written by Michael Chen, 1/1/2016

https://github.com/mkatsoho/retrospection-2016/blob/master/README.md


many engineers or several engineers (是一帮人一块开发,还是几个人开发)

2016中经历了一个feature,需要众多开发人员参与,协同开发,数据流从component 1 to component N,非常之长,不复杂的feature,经历了整整一周的开发时间,终于搞定。感叹。。。

相比一群人开发(many engineers),我更倾向支持几个人开发。显然,后者沟通成本更少,架构更合理,代码质量更高,开发进度更可控。缺点也很明显,没有人员互备,找到senior的人难度增加,”老家伙“做事没有热情,好像也就这三个问题。

曾经约了一共3个开发人员,着手做一个ERP,3个月败了。可是我依然支持 several > many。实在是经历了太多,初级开发人员写了初级的代码,后续要重新re-arch,甚至推翻重写,feature实现不完整,性能/安全/等等质量低下。

上述机构问题,senior人也有类似的情况,相对少很多,这个是不可否认的。注:senior和junior的区别不是工作年限,而是写代码的行数和代码的效率。

更实际的现实是,在many中有譬如1个senior的人,无论在流水线的哪个环节,依然可以协调上下游,依然可以解决一定的沟通问题,也许架构可以合理一些,代码质量吗,就听天由命吧。

简而言之,相信”代码改变世界“的话,就选择”several engineers“吧。如果相信”奋斗才能成功“,”many engineers“也许是好选择中的一个。


不同的APK中使用公共的SDK模块,真的好难

最近看到有好多的APK,都在使用一个内部自定义的SDK模块。现象就是:“五花八门”。

每个APK,UI都不一致,各有特色,每个都要自己的演进和变化,都在不同的事件中有类似又不一致的需求。问题来了,这个SDK没法让“大家满意”。于是乎,Fork一个新的,自己写自己的,结果“同一个SDK规范”有不同的实现的版本,APK们纵横交错,reuse别人的SDK代码,如是乎,“SDK规范”有了各种实现,也就有了几倍的工作量,有了各种bugs,各种各种的问题。。。

UI和使用行为的不一致,这是合理的。那这个问题怎么解?!

不同人有不同的想法。私以为,“SDK规范”的实现,可以和UI解耦,用非可视化的model来实现所有的下行和上行数据流(下发和上报)。当然在给2个UI的参考实现。不同的APK fork UI的实现,把各种自己期望的UI事件和model的行为链接在一起。这样既保证了“SDK规范”的一致性,又保证了“APK的UI特色”。值得考量。

当然,在说一下困难。其实困难不是技术,是人。不同部门见的独立,互相的敬仰或不敬仰,任务别人挫或自己强。。。当自己搞不定的时候,显然原因是有更优先的工作,人员不够,需求不应该。。。最终还是人的“问题”。


说说后台服务的QPS (每秒可以处理的请求数)

8核32G内存的AWS服务器,能处理多少QPS?

答:不确定。不知道cpu型号。不知道服务是不是cpu密集型的。不知道服务是不是io密集型的。不知道io对应的后端资源的latency。不知道请求的协议。不知道请求的payload大小。。。

如果,服务既不是CPU密集型的,也不是IO密集型的,这样一台应该CPU还不差的服务器的QPS还不到600?甚至不到300?不可思议吧?8086的处理速度?不,应该是个i5笔记本的速度。

原因在哪呢?技术和人,不外乎这两件事。

技术上选择了同步IO,用多进程来解决并发的问题。10 QPS每进程 * 32 进程 = 320 QPS 处理能力也就这样喽。异步IO会增加代码的复杂度吗?这个不好回答。c++,python,java,nodejs都不一样。或许每个语言都有成本不高的异步IO方案,即,学习成本不高,架构不复杂,代码也不很复杂,debug也容易的方案。我相信它们都有。

人的事情永远比技术的复杂度大,此处省略500字。


写测试代码太耗时间

每每听到有人说“写测试代码太耗时间”,“太赶,没时间”。曾经认为最正确的回应是”有足够的测试代码才能敏捷开发“。现在已经不在这么想了(老了)。

还是只谈技术,不谈”政治“(技术)。

技术上讲,“测试代码太复杂”核心的原因是:设计架构和API的时候,仅仅想着功能,就没有想怎么测试。更直白的讲,设计能力不够。写功能的时候,要考虑好写个事儿呢!例如:

  • 并发性能。怎么知道服务端的QPS呢?设计的时候已经考虑了怎么测试性能了。否者,out了
  • 响应时间。有的API不会有很大的访问压力,比如说服务端ready这样的API,需要很快的响应时间。只考虑功能,对响应时间不感冒,就完成了那点功能,就有点low了。
  • security。不要到处留下password/token的脚印,不要,千万不要。需要保存话,也是一个不可逆的数值。
  • 其它,没记错的应该一共有7个

把上面都考虑了,你会发现测试就是一个顺理成章的事。例如,5行搞定:

  # Exmaple: load a new conf to server, wait it restart, and ensure the new conf works
  startTimestamp = Time.now()
  assert url(/loadNewConf).sendRequest() == 200                 # load new conf
  setTimer(timeout=10s, interval=10ms, funciton(){
      break if url('/isRunningAfterLoad').sendRequest().body().status == 'running'  # wait until running
  )
  assert url('/isRunningAfterLoad').sendRequest().body().status == 'running'        # running!
  assert url('/getConf').sendRequest().body().conf = 'new'      # new conf has been effective
  assert Time.now() - startTimestamp < 500ms                    # should be less than 0.5 sec
1 回复
回到顶部