64 lines
6.7 KiB
Plaintext
64 lines
6.7 KiB
Plaintext
---
|
||
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”的程度。
|
||
---
|
||
|
||
|
||
|
||
上周和一个即将毕业的大学生聊天，他很厉害，学了很多，抱怨到很多人学了很多编程语言，但最后都只是会写一个“Hello World”<sup>〔1〕</sup>的程度。我说，因为他们大多是一直在准备学习，往往刚开始学的时候，便放弃了。
|
||
|
||
<p style={{textAlign: 'right'}}>——题记</p>
|
||
|
||
我叫雨帆，所有的汉字中我觉得我“雨”、“帆”这两个字写的最好看，不是因为我字写的好，而是因为我专门针对这两个字专门练习。
|
||
|
||
同样的话语可以套在很多东西上，许多东西，比如人的技能，擅长的东西，并不是一蹴而就的，需要频繁的练习。没有谁能一开始就能成长为参天大树，即使是所谓的天才，在你看不见的背后，也有着常人难以想象的汗水与努力。
|
||
|
||
所以一直一来，我很赞同一句话：[信念永远不能达到目的地](/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，久而久之成为一个梗。
|
||
|
||
|