好久没有更新啦，一方面是工作较为忙碌，一方面经历了同时几个项目的生命周期。突然意识到，2018年，似乎没有做过什么年终总结，同时近段时间经历了巨大压力与困惑下的觉醒，突然想写点什么，那么主题便是，向死而生，唯一不变的是变化。
记得上一次极限开发在0930那个时间段，为了保证项目的上线拼尽了全力，同时使自己能力得到了极大的锻炼，领域业务抽象、架构流程交互闭环以及对数据领域的任务、节点、表模型、系统建设分层等等有了更深的理解。记得那时满怀信心的准备迎接下一阶段的挑战，承接更多的项目。也许是经验不足，也许是年轻气盛，也许是读专业书读到走火入魔，在承接多项目设计、开发、测试、运维、人员指导、用户使用问题解决、加上他人干扰的情绪、以及自己对于向上的渴望。那种感觉，让你无法专注于任何一件事，无法听进去任何人的话语，盲目，愚蠢，身体是骗不了自己的，呕吐、智力严重下降、思维严重混乱。是恐惧、是愤怒、是压抑、是绝望，是羞耻感，失去了对他人的信任，犹如黑暗笼罩在你身边，仿佛所有人都在看着你，最终导致心态的崩溃与自我的迷失。同时这也跟个人的一些特质有关，总是在最痛苦的时候依旧要强行顶过去，但这次的管理方法不对，切换太过频繁以及求成心切，想要每一个都能在既定时间完成。最终，在家人、朋友与同事们的引导下，把来龙去脉梳理清楚，同时放空自己，阅读自我管理、思维方式、人物传记以及哲学的相关书籍。同时，将各个任务项进行优先级管理、风险管理，努力让自己专注于一件事情。最终开启了第三只眼，从摄像机角度审视自己的情绪与心态，贯穿价值观、思维方式、优点与不足以及家庭经历、工作经历、状态、背景的全生命周期审视。领悟我相人相众生相，凡所有相，皆是虚妄。 随之回归最佳状态，那么下面分享一下多项目管理全生命周期管理的一些个人看法。
1、自我管理与优先级管理
自我管理中最重要的便是时间管理与优先级管理。
时间管理，在主导或参与多个项目生命周期的情况下，如果一个项目的过程包含需求理解、设计、开发、测试、运维的话，同时4个项目（这里的项目按照业务属性的差异化来划分，不以系统划分），相当于一天之中会被来回切换无数次，同时包含会议以及对他人的指导。这个时候，如果还按照单一项目生命周期的方法是已经行不通的。因为大家都知道，设计与开发是一个细法活儿，一定要非常专注，考虑业务抽象、代码结构与框架以及系统与系统之间的交互。倘若被切换，再进入状态将会重新耗费之前已经投入的相同时间，随之慢慢地，将会变得心浮气躁，沉不下去了。
这个时候一定要跟主管或是跟相关人员说清楚，并且列出详细的分工计划，暴露风险，哪怕时间线延期，也不能够重叠同时几个项目的各环节同时进行。在一天之中，必须有一段时间是能够安静的写代码或是架构设计或是解决问题，这个时间段不处理其他事情，哪怕一个人坐在安静的角落里，也要保证每天自己有专注的时间。
优先级管理，很多情况下会遇到，这个事情你会成为中间卡点，中间卡点的意思是如果你不做这件事情，这件事情就会因此而延期。在多个时间线同一截止日期的情况下，内心是焦虑的，它一定会顾此失彼，如果稍微周边情绪感染或影响（也许人家没有恶意，此时焦虑的你也会理解成恶意），严重影响着自己的心态。而本人有个特点是极能忍，这个说好也好，说不好也不好，因为如果一直忍下去不去沟通，最终达到爆发的临界点，后果是不堪设想的（还好的是，每次到临界点的时候都会去思考，没有爆发，因为爆发出来是没有用的，找寻合理的环节方法）。
那么这个时候，还是沟通，与相关人员沟通，说明各项目之间现在的问题不是落地问题，而是资源问题，不要自己硬撑。资源分配不合理，跟相关人员沟通，如果持续这样下去，一个都做不好。将四个项目中的轻重缓急按紧急重要、紧急非重要的方法去排期，或是拉上产品，项目经理一起review一下个人的时间线，以及说明现在的做事的方法会带来的切换严重性。这里重审，不要硬抗，不要硬抗，不要硬抗。
这里有个重要的点，如果此时你已经深陷泥潭，在黑暗笼罩之前，切记与家人、朋友、同事沟通，不要封闭自己。同时，多出去走走，什么都不想，就关注陪你出去逛的家人啊、女朋友啊，看看电影，一起玩点开心的（这里要注意的是，完全抛开工作场景，生活就是生活）。到了工作日再尝试着去专注一件事。我记得，在自己最混乱的时候，已经丧失自信的时候，就想办法钻进去，就一个bug，程序员都知道有时候有些框架的依赖问题是很恶心的，要专注去找依赖关系，当你再次回归专注状态的时候，同时恢复解决问题的能力的时候。内心会是无比的激动，卧槽啊！！太爽了卧槽啊 ~ 简直不忍直视的大喊着。
即便状态回归了，但是其实还是没有回归最佳状态，头非常的疼，在我看来，是错乱的神经开始重组，变得有序。此时，尝试让自己更加专注，读一些名人传记、读一些哲学思想、读一些你曾经感兴趣的架构设计等等，只要是你想看的，能钻进去的就去尝试，慢慢的，就变得萌萌哒了，仿佛这个世界不一样了，更加清醒。当然，最好呢，能出去转转，去别的国家，感受下不同文化的人们是怎样生活的，这样你会有新的感悟。（开个玩笑，卧槽，日本的小杂志是摆在便利店的，哈哈哈哈）
2、我对架构师 以及 软件架构设计的一些思考
首先，心态上，前两天，跟一位曾经饿了吗的一位架构师讨论什么是架构。对方认为，优秀的架构呈现的应该是更加自然的世界，不应该是参杂任何个人情绪的。的确，我认为情绪平稳、心态平稳的架构师，在专注的时候，没有物质的欲望、或是为了什么而做什么的目的性的灵性产出的架构，是最合理的架构。架构师本就是一个中立的角色，对上需要对接产品、项目经理，对下他要对接各种技术人员，业务上还需要理解所在业务领域的核心模型。
其次，共性的东西的抽象与操作的可配置化。个人觉得，很多时候，项目的一开始是想不清楚的，会陷入一种泥潭，就是说很多共性及抽象是在业务的不断迭代中方能呈现（这也是为什么要重构）。对方跟我讨论了一个话题很有深意，以《建筑的永恒之道》来与软件架构设计的共通。该架构师已经领悟的相同事务的共通。
那么以本人的愚见，无论架构也好，工程也好，任何事物都有一定的规律与共性。但规律与共性一定是在发展的过程中逐步去发现与迭代的。建筑工程、软件工程都是在解决实际问题的实用学科，同时理论已经很成熟（比如建筑工程中，结构力学的相关理论）。那么软件工程的顶层设计原则也就相当于相关的理论，但如何做好软件架构？下来就是要对现实问题，需求的深入理解，抽象共通，用理论指导实践的过程。任何方法、任何架构在现阶段看似是最优的架构，但架构的发展会随着重构进行演进。那么软件架构，是一个遵循所在的业务范围的迭代的过程。
在设计的时候，有时候会有一种状态，很难去平衡架构中各个因素，有时候会觉得无从下手，纠结这个平衡的状态。那么此时，我们换个方式想，业务总归是在发展，迭代总归是要进行。在想不清楚的时候，以局部最优的方式先做起来，在问题及其迭代中逐步发现及抽象共通点，从时间、质量、成本、流程、资源的角度以及未来可能的业务发展方向来平衡整个架构。突然想到阿里一句土话，哪怕错，也比不做要强。
3、哲学的起源与意识的进阶
4、读书与生活