阅读 2673

让你选一句话裱起来,你会选什么?

原文链接

摩尔定律对软件开发也是间接奏效的,每过18个月,就会有一半的知识会过期。我之前写的有些文章就已经过期了,今天我们来聊一个不会那么容易过时的话题 —— 那些业界‘大佬’是怎么思考的? 一个结构化的知识体系是怎样的?

不过要提前说明,本文没那么严肃,仅作抛砖引玉。如果你想要多了解这方面的知识,应该多读几本经典的书籍。


从思考框架到基本原则,到具体最佳实践

前些日子学习了 《10x程序员工作法》《研发效率破局之道》,内容本身质量很高自不必说,给我启发较大的是他们的内容组织方式。以 《10x程序员工作法》为例,它的内容是这样组织的:

这种设计可以让我们直观地把握课程的主要脉络。

思考框架是事物的出发点,用于审视目标、把握方向;基本原则是在思考框架下的核心指导思想;最后在基本原则指导下进行具体实践。后面会详细说明这三者的关系。

在我看来,这才是一种结构化的知识体系。这种方法可以帮助你建立一套自己的知识体系、认知模型,还可以用来指导你的行动实践。希望本文也可以给你一些启发。



思考框架

最上层的思考框架往往是一些哲学问题,无非就是保安经常问你的那三个问题:

  • 你是谁?
  • 从哪来?
  • 到哪去?

还有类似的 WWH

  • Why? → 目的、理念
  • What?→ 定义、概念、现象或成果
  • How? → 具体操作方法、措施

《10x 程序员工作法》的思考框架是:


估计这个思考框架你从小学、幼儿园老师就会教你,不用多解释。那么问题来了,大家有没有形成这样的思考习惯呢?

这个思考框架,虽然简单,却可以受益终生。

它可以是任何行动的基础。比如我在 上一篇文章中“如何看待新技术章节” 也套用了这个模式:

  • 这是啥玩意?
  • 解决什么问题?
  • 怎么解决的? 思想 → 流程 → 实现

再比如下次产品经理给你一个需求,套用这个框架,你可以问他:

  • WHY?为什么要这个做这个功能? 它可以给用户带来什么价值? 或者说能给公司带来什么收益? → 没价值,就没有做的意义
  • WHAT & HOW ? 什么样的用户会用到这个功能,他们在什么场景下使用,他们又会怎样使用它?实现这个功能就只有这种方式吗?还有没有其他方案? → 可以衡量这个功能是否有经过认真思考的,是不是自己 YY,是不是合理

如果产品回答不上来,那不好意思,回去等通知吧。


碰巧最近也招人(简历砸过来 Y2FybmV5NTIwQGhvdG1haWwuY29t),按照上面的套路,我可能会这样考察你的'要性'(阿里土话,道听途说):

  • 你觉得你现在处于什么水平?有哪些不足
  • 你的目标是什么?想加入什么样的团队?
  • 你有什么计划?

OK,这里留一个思考题,如果你的老板在画大饼,你会怎么怼他呢?



原则

接下来是在思考框架指导下的‘原则’。这些原则相比思考框架要具体一些,是针对特定领域的思想指导,在处理某个特定领域的问题时会更有用一些。

比如 《10x 程序员工作法》归纳了四个原则:

因为是付费专栏,所以我也不多剧透,可以看它的导读

可以举其他我们比较熟悉的例子,比如面向对象设计的 SOLID 原则:

  • S 单一功能原则: 认为“对象应该仅具有一种单一功能”的概念
  • O 开闭原则: 认为“软件体应该是对于扩展开放的,但是对于修改封闭的”的概念。
  • L 里氏替换原则: 认为“程序中的对象应该是可以在不改变程序正确性的前提下被它的子类所替换的”的概念。
  • I 接口隔离原则: 认为“多个特定客户端接口要好于一个宽泛用途的接口” 的概念
  • D 依赖反转原则:认为一个方法应该遵从“依赖于抽象而不是一个实例” 的概念。依赖注入是该原则的一种实现方式。

搞对象的人,看到这些原则就会如数家珍,刚入门的小白可能比较难以理解。他们是历代火影燃烧火的意志沉淀下来的宝贝,没有经过战场的洗礼理解可能不会那么深刻。



说一个我编程生涯比较受用的原则,那就是 DRY(Don't repeat yourself),因为它相比SOLID原则、KISS原则,更好理解、或者说更有实践性

DRY 原则简单说就是识别你的重复代码,思考,然后重构它。

如果你在编程时养成了这种习惯,你会发现你的代码自然而言会有比较良好的结构,同时也可能符合上述各种原则一些特征(实际上它们本来就是交叉和相通的)。

或者说,经过 DRY 原则下的刻意训练,你会形成一种编程品味( 敲黑板,这也是大厂考点)。


类似思想/原则还有很多,比如 Unix 哲学 、Windows 哲学,还有一些算法思想:

经典算法思想,来源zhuanlan.zhihu.com/p/73144439


Unix 哲学

上图有两个彩蛋:

  • 一个是 Ken Thompson(Unix、Go 作者之一,真大神级人物) 非常实用的‘建议’: “拿不准就穷举”, 干就是了,干了再说。

    Unix 哲学用一个词概括就是 KISS(Keep It Simple, Stupid),在这个'面试造火箭,上班拧螺丝钉'内卷年代, 很多人容易走偏,把事情复杂化,写一些花里胡哨代码,做一些花里胡哨的功能。Unix 的远古哲学告诫我们:简洁就是好,好就是简洁

  • 第二个是我自己写的,尽管大学时就看过这本书,当时只有盲目崇拜,时隔多年再看,这些原则个个是说到心尖上了,顿时感叹应该把这些'哲学'裱起来,日看夜看。这也是本文的灵感来源。


Windows 哲学


这些原则你说难吗?其实不难,几句话就可以说清楚。

如果你是多年的老鸟,可以让你返璞归真。如果你是菜鸟,那你应该背诵下来(开玩笑),或者裱起来挂客厅、搞成壁纸、做成鼠标垫、印在保温瓶上...



具体的最佳实践

再往下更具体,这是在原则指导下、经过实践总结出来的最佳实践/设计模式。可以用于指导解决具体的领域问题。

还是以 《10x 程序员工作法》为例,它最终的知识结构如下:


举大家比较熟悉的例子,最典型的莫属于面向对象的《设计模式》,它就是属于这个层次的知识:

来源:my.oschina.net/u/4353432/b…

设计模式就是在 SOLID 原则指导下的具体实践。



并不是说我们只要学习思考框架和指导原则就行了,最佳实践也是要刻意学习的。三个层次相得益彰,这样形成的知识体系才是比较稳固的

  • 最佳实践是在思考框架和指导原则下形成的产物。如果只是掌握最佳实践,停留在皮毛,不去挖掘它的内在思想,则不能做到内化和升华。如果有幸,来到了一个新大陆,这里没有任何最佳实践和设计模式,要怎么办呢?

  • 思想和原则不能脱离实践。

    最佳实践通常是别人实践总结出来的, 能复用的就复用是吧?最佳实践、准则、对我们来说是站在巨人的肩膀上,是捷径,让我们可以少走点弯路。

    由于每个人的场景千差万别,别人的实践并不一定适合你, 或者你走在世界前头,上层的思想则是创造最佳实践的有用指导。

    另外实践也在深化我们对上层思想的理解。

  • 实践和思想是相互验证的关系。


后面大家看书、学习某些课程时,可以留意一下它们的组织结构,某种程度上可以折射出作者的水平。

一切都是套路,套了又套。



那么,让你选一句话裱起来,你会选什么?

不要跟我扯什么自*、民*、和*...

来点实际的,软件开发领域选一句让你受益匪浅的话,裱起来告诫自己/后人,你会选什么?

我举一些例子吧:

  • KISS

  • DRY

  • SOLID

  • SPOT

  • Unix 哲学 17 大原则

  • 程序员的三大美德:懒惰、急躁、傲慢。

    来源于Perl 作者 Larry Wall, 附带相关解释:

    • 懒惰,是一种品质,它会使你花很大力气去规避过度的精力消耗,敦促你写出节省体力的程序,别人也能很好地利用,你还会为此写出完善的文档,以免别人来问问题。
    • 急躁,是计算机偷懒时,你会感到的一种愤怒。它会促使你写出超越预期的程序,而不只是响应需求。
    • 傲慢,极度自信,写出(或维护)别人挑不出毛病的程序。

    —— Larry Wall

    不是开玩笑,这真是美德。如果身边多几个这样的程序员,就不用996了。

  • Stay hungry, Stay foolish —— Steve Jobs

  • Talk is cheap. Show me the code —— Linus Torvalds

  • ...



本文提及 & 扩展阅读

《Unix 编程哲学》

《10x程序员工作法》

《设计模式》

还不懂这八大算法思想,刷再多题也白搭!

学好算法,有三重境界

程序员必须掌握哪些算法?

Talk is not cheap

《10x程序员工作法》

《研发效率破局之道》

文章分类
前端
文章标签