阅读 225

代码即设计 | 掘金年度征文

写在前面

2018年过去了,我很怀念它。

2018年是漫长的一年,在这一年里收获了太多,难以细细道来。

从一个在屎山上添屎的菜鸡,到现在的用心设计代码,饮冰二年,难凉我对编程艺术的追崇热血。

从“SB js, SB java”的抱怨,到后面渐渐理解各个语言的设计思想,变成了对各个语言之美的赞叹。

2018年,对我最重要的书是clean code,我写的最多的是java 和 js, 熟悉了python,但最让我赞叹的语言还是kotlin,一门将clean code演绎在骨子里的语言。

2019于此,我总结下我的2018关键字: 设计, 语言。

设计

设计是门艺术。

设计你的代码

在年中的时候,我一度认为代码丑陋主要有两个原因:

  • 没有遵循约定的代码格式,令代码不可读。所以我使用ktlint,eslint去改善这一点,并在java代码中严格遵循这种规范
  • 没有好的接口,没有注释文档

所以这导致我在写新的模块中,大量地使用了接口,并且在暴露的接口方法中写了十分详实的文档,遵循javadoc的规范。

后来我认为这是愚蠢的做法。类可以自己描述、表达的,就不需要为其写接口。代码可以描述的,就不需要为其写文档。在我新的代码当中,我开始控制我自己写注释的欲望:人们往往不会去维护注释。

我开始发疯一样,在起一个类名、方法名、变量名的时候想半天。我开始抽象大量的方法,每当我觉得我有好一段代码有写时,我就开始准备一个新的方法。我遵循了clean code的原则,并觉得每一句话都是圣经。

直到我看到了5分钟原则:起名超过5分钟的话,就妥协吧。是的,你没办法为编程里面的所以类与对象映射成一个在现实生活中有意义的事情。很多重构的书,《clean code》 或者是《重构》,都不断地叫你:类名不要出现helper,不要出现manager,但是他们却没有给出解决的方案。

我开始思考:如果我不写helper,我该怎么命名辅助类?我不写manager,我怎么抽象facade?

世界上本没有路,走的人多了,便有了路。Helper,manager本来是不可读的,写的人多了,他就被约定可读了。

所以我开始随心所欲地写,找很多牛人帮我code review。我开始对自己的代码有信心,并再也不怕展示自己的代码。

设计你的系统

也是因缘际会。当初在看DDD的时候,感觉DDD是这么一种思想:

一问都知道,一说都明白,却从来没人用。

我自忖在理解能力上还行(当年语文还行),却也看的昏头巴脑。这更激起我的好奇心,所以我开始准备搞清楚这是个什么玩意。

我翻阅了许多的博客,大部分的讨论只是浅尝辄止,只有一篇知乎上的美团点评的实践还算详尽:zhuanlan.zhihu.com/p/32459776

然后我开始读DDD,IDDD,啃电子书是痛苦的。我一边笔记一边读,勉强啃完,但是也是只是通了几窍。

在我读完IDDD后,再重读美团这篇文章,发现可能和我理解的不太一样,所以我在评论中留下这样的评论,但是遗憾没有收到回复:

一点浅见: 题中作者已经提到了, 架构和IDDD中有所不同, 我仔细回顾了一下, 发现可能不同的有点多。 在IDDD中, 领域服务是对领域模型的一种补充, 是附属品, 相当于实在是面向过程的才放到领域服务里, 实际上可能根本用不上, 而在本文中, 不知道我有没有理解错, 领悟服务变成了对领域模型的封装? 这点感觉会导致贫血, 而且和书中所描述的领域服务有所出入?望指教。

后面看到18年9月印刷了一本《领域驱动设计精粹》,我赶紧从淘宝买来,放在案头准备有时间好好研习。

DDD给我带来的是:在每一个项目开始时,我都会细细地理通领域知识,并在分层、结构设计上更加自信。但是遗憾,我没有真正实践它的机会。

语言

Kotlin

初识Kotlin时正好我在研习clean code。当时我就在想:设计kotlin的人一定是clean code的粉丝。Kotlin的思想,禁止空值传递、取消违反开闭的checked exception、 类似groovy的有表达力的dsl等,让我觉得写kotlin是种享受。

Kotlin太新了,所以吸收了无数的别的编程语言的智慧,并且使用富有表达力的形式展现。

Kotlin multiplatform也是强大的,虽然它还是十分地年轻,但是我十分看好它。我也十分自豪,为kotlin multiplatform的社区贡献了自己的代码。

也是因缘际会,当初接到一个需求,将一个kotlin multiplatform的项目增加node.js的支持。我开始研究这个东西,并且发现ktor这个库没有对node.js做支持,而这个kotlin multiplatform的项目是有依赖ktor的。所以我提了issue,提了pr,为ktor加上了node.js的support。

js

js圈简直就是娱乐圈。今年爆出几个大事,都与js有关系,就连我常用的nodemon,也依赖了event-stream这个库。

不过这改变不了js优秀的异步驱动的思想。用Js编程你可以忘掉一切多线程的烦恼(node在18年5月份release了对多线程的支持,不过好像是通过传递来共享内存),而es678的语法让你发现,你要的js基本都有。

2018年也尝试了Typescript,将一个js的项目完全地重构成ts,过了一把重构的瘾。有人说ts和python3.5基本是一个语言,我非常认同。

展望

18年过去,常常感觉自己还是好弱,想学的东西太多。

感觉自己soft skills更是需要好好提升了。这是重中之重。没有办法做一个纯粹的programmer。

掘金年度征文 | 2018 与我的技术之路 征文活动正在进行中......

关注下面的标签,发现更多相似文章
评论