好久沒有更新啦，一方面是工作較爲忙碌，一方面經歷了同時幾個項目的生命週期。突然意識到，2018年，似乎沒有做過什麼年終總結，同時近段時間經歷了巨大壓力與困惑下的覺醒，突然想寫點什麼，那麼主題便是，向死而生，唯一不變的是變化。
記得上一次極限開發在0930那個時間段，爲了保證項目的上線拼盡了全力，同時使自己能力得到了極大的鍛鍊，領域業務抽象、架構流程交互閉環以及對數據領域的任務、節點、表模型、系統建設分層等等有了更深的理解。記得那時滿懷信心的準備迎接下一階段的挑戰，承接更多的項目。也許是經驗不足，也許是年輕氣盛，也許是讀專業書讀到走火入魔，在承接多項目設計、開發、測試、運維、人員指導、用戶使用問題解決、加上他人干擾的情緒、以及自己對於向上的渴望。那種感覺，讓你無法專注於任何一件事，無法聽進去任何人的話語，盲目，愚蠢，身體是騙不了自己的，嘔吐、智力嚴重下降、思維嚴重混亂。是恐懼、是憤怒、是壓抑、是絕望，是羞恥感，失去了對他人的信任，猶如黑暗籠罩在你身邊，彷彿所有人都在看着你，最終導致心態的崩潰與自我的迷失。同時這也跟個人的一些特質有關，總是在最痛苦的時候依舊要強行頂過去，但這次的管理方法不對，切換太過頻繁以及求成心切，想要每一個都能在既定時間完成。最終，在家人、朋友與同事們的引導下，把來龍去脈梳理清楚，同時放空自己，閱讀自我管理、思維方式、人物傳記以及哲學的相關書籍。同時，將各個任務項進行優先級管理、風險管理，努力讓自己專注於一件事情。最終開啓了第三隻眼，從攝像機角度審視自己的情緒與心態，貫穿價值觀、思維方式、優點與不足以及家庭經歷、工作經歷、狀態、背景的全生命週期審視。領悟我相人相衆生相，凡所有相，皆是虛妄。 隨之迴歸最佳狀態，那麼下面分享一下多項目管理全生命週期管理的一些個人看法。
1、自我管理與優先級管理
自我管理中最重要的便是時間管理與優先級管理。
時間管理，在主導或參與多個項目生命週期的情況下，如果一個項目的過程包含需求理解、設計、開發、測試、運維的話，同時4個項目（這裏的項目按照業務屬性的差異化來劃分，不以系統劃分），相當於一天之中會被來回切換無數次，同時包含會議以及對他人的指導。這個時候，如果還按照單一項目生命週期的方法是已經行不通的。因爲大家都知道，設計與開發是一個細法活兒，一定要非常專注，考慮業務抽象、代碼結構與框架以及系統與系統之間的交互。倘若被切換，再進入狀態將會重新耗費之前已經投入的相同時間，隨之慢慢地，將會變得心浮氣躁，沉不下去了。
這個時候一定要跟主管或是跟相關人員說清楚，並且列出詳細的分工計劃，暴露風險，哪怕時間線延期，也不能夠重疊同時幾個項目的各環節同時進行。在一天之中，必須有一段時間是能夠安靜的寫代碼或是架構設計或是解決問題，這個時間段不處理其他事情，哪怕一個人坐在安靜的角落裏，也要保證每天自己有專注的時間。
優先級管理，很多情況下會遇到，這個事情你會成爲中間卡點，中間卡點的意思是如果你不做這件事情，這件事情就會因此而延期。在多個時間線同一截止日期的情況下，內心是焦慮的，它一定會顧此失彼，如果稍微周邊情緒感染或影響（也許人家沒有惡意，此時焦慮的你也會理解成惡意），嚴重影響着自己的心態。而本人有個特點是極能忍，這個說好也好，說不好也不好，因爲如果一直忍下去不去溝通，最終達到爆發的臨界點，後果是不堪設想的（還好的是，每次到臨界點的時候都會去思考，沒有爆發，因爲爆發出來是沒有用的，找尋合理的環節方法）。
那麼這個時候，還是溝通，與相關人員溝通，說明各項目之間現在的問題不是落地問題，而是資源問題，不要自己硬撐。資源分配不合理，跟相關人員溝通，如果持續這樣下去，一個都做不好。將四個項目中的輕重緩急按緊急重要、緊急非重要的方法去排期，或是拉上產品，項目經理一起review一下個人的時間線，以及說明現在的做事的方法會帶來的切換嚴重性。這裏重審，不要硬抗，不要硬抗，不要硬抗。
這裏有個重要的點，如果此時你已經深陷泥潭，在黑暗籠罩之前，切記與家人、朋友、同事溝通，不要封閉自己。同時，多出去走走，什麼都不想，就關注陪你出去逛的家人啊、女朋友啊，看看電影，一起玩點開心的（這裏要注意的是，完全拋開工作場景，生活就是生活）。到了工作日再嘗試着去專注一件事。我記得，在自己最混亂的時候，已經喪失自信的時候，就想辦法鑽進去，就一個bug，程序員都知道有時候有些框架的依賴問題是很噁心的，要專注去找依賴關係，當你再次迴歸專注狀態的時候，同時恢復解決問題的能力的時候。內心會是無比的激動，臥槽啊！！太爽了臥槽啊 ~ 簡直不忍直視的大喊着。
即便狀態迴歸了，但是其實還是沒有迴歸最佳狀態，頭非常的疼，在我看來，是錯亂的神經開始重組，變得有序。此時，嘗試讓自己更加專注，讀一些名人傳記、讀一些哲學思想、讀一些你曾經感興趣的架構設計等等，只要是你想看的，能鑽進去的就去嘗試，慢慢的，就變得萌萌噠了，彷彿這個世界不一樣了，更加清醒。當然，最好呢，能出去轉轉，去別的國家，感受下不同文化的人們是怎樣生活的，這樣你會有新的感悟。（開個玩笑，臥槽，日本的小雜誌是擺在便利店的，哈哈哈哈）
2、我對架構師 以及 軟件架構設計的一些思考
首先，心態上，前兩天，跟一位曾經餓了嗎的一位架構師討論什麼是架構。對方認爲，優秀的架構呈現的應該是更加自然的世界，不應該是參雜任何個人情緒的。的確，我認爲情緒平穩、心態平穩的架構師，在專注的時候，沒有物質的慾望、或是爲了什麼而做什麼的目的性的靈性產出的架構，是最合理的架構。架構師本就是一箇中立的角色，對上需要對接產品、項目經理，對下他要對接各種技術人員，業務上還需要理解所在業務領域的核心模型。
其次，共性的東西的抽象與操作的可配置化。個人覺得，很多時候，項目的一開始是想不清楚的，會陷入一種泥潭，就是說很多共性及抽象是在業務的不斷迭代中方能呈現（這也是爲什麼要重構）。對方跟我討論了一個話題很有深意，以《建築的永恆之道》來與軟件架構設計的共通。該架構師已經領悟的相同事務的共通。
那麼以本人的愚見，無論架構也好，工程也好，任何事物都有一定的規律與共性。但規律與共性一定是在發展的過程中逐步去發現與迭代的。建築工程、軟件工程都是在解決實際問題的實用學科，同時理論已經很成熟（比如建築工程中，結構力學的相關理論）。那麼軟件工程的頂層設計原則也就相當於相關的理論，但如何做好軟件架構？下來就是要對現實問題，需求的深入理解，抽象共通，用理論指導實踐的過程。任何方法、任何架構在現階段看似是最優的架構，但架構的發展會隨着重構進行演進。那麼軟件架構，是一個遵循所在的業務範圍的迭代的過程。
在設計的時候，有時候會有一種狀態，很難去平衡架構中各個因素，有時候會覺得無從下手，糾結這個平衡的狀態。那麼此時，我們換個方式想，業務總歸是在發展，迭代總歸是要進行。在想不清楚的時候，以局部最優的方式先做起來，在問題及其迭代中逐步發現及抽象共通點，從時間、質量、成本、流程、資源的角度以及未來可能的業務發展方向來平衡整個架構。突然想到阿里一句土話，哪怕錯，也比不做要強。
3、哲學的起源與意識的進階
4、讀書與生活