题图：Streetwill
这周是全力以赴的写代码的一周。独立开发一个模块的好处是可以自己把控自己的代码、抽象及设计，不用依赖别人的代码逻辑；劣势是需要完全清晰的认识整个数据流的走向，想清楚所有的边界。
目前接手的这块是项目的核心模块，虽说在技术评审的时候对全流程有了足够的认识，但是在coding时还是感觉对其中的细节力不从心。一周5天，基本上3天在边coding边顺逻辑、理细节边界，2天在全力coding。当然还免不了穿插各种会议。
所以，比较有感触的一点：是否有可能在coding之前充分清晰逻辑细节？这是否需要强大的脑力来运算？还是说细节边界只有在coding时才能全面清晰是一种常态？怎么在coding之前、或者说是评审的时候把这种因细节认识不到位差点走不下去风险扼杀在摇篮里。这块真的值得去深度挖掘一下，技术细节风险怎么把控。
得亏架构师就坐我旁边，我能时不时的探讨答案。但是大部分人没有这么好的机会，所以这会成为开发效率的拦路虎。自己都不知道自己要做到哪种程度，效率怎么上的去。
我的认识：还是只能在实践中出真知。写得够多，在实现之前会有预知的能力，预判细节边界带来的风险。但是实践到哪种程度，我不知道。我只能先多写试试看。
延误了很多天的分享初稿经过周末两天的赶工，终于完成了90%了。突然发现要深入浅出真的挺难的，深入就挺难，浅出就更难了。一个顶尖项目的设计架构思路可能就够我们啃好久了。半个月之前就在写《kafka从入门到实践》分享稿，起初觉得挺简单的，kafka系列去年就看过了。但是越写越觉得不对劲，咋越写越多，越写越搞不懂了。其中的细节之前都没见过，也没有考虑过。同时为了强化自己的认识，我尽可能的针对要点多画图，画图就占了我差不多三分之一的时间。其中仍然有很多东西没有搞得特别清楚，只能略过。就算不讲也不能讲错。
工作之余给自己定的kpi太多了。太多要做的。感觉时间真的不够用。一天要是有48个小时就好了。
#
