--- title: 不要总是走在准备的路上 slug: just-try date: 2016-04-04 12:45:43 updated: 2020-09-04 19:54:37 tags: - 随笔 category: 编程 cover: /images/2020/09/2020090419532852.jpg summary: 上周和一个即将毕业的大学生聊天,他很厉害,学了很多,抱怨到很多人学了很多编程语言,但最后都只是会写一个“Hello World”的程度。 --- ![9692 - 「中身が無い」](/images/2020/09/2020090419493263.jpg) 上周和一个即将毕业的大学生聊天,他很厉害,学了很多,抱怨到很多人学了很多编程语言,但最后都只是会写一个“Hello World”〔1〕的程度。我说,因为他们大多是一直在准备学习,往往刚开始学的时候,便放弃了。

——题记

我叫雨帆,所有的汉字中我觉得我“雨”、“帆”这两个字写的最好看,不是因为我字写的好,而是因为我专门针对这两个字专门练习。 同样的话语可以套在很多东西上,许多东西,比如人的技能,擅长的东西,并不是一蹴而就的,需要频繁的练习。没有谁能一开始就能成长为参天大树,即使是所谓的天才,在你看不见的背后,也有着常人难以想象的汗水与努力。 所以一直一来,我很赞同一句话:[信念永远不能达到目的地](/intimate-in-mind)。每个人都有自己的梦想,但是如果只是梦想,却不去付诸行动,那么它也仅仅是梦。 记得三年前有一个叫做[谢钦](/meeting)的网友邮件问了我很多关于独立博客的话题,当时的感觉就是在茫茫大海中看到一束光的感觉。就是一直以来,你一直以为只有自己一个人在做什么事情,周围没有一个人懂你的时候,突然有一个人理解你的感觉。 然而过了三年,他的博客还是一句话:“未命名博客更新中”…… 当然,我不是刻意黑这位朋友,更多的是想表达一种遗憾。因为写一个独立博客的准备工作真的很麻烦很麻烦,如果像我一样在国内的话还要备案一类的繁琐程序。如果不是喜欢写博客,真的一开始就会想放弃。那么为何都准备好了,最后关键的写文章一步却放弃了呢? --- 写代码的时候老大总教育我们一句话,不要过度设计。什么叫做过度设计呢?就是和业务无关的东西写了一堆一堆,但是关键的业务的代码却写的很少。 说这个前,不得不提知乎上之前一个很流行的问题:[为什么有些大公司技术弱爆了?](https://www.zhihu.com/question/32039226/answer/76059969)当时看到的时候就想起前老大的一句话,“满足业务需求的代码就是好代码”。 对于很多还未毕业的计算机专业学生可能会觉得不可思议,尤其是看到很多外表看似光鲜的项目,底层竟然是如此垃圾的代码。甚至某些方式(如数据库的设计),完全是教科书般的错误案例。而实际上,它们只做好了一件事,满足业务需求,然而,因为做好了这件事情,它至少可以给公司带来收益。 当然,我并不是为了给烂代码洗地,对于互联网公司而言,快速的上线和迭代开发才是保证收入的根本。如果是使用智能机的你,尤其是Android手机的话,可能最大的感受就是那些APP,基本上一周恨不得更新个十几次。为何不能从一开始就是设计好呢? 从产品的角度而言,需求是不断变化的。比如输入法,一开始,人们的需求就是能打字的时候少一些选择,于是有了词库,包含常见词。后面有了按照词频不同的动态候选词序,再后来,由于互联网聊天的流行也许有了所谓的Emoji、字符画等特定需求等……但是一开始就想做好这些,是不可能的。比如你潜心花上几个月甚至几年打磨一个输入法,往往还没开发出来,要么是市场被人抢走了,要么是你自己耗死了。 话题扯的有点偏,换句话说,很多东西,不可能一开始就做的很好,如果不去做,而是一直在想怎么写好,怎么做才好,那是永远做不出来东西的。你只有上手做了,比如,先写个demo,然后完成一个主流程,再一点点考虑里面的问题细节。如果一开始就想做好,要么是你很累,想要放弃;要么是团队不会给你太多时间。 --- 记得上周参加Openresty Meetup的时候和一个架构师聊天,聊架构。在他看来,架构的存在是在公司的业务数量级达到一定的规模之后的必然产物。然而,对于一个初创公司而言,往往却是可有可无的产物。因为你的业务数量级没有到这个级别,套用**安迪比尔定理**,这个时候的业务量,无需多好的架构设计,关键是满足主要业务需求就好。按照业内常见的标准,只有业务量上升到百万这个级别,你才需要考虑架构,考虑设计。 当然这也许有点偏激,在此我保留意见,回到前面说写代码这事上。我觉得,这事应该是这么一个顺序:`能写出代码` => `能写出满足业务需求的代码` => `能够按照业务需求优化代码` => `能够考虑未来可能的需求变更预留扩展的接口` => `能将唯一可变行为剥离接口参数化` => `能在现有的语言发展层面上进行演进` => `能不再为设计模式而设计模式` => `开始理解熟记 Clean Code 的全部准则` => `拥抱 TDD,不断重构测试驱动` 当然,换种说法也许就是:不要为了设计模式而设计模式,不要提前优化,不要过度封装,不要过于追求最新的技术。 看一些牛逼的老程序员写代码就非常有意思,你会发现,他们写出来的代码,往往都十分小而简,恰当的地方使用一些让你眼前一亮的设计。当时我在写公司的开放平台,写的很累很累,花了半个多月,进展基本还是起步阶段。当时和带我的人聊天,他的一句话点醒了我:“理解需求,构建抽象实体,打通主流程”。如果我总是在想要用什么,要怎么写,也许我到今天什么都写不出来。 很多人都有完美主义倾向,什么东西,一定要做好,做棒。为此付出大量时间做准备。等到开始做的时候,才发现,后面的人已经超过了自己…… 当然,做好一件事,离不开准备。但是,只准备,不去做,那么永远做不好。我的话说完了。 --- [1]、Hello World,基本上任何编程语言的教科书,一开始都是教大家如何写一个Hello World,久而久之成为一个梗。 ![9692 - bleu ciel](/images/2020/09/2020090419530721.jpg)