# 附录

本章节属于一个比较特殊的章节,不定时更新,想到什么写什么。内容或是个人的一些感悟感想,或是对专栏中某个章节内容知识点的补充(有些知识点需要较大篇幅,不便在主体内容中体现),推荐读者阅读。

# 设计模式到底有什么用

设计模式,相信基本每一个开发者都或多或少听过,至于运用了多少就不得而知了。当然这小节并不打算跟大家把每个设计模式都过一遍,因为内容量太大,随便都是一本书的级别,在没有打赏的前提下,我不想写(收到一条群消息:都2020年了,沁尘的专栏还不更新)。本小节主要想和大家分享的是关于我对设计模式的理解,相信通过阅读本小节的内容,能让你对设计模式有个清晰的认识,在日后学习和运用设计模式的过程中可以少走弯路。

和大多数人一样,我一开始也是通过百度或者买书去学设计模式,在学习了一段时间之后的感触就是:设计模式太棒了,但是我好像用不着。不知道显示器前的你是不是也有这种想法,我一度很困惑,我写的项目,设计模式?不存在的。能运行吗?没问题。那我要设计干嘛呢?本来几行代码可以实现的逻辑,我可能要各种拆分和抽象,折腾出什么工厂类(工厂还分简单和抽象)。就在我百思不得其解的时候,突然一句话让我瞬间顿悟:世上无难事,只要肯放弃。是的,于是我干脆就不想这个问题了,继续写我的代码。当然故事肯定不可能这样就结束了,接下来的日子就是漫长的打脸岁月。项目两年时间里为了满足业务的增长和各种变化的需求,前前后后重构了三次,基本都是推倒重来的局面,上线后各种深夜修BUG那是家常便饭。这样的生活严重压缩了我的游戏时间,于是我开始想办法解决这个问题,我开始使用一些封装或者抽象来让各个功能模块做到尽可能的易于改动和扩展,而就在这个过程中,我发现写着写着有种似曾相似的感觉,似乎在哪看过,没错!是它!设计模式!于是乎,我赶紧翻开那尘封已久的设计模式相关书籍,再一次阅读那些曾经我“看了等于会了”的章节,瞬间有种顿悟的感觉,就在那一刻,我想明白了之前一直很困惑的那个问题的答案——不是设计模式无用,而是项目太小。当一个工程项目足够简单的时候,什么框架和面向对象、面向接口都是浮云,同理,给一个简单的工程项目引入什么设计模式那就是增加了项目的复杂度而且没收益的那种,因为根本就不需要。这里不妨回顾一下设计模式的由来,设计模式本身就是由无数业界大佬总结自己的编程经验而得出的,为了适应变化的解决方案,所以,如果你的项目本身就不会有啥变化或者变化很小,自然体会不到设计模式的作用。但是理论上不会变化的项目是不存在的(除非你这个项目已经凉了或者可有可无),既然有变化,我们就需要改代码。众所周知,改代码是有成本和风险的,而如何控制这个成本和风险就需要开发人员借助设计模式了。作为开发者,肯定不希望老是面对不停变化的需求,无论是从划水摸鱼的角度来说还是系统稳定性来说,但这是不现实的想法。想出设计模式的前辈们也是意识到了无法阻止变化和拒绝变化,所以总结了些套路,让我们学会拥抱变化

其实无论是从工作、学习、还是生活,个人觉得拥抱变化都是一种值得每个人拥有的态度。

看到这里,不知道读者们有没有又重新燃起了对设计模式的兴趣?当然即便没有也不要紧,只要你还写代码,你总会遇到给变化折磨得死去活来的一天,到时候你就会想到用设计模式了。最后我分享几点个人学习和运用设计模式的心得体会供读者参考:

  1. 设计模式需要理论和实践结合来学习,光看理论学不会。
  2. 看不同角度或者风格的设计模式书籍。
  3. 理论知识似懂非懂不要紧,留个印象即可。
  4. 多写项目。

# 提问的那点事

“提问”这一行为相信读者们都不陌生,大到生活,小到写代码,我们总会在前进的道路上遇到各种障碍。在面对障碍的时候,我们会有许多种应对方式,其中一种就是“提问”,也是最常用的一种,甚至是被滥用了的一种。为什么这么说呢?注意这里的其中一种这四个字,这里很直接的点明了这种方式不是万能的,再有就是“提问”本身是有前提和要求的,而很多人并没有意识到这些。很多人习惯性在遇到问题的时候就不假思索的提问,这也就是为什么有些人虽然提问,但是却始终得不到自己想要的答案、解决不了问题。其实说白了就是提问的方式不对,至于不对在哪,接下来作者分享几个本人亲身经历的真实例子,让读者们从另一个角度去体验这一过程。

  • 不要轻易提问使用搜索引擎能解决的问题

在林间有风的官方QQ群,经常会有小伙伴提问,有时候我会复制他的问题,原原本本的放到搜索引擎中回车,然后把搜索结果的页面截图发到群里回复他,这时候会有三种情况:

  1. 没人说话
  2. 谢谢
  3. 不好意思,我去看看

这里面我可能更期望的是第3种情况,因为下一次遇到问题的时候有很大概率会回想起这次可能不是那么好的经历,会让他暂时放弃习惯性的提问而先使用搜索引擎。有些人可能觉得我这样做有点不近人情或者装X,这里我要放出一张著名的“鸟哥语录”:

群聊对于解决问题真的是效率很低的一种方式。

都说程序员是面向谷歌/百度编程,这句话我觉得一半是玩笑一半却也是道出了事实,就个人学习经历而言,绝大数问题也确实是通过搜索引擎解决的。当然搜索引擎也有不灵的时候,这时候就需要其他手段了,手段里面就包含了我们的讨论主题——提问。看到这里,如果读者觉得作者就是想告诉你遇事先百度,不行再提问那就太年轻了,虽然你最后确实是要这么做的。但是这里我想让读者们在掌握方法之余,从更深的层次去看待这个事情。请你思考一下,或者试验一下,你先通过搜索引擎之后再提问和上来就直接提问,你提问的内容、方式以及得到的反馈会有什么不同,答案是会有很大的不同。除非你本身语言表达能力有问题或者说话实在很招人讨厌,不然绝大多数情况下你在尝试利用搜索引擎后再提问会收获一个答案或者解决思路。而另一种方式的下场则多数情况下是没有人鸟你或者像我一样给你个截图。看到这里似乎感觉充满了玄学,其实不然!问题之所以是问题,就是因为我们不懂,不知所措,无从下手,我们一开始掌握到的,都是一些很零碎或者很模糊的信息,这些已知信息在你通过搜索引擎一番折腾之后,虽然没有解决,但是往往会令信息更加准确或者说接近问题真相,这个时候再提问,你就能更好地描述问题(一个懵逼的人去描述一个自己都不知道是什么的问题肯定不会有满意的结果),别人也能更好的帮你定位到问题。

  • 描述清楚你的问题

这一点其实和前面的内容有一定关联,同样是在林间有风的官方QQ群中,有些问题是出现频率比较高的,而且也有惊人的神同步,接下来作者就和大家分享一下我碰到这些提问时的内心世界是怎样的:

  1. 为什么我项目部署了跑不起来?/ 这是什么问题?
    内心:我怎么知道呢?环境是什么、你部署了什么、出现了什么错误?

不要让别人对你的问题做阅读理解或者大家来找茬

  1. 这里为什么报错?(几十行报错信息的截图)
    内心:我的妈呀这都是些啥?

请提供筛选或者过滤之后的错误信息

  1. 这里为什么获取不到数据?
    内心:代码写得有问题呗。

粗心导致的问题常伴你左右

以上列举了3个高频的提问,当然这只是其中几个比较典型的。我们可以从这几个典型的提问中总结出两个共同的毛病:

  • 自己不思考。

前面我们提到过,有问题要先利用搜索引擎,这其实也是思考的过程。绝大多数情况我们通过搜索引擎和仔细检查代码都能发现问题和解决问题,但是懒惰和不自信使得我们更倾向于直接向别人提问,因为这对于自己来说“更舒适”。

  • 占用他人时间

坦白说,没有人有义务在网上花时间无偿为群众答疑解惑,你的每一个提问都意味着别人需要停下手中的事情来回答你的问题,哪怕大佬正在划水,那你也是打扰了大佬划水。正因为我们是在占用他人的时间,所以我们更应该谨慎的利用好每一次的提问的机会,在提问前先参考下第1点的内容,你的“舒适”很可能引起别人的“不舒适”。试想一下,你去医院看病,医生问你哪里不舒服,你说你猜。

  • 总结和回顾

很多人习惯性在解决一个问题后就不会再去关注这个问题,就像一个没有感情的杀手。大佬写代码就不会遇到问题了吗?答案是否定的。大佬之所以看起来像免疫一切问题一样是因为当问题出现的时候,大佬总能高效的定位问题并解决问题。这里读者可能会说,因为他是大佬,我不是呀。这里我想说的是这个看法是错误的。诚然,我们要定位和解决问题是需要一定的技术功底支撑,但是这只是一部分,另一部分则是经验使然。无论是解决程序上的问题还是其他问题,我们都会有一些通用的解决流程作参考,比如先xxx,然后再xxx,但是当你有一定的行业经验之后,你是可以跳过某些环节直接达到xxx的目的,这就是经验的作用。而经验怎么来的呢?就是通过不断总结和回顾每一次解决问题的经历。

这里可以类比医院看病,现在一些医院医生开药,都是电脑输入XX病,然后系统就会返回一套方子,点击打印开药,这就是医学临床经验的结果。

回到我们的主题本身,作者观察发现,有些小伙伴一步一坑,一坑一提问,但是仔细观察会发现,这个问题和上一个问题其实解决的思路是一样的,都是可以用同样的手段定位问题,但是小伙伴浑然不知,这就是典型的没有总结和回顾,这种学习方式是很低效且容易打击自信心的。无论是解决问题也好,学习也好,思路、过程远比结果重要,问题的症状千变万化,但是原因终归那几样,一昧的追求“实现功能即可”只会让自己在舒适区中逐渐被淘汰,人生并没有太多“躺赢”的机会。

最后,推荐各位初学者抽空阅读一下经典名著《提问的智慧》。另外说明一点的就是,无论哪个行业,技术到了一定水准之后,必然会需要利用知识输出来提高自身、突破瓶颈,所以,大佬其实是很乐意回答问题的,只要你的提问是经过思考的。

最后更新: 2020-08-02 03:50:30