我的坑队友给我推荐了一本书，开始他吹的特别好，然而我花了一点时间下载下来，再看了几页之后，我发现这就是一本毒鸡汤。然而看都看了，还是要写写读书笔记的
由于这本书属于毒鸡汤类型，我就不记录书名了。本文是记录我翻这本书翻到的一页的内容的读书笔记，这一页的大意是，如果有一个人很着急要你帮忙开发一个软件，那这时你不要急，但是要快。听起来就像听君一席话，如同听君一席话一样废话
我早上出去买早餐，路上没事干就想着上面这句废话，心里正在吐槽。去到肠粉店，看到了有好多人在排队，这时候饿了6-7个小时的我是属于急着吃。卖肠粉的老板也是加紧速度在制造肠粉。我注意到了卖肠粉的老板的动作都是加速的，但是老板会在顾客说出自己想吃什么样的肠粉加什么配料的时候，停下动作，仔细听着，听完还和顾客确认了一遍
我这样来回看了老板卖出了好多条肠粉之后，我想到了看的毒鸡汤提到的那句话，做事情不要急但是要快。换一句话来说就是做事情不要着急，不要忽略细节和需求，值得花时间认真去了解真实需求，但不要拖延，而且也需要提升基础熟练度出活速度
我认为非毒鸡汤的说法应该是，在开发软件的时候，遇到一个看起来很急的需求项时，自己开发是不能着急的。着急体现在于匆忙进入写代码模式，这时往往因为前面没有了解真实的需求，导致开发无用功比较多，事倍功半。不能着急的部分是属于决策各个选择题部分，例如应该选 A 还是应该选 B 的问题，这个在技术上会特别常见，比如这时应该选 A 库还是选 B 库好，这时应该做什么样的框架或者应该用什么样的框架才好。根据现实需要做恰当的技术选择这一步是不能着急的，选错了可能后面需要再投更多的时间来填坑。花在了解需求和技术决策上的时间是值得的
刚好最近我有伙伴和我反馈说我经常写的内容里面，只是说了有某个东西，但是某个东西和其他东西的对比性在哪。比如我最近写的 Vortice 库和 Silk.NET 库博客，这时就有伙伴问我应该选哪个，是否只有这两个可以选。假如现在是我遇到某项加急任务，需要让我来选使用哪个库的情况下，由于我对这两个库都足够熟悉，技术决策时既有底气，也能够快速按照业务需要选择合适的库。技术的决策选择也在于日常的积累，日常时可以了解实现相同的功能有哪些方法，以及对应的某个业务点有哪些实现模式，以及有哪些库的功能是重叠的，每一个的优缺点，有了这些积累，就可以方便在遇到加紧任务时，更快和更对的进行技术决策。日常开发过程，也可以自己写写笔记，比如我现在在这个模块里面用了 xx 库，使用起来感觉怎样，比如再也不用这个库了，比如这个库用起来就是顺手，下回还是使用它等等
毕竟原书只是一个毒鸡汤，我能想到这个就自己记录下来，不构成任何参考和指导意义，仅仅算是我自己的读书笔记