Skip to content

非技术 做事情的急和快的差别

Updated: at 08:22,Created: at 00:48

我的坑队友给我推荐了一本书,开始他吹的特别好,然而我花了一点时间下载下来,再看了几页之后,我发现这就是一本毒鸡汤。然而看都看了,还是要写写读书笔记的

由于这本书属于毒鸡汤类型,我就不记录书名了。本文是记录我翻这本书翻到的一页的内容的读书笔记,这一页的大意是,如果有一个人很着急要你帮忙开发一个软件,那这时你不要急,但是要快。听起来就像听君一席话,如同听君一席话一样废话

我早上出去买早餐,路上没事干就想着上面这句废话,心里正在吐槽。去到肠粉店,看到了有好多人在排队,这时候饿了6-7个小时的我是属于急着吃。卖肠粉的老板也是加紧速度在制造肠粉。我注意到了卖肠粉的老板的动作都是加速的,但是老板会在顾客说出自己想吃什么样的肠粉加什么配料的时候,停下动作,仔细听着,听完还和顾客确认了一遍

我这样来回看了老板卖出了好多条肠粉之后,我想到了看的毒鸡汤提到的那句话,做事情不要急但是要快。换一句话来说就是做事情不要着急,不要忽略细节和需求,值得花时间认真去了解真实需求,但不要拖延,而且也需要提升基础熟练度出活速度

我认为非毒鸡汤的说法应该是,在开发软件的时候,遇到一个看起来很急的需求项时,自己开发是不能着急的。着急体现在于匆忙进入写代码模式,这时往往因为前面没有了解真实的需求,导致开发无用功比较多,事倍功半。不能着急的部分是属于决策各个选择题部分,例如应该选 A 还是应该选 B 的问题,这个在技术上会特别常见,比如这时应该选 A 库还是选 B 库好,这时应该做什么样的框架或者应该用什么样的框架才好。根据现实需要做恰当的技术选择这一步是不能着急的,选错了可能后面需要再投更多的时间来填坑。花在了解需求和技术决策上的时间是值得的

刚好最近我有伙伴和我反馈说我经常写的内容里面,只是说了有某个东西,但是某个东西和其他东西的对比性在哪。比如我最近写的 Vortice 库和 Silk.NET 库博客,这时就有伙伴问我应该选哪个,是否只有这两个可以选。假如现在是我遇到某项加急任务,需要让我来选使用哪个库的情况下,由于我对这两个库都足够熟悉,技术决策时既有底气,也能够快速按照业务需要选择合适的库。技术的决策选择也在于日常的积累,日常时可以了解实现相同的功能有哪些方法,以及对应的某个业务点有哪些实现模式,以及有哪些库的功能是重叠的,每一个的优缺点,有了这些积累,就可以方便在遇到加紧任务时,更快和更对的进行技术决策。日常开发过程,也可以自己写写笔记,比如我现在在这个模块里面用了 xx 库,使用起来感觉怎样,比如再也不用这个库了,比如这个库用起来就是顺手,下回还是使用它等等

毕竟原书只是一个毒鸡汤,我能想到这个就自己记录下来,不构成任何参考和指导意义,仅仅算是我自己的读书笔记


知识共享许可协议

原文链接: http://blog.lindexi.com/post/%E9%9D%9E%E6%8A%80%E6%9C%AF-%E5%81%9A%E4%BA%8B%E6%83%85%E7%9A%84%E6%80%A5%E5%92%8C%E5%BF%AB%E7%9A%84%E5%B7%AE%E5%88%AB

本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。 欢迎转载、使用、重新发布,但务必保留文章署名 林德熙 (包含链接: https://blog.lindexi.com ),不得用于商业目的,基于本文修改后的作品务必以相同的许可发布。如有任何疑问,请与我 联系