# 心路历程
IM-X 项目是从业以来，负责的大项目之一，但是是最复杂的一个项目；
在通知作为 项目 PIC（技术负责人） 时，我还处于 Y 项目的开发阶段，并来 STalk 后，个人大部分时间在跟进 Call 模块相关工作，对 IM 系统的整体及细节感知，相对组内其他同事来说并没有优势。
所以，我当时压力很大，怕自己完成不了任务，但也很想挑战下自己。
在给自己做了一些心理建设后，还是想硬着头皮，迎难而上。
“挑战，打破旧我，才能重塑自己。“
在项目方案讨论前一周左右时间内，梳理掌握 IM 核心流程（消息收发，消费，搜索，加载渲染，etc.），并设计端技术方案。
所幸，技术方案 Review 过程中，还算顺利，当然也有一些论点引起激烈的讨论，其实个人并不喜与人争论，但有些事情如果避免不了，且你觉得你的主张是正确的（最好有依据，别瞎搞...），那就迎接挑战，证明自己。
如果这次证明不了，下次继续，当一只打不死的小强。
项目接近尾声，Internal Release 的目标也将顺利达成。
大呼一口气，以前哪敢想象自己可以在会议室里与十几个大佬们“谈笑风生”，现在回头看看，其实也就是那一步的事情；
也许这一步很难，但跨过去，你就会发现... 发现前面还有其他怪兽要打，只是你稍微变强一点了。
借此分享一些 PUA 话语，不是我说的，别叼我；
“当你觉得不舒服的时候，就是你成长的时候，因为成长总是伴随着痛苦的。”
出自某本土话文集，有一定道理，尝试去做垫起脚尖才能事，难免会有些不适，但是在适应后，你能触及的，会上一个小高度，长此以往，慢慢就能上一个台阶。
# 技术感悟
当然技术实力也有跟随提升，对 STalk IM 系统的理解更加全面了，客户端 IM 系统的底层逻辑设计，数据缓存流转，到上层的 UI 加载与渲染，有整体的理解，并熟悉掌握一些细节。
但更多的，是学习到一些方法论，
“技术人有时容易陷入按直觉走的怪圈，直觉不是100%准确的，技术方案要有所依据。”
“技术人要具有架构的前瞻性，这要求你全面感知并深入理解整个系统。”
原话是不是这样有点忘了，大意就是这样，谢谢大佬们的指点。
同时技术视野也有所开阔，
设计技术方案时，往往会遇到高性能与低成本的矛盾，这是个很难平衡的问题，我觉着，在不影响项目进度的前提下，我们应该追求高性能方案；
如果你总是退而求其次，选择低成本低性能的方案，那么自己的能力会慢慢弱化，技术这种东西，就如
“逆水行舟，不进则退。”
就像排序算法，用冒泡排序，实现很简单，但性能低，用快排，实现复杂些，但性能高啊；如果你总是用冒泡排序，有一天你会发现写不出快排了。
当然技术界也很流行一句话，
“没有银弹。”
你懂的，追求性能，难免就会带来一些技术成本。
# 技术心得
涉及到开发心得，其实我不算资深，其实也没干货能分享的，只是自己有个技术习惯，希望对大家有帮助。
我是保守的技术人，无论是写需求还是解BUG，习惯把逻辑上下文梳理清晰，把握变更代码的逻辑边界后，再编写解决方案，最后着手开发。
一个准确的技术方案，慢一点无所谓，只要方向对，前期就不怕慢，一个错误的方案，在开发前期，也许会有些效率的提升，但一旦错误显现，返工成本将十分巨大。
某本土话文集里，有句话和这个观点不谋而合，
“想清楚，再办事。”
对技术人来说，把握技术方向的准确性十分重要；对一线开发来说，准确的技术感往往体现在项目技术方案的设计上，一个优秀的技术方案有一些特点，
# 契合现有系统实现
这要求开发对项目涉及的系统有全面深入的理解，方案越契合现有系统，开发维护成本越低，系统新增的技术负担也会越少。
# 面向失败设计
我觉着这个准则，可以理解成面向BUG设计，当你写代码时，是否有考虑到所有边界，是否兼容所有异常，输入输出是否在预期之内；这往往需要设计单测保障，但天朝互联网似乎没有这种技术文化。
# 适当的面向未来设计
不要先污染后治理，如果重构成本不大，技术方案应该考虑进去；适当地通过设计模式减少条件分支，合理地运用抽象继承组合，这些都有助于把复杂的需求简单化，需求“简单”了，开发就更得心应手了。
# more.
简述下， X 项目的技术设计，逻辑层及UI层，基于现有的系统框架，抽象改造可复用的逻辑及组件，派生或组合出 Room 与 Thread 两套逻辑与 UI，在后续项目维护上，
尽可能地避免了相似功能的代码重复问题，同时通过继承保留差异化的能力，更重要的是，一定程度上隔离了相关逻辑，保障新版本上线后灰度过程的稳定性。
# 技术“道德”
开发 X 项目过程中，我也在纠结是否重构复用一些代码，若重构复用，难免会带来一些时间成本导致项目进度拖慢，若不，大量的重复代码会给系统维护带来很大负担； 后面我还是决定当个有职业道德的程序员哈哈哈，完成重构任务，拒绝先污染后治理；
回头看看年初写的一些技术见解，能保持初心，也算是件好事吧，在这里分享给大家，关于代码质量一些见解。
# 感谢
十分感谢项目过程中，前辈与同事们的帮助，如果期间有些冒昧地方，表示歉意。
# 备注
技术心得与感悟，仁者见仁，智者见智，以上只是个人的一些见解，不喜勿喷；推荐相关技术书籍，推荐《代码整洁之道》(Read) 《人月神话》(Reading)《架构整洁之道》(Todo)
