0. 引言
目前，有太多的資訊都以電子資料的形式存在，也有太多的工作和生活被繫結線上上。在這個連貨幣都馬上要數字化的時代裡，如何打理好自己的數字生活，保護好自己的數字資產，很重要。
1. 需求分析
作為一個非典型程式設計師和深度學習煉丹師，平常又會逛逛論壇，寫寫BLog，程式碼和文件是最常要處理的兩類數字資料。
此外，業餘還喜歡拍照，大量的照片也需要妥善保管。
總結核心需求如下：
-
資料在必要時較易實現本地化
-
資料在必要時較易實現跨平臺遷移；
-
對於不同型別的資料，分場景進行儲存和備份；
-
儘量提高資料儲存和備份的自動化程度。
1.1 本地化
本地化的意思是指，我可以把原始格式的資料拉取到本地磁碟上。這也是針對於雲服務越來越盛行的現狀所說。
在合理的場景中，線上化、上雲是大勢所趨，我也是擁護者和受益者。工作中，在需要協作的場景下，我已經不止一次地去推動如騰訊文件、禪道等工具的使用，來取代老舊的Office式專案管理模式。
但對於需要積累和沉澱的資料，全部線上化，我是心懷擔憂的。
我不怕被雲端繫結，但我怕被雲端綁架。
我希望能夠享受雲端的便利，但在最壞的時刻，還有一個託底方案，能夠把所有的原始資料掌握在自己手中。
1.2 跨平臺遷移
既然我不希望我的資料被雲伺服器綁架，類似地，我也不希望我的資料被某一款軟體或系統所綁架。
舉例來說，我自認是一個喜歡整理和總結的人，但對於《印象筆記》這款號稱第二大腦的筆記軟體，我一直是採取迴避的態度。
它太封閉了，除非用一些黑科技手段，你很難把你儲存在裡面的資料原封不動地搬運出來。你使用得越多，你就被套牢越深。假如有一天它的系統崩潰，或公司倒閉，對你來說就是滅頂之災。這種頭懸利劍的感受很不好。
再比如，一款常用的生產力工具，如果是某作業系統獨佔（MacOS，說的就是你），那我一般不會選擇用它，我會優先選擇Win/Linux/Mac跨平臺相容的軟體。
目前，我在辦公室的工作終端是Win10，還有一臺Linux的遠端伺服器，在家的電腦是Ubuntu。為了保證單位和家之間的工作狀態無縫切換，工具的跨平臺相容性很重要。
1.3 分類和自動化
程式碼，文件，資料，程式檔案，照片等不同資料的儲存要求有非常大的差異。這主要從修改的頻率和資料本身的大小兩方面體現。
因此也就需要選擇不同的方案。我主要會從Git託管，網盤，NAS和行動硬碟四個方面去考慮。
自動化的需求主要是為了對抗人的思維惰性，如果一切都依靠繁瑣的手動操作，那麼很可能堅持不了多久。
2. 實現思路
2.1 個人知識庫
前面說過，我對於把自己稱為“第二大腦”型別的軟體是迴避的。
但對於這種理念，我是十分贊同的，收集-整理-輸出，完整經歷這一過程，知識才能被更好地掌握。
只不過我願意多花費一點點時間和操作，自己來掌控這個流程。來實現前述的“本地化”，“跨平臺”等原則。
2.2 資料分類
經過分析，將資料按如下類別進行分類：
| 類別 | 特點 |
|---|---|
| 程式碼/筆記/文件 | 重要性高，修改頻繁，文字化 |
| 其他文件資料 | 多樣化，零碎 |
| 大體積資料 | 修改少，持久儲存 |
-
程式碼、筆記、文件：所有靠自己碼出來的文字類資料，含金量最高。所有特性都指向了一種最合適的儲存方式，那就是Git。有保密要求的，託管在公司內網Git；無保密要求的，我會在Github/Coding等多個平臺同步託管。
-
其他文件資料：工作/生活中有大量這類文件，比如下載的各種論文/電子書，工作中的各種PDF/WORD/EXCEL，檔案增刪較為頻繁，但檔案內容本身修改頻率並不高，這種時候，最合適的應該是同步盤工具。
-
大體積資料：比如照片/視訊，大量的樣本資料，下載的視訊課程，一些需要保留的程式安裝檔案等，基本沒有修改的需求，但需要持久儲存，並方便隨時讀取。我置辦了一個小型的NAS，主要用於這類需求。只要能聯網，手機和電腦就可以隨時隨地接入看網課或者翻看以前拍攝的照片和視訊。此外，每隔一段時間，我還會將整理過的照片/視訊在網盤上備份一次。
-
最後，大概以每月一次的頻率，我會將所有型別的資料在行動硬碟上備份一次，作為最後的保險。
2.3 文件/筆記
工程程式碼和對應的文件是工作產出要求，而在此以外的文件和筆記，則是個人持續積累和提升的關鍵，這邊專門談一談。
對於個人文件/筆記，我採用的是一種去中心化的方案。
說得更直白一點，我更傾向於用最傳統的本地資料夾方式來組織和管理，同時利用Git這樣的版本管理工具，實現檔案的多端同步。
對於現在也很流行的標籤式管理體系，暫時沒有領會其精髓，在實際操作上往往也需要與系統或軟體強繫結。如果未來有第三方的工具能夠進行這方面的增強，我可能會嘗試一下。
在遵循Git基本規範，操作得當的情況下，所有的文件會在我所有的電腦和多個遠端託管平臺上保持同步更新，以此達到：
-
極高的標準化，一處編寫，多處使用；
-
極高的安全性，因為同時損壞或丟失的情況幾乎不可能發生。
3. 工具推薦
合理而順手的工具可以大大提高工作效率和工作時的幸福感。我也很喜歡嘗試和折騰一些效率/生產力型別的工具。
為了配合前面提到的所有指導原則和實施思路，下面推薦一些我用過或正在使用的工具。
3.1 Markdown及相應編輯器
大部分程式設計師應該都很熟悉Markdown。
不Coding但是有碼字需求的人，也強烈推薦嘗試一下。
這是一個用過後就再也回不去的神器。如非必要，我現在絕不會主動開啟MS-Office，因為Markdown太好用了。
Markdown的優點，我總結主要有以下幾點：
-
純文字，簡單快速；
-
相容性高，格式統一；
-
能夠被git diff所識別。
缺點可能就是對於複雜的排版支援不夠。
概括地說，就是方便寫文，特別是技術類文件，但不方便寫書。
雖說任何文字編輯器都可以用來寫Markdown，但是一個順手的寫作工具還是能夠提高效率和舒適度。專門支援Markdown寫作的工具軟體有很多，這邊推薦三款。
3.1.1 VSCode
同型別的還有Atom和SublimeText，它們本質上都是程式碼編輯器，自身或者通過外掛擴充套件，可以實現Markdown的編輯功能。
但使用體驗來說，VSCode是最好的，而微軟官方的Remote系列外掛，則完美符合我的使用需求，只此一項就秒殺了另外兩款。
作為一個Vim盲的我，除錯程式碼時再也不用本地編輯後，手動用SFTP上傳伺服器執行了。
VSCode可以相容編碼和簡單的Markdown編輯需求，但體驗上跟專門的Markdown編輯器還是有些差距，最主要體現在快捷鍵的支援範圍，以及插入圖片等附件時的便利性。如果想要真正體驗飛一般的輸入快感，你需要下一款。
3.1.2 Typora
這個軟體在網上的口碑非常好，我自己使用的體驗也很棒，目前是我的主力編輯器。
將Markdown這種標記語言的特性和所見即所得的功能整合起來是它的特色。而對於插入圖片的操作優化，特別符合人的使用直覺，進一步降低了學習成本。
3.1.3 Mark Text
Typora雖然目前免費使用，但它屬於閉源軟體，等正式版推出，估計會收費。如果軟體足夠好，我也是願意付費的，但本著保險起見的原則，我又搜尋到這樣一款開源軟體，幾乎完美實現了Typora的所有優點。
Mark Text在一些細節上可能還需要打磨，但已經足堪大任。我目前在自己的Ubuntu系統中，就是使用的Mark Text。
3.2 Git及託管服務
3.2.1 Git
Git幾乎可算是現代程式設計師的必備技能。但用來做文件的同步管理也是非常棒的，如果只是個人用來管理文件，不涉及分支和協作的話，Git其實很簡單，只需要用到非常有限的操作，而且目前也有足夠多的視覺化工具可以輔助。
3.2.2 Git託管服務
關於Git託管服務，公司內網的本地部署採用的是Gitea的方案。
公網的話，Github是繞不過去的。但鑑於某些原因，Github的登入不是很穩定，傳輸速度也非常感人，因此，我還會同時託管在Coding和Gitee上，連線穩定快速多了。
3.3 同步盤/網盤
3.3.1 堅果雲
堅果雲大概是目前國內唯一一款，免費使用者也能用得比較舒心的同步盤產品。
Win/Linux/Mac/Android/iOS/Web全平臺相容。
日常辦公涉及的文件資料，我都是通過堅果雲實現自動同步。只要注意一下不要把特別大的檔案放到同步地址下，每個月免費的上傳下載額度基本足夠使用了。
也有一些別的軟體支援同步盤，但功能都有些缺陷，比如不支援多個終端的同步，不能自由設定多個同步地址等，堅果雲還是最好用的。
3.3.2 百度網盤
雖然不充會員就特別慢，但是似乎也沒有其他更通用的選擇了。據說阿里雲也要出個人網盤了，希望能帶給我們更多選擇。
3.4 NAS
目前用的不算標準NAS，是聯想出的一款個人雲端儲存。當時買它主要是看中了便宜，首發期間有很大優惠，幾乎等於買機械硬碟送NAS。但也滿足基本需求了。
後邊如果要升級的話，可能會考慮威聯通或者群暉的產品。硬體方面的動手能力很弱，就不考慮DIY方案了。
3.5 其他
再推薦一個自己用得比較順手，覺得很有價值的工具。
3.5.1 Teambition
這原本是一個團隊專案管理工具，但其實用來做個人任務管理和日常生活的協作都很好。
還有一些其他類似的線上工具，比如Trello，Worktile，Tower等可以選擇。
（1）用於個人：
我會把Teambition當做一個便籤和TODO-List來使用，用專案的方式分類管理起來。
比如把閱讀清單作為一個專案，分為“在讀/已讀/待讀”三個任務列表，每本書作為一個任務，任務詳情中可以記錄一些簡單的閱讀情況。甚至看到一些精彩或有用的段落，通過截圖或拍照的方式，把圖片上傳在備註中，留待後期的進一步整理。把書看完後就可以把任務置為完成。
再比如把Blog寫作作為一個專案，想到一個可寫的主題就列為一個任務作為備選，任務詳情中可以隨時記錄一些點子和零散的資料。這樣，就可以累積起不少素材。寫完成篇後就可以把任務置為完成。
自從用了這種方式，讀書的效率提高了不少，特別是把一本書讀完的概率提高了不少；而Blog的產出效率也提高了。
（2）用於家庭協作
家庭生活中，一些重大的事項其實也可以看作一個個專案，我跟老婆經過一段時間的嘗試，也摸索出一種用專案管理的理念來提高生活條理性和規劃度的模式。
之前我們還用過微軟的ToDo，簡單的協作也很不錯，比如購物清單，快遞備忘等，但是更復雜更長時間跨度的協作管理就感覺有些力不從心了。目前ToDo還在使用中，但僅限於這些短平快的備忘性質任務。
比如把家庭出遊當做一個專案，分為“待出行/構想中/已出行”三個任務列表，每一次出遊作為一個任務，任務詳情中可以記錄出遊的各項細節情況，比如目的地、住宿預訂、車票機票預訂、景點門票預訂等，還可以把攻略和參考連結附上。回來後，在專案Wiki裡，還可以寫遊記。
以後回顧起來非常清晰明瞭，甚至系統自動的統計報表功能，可以幫你完成出遊的資料統計。
其他比如買房/裝修，娃上學擇校等，都可以列為專案，進行更有條理的規劃。
4. 關於寫作
看到過有人說，程式設計師都應該學會寫作，都應該去寫部落格。話雖說得絕對，但我覺得有道理。
程式碼是一種語言，日常用語也是一種語言，只不過一個是要讓機器讀懂，一個是要讓人讀懂。而把語言和邏輯組織好，並表述清楚的能力，其實是相通的。
並且，在一定規模的團隊協作專案中，使程式碼能夠讓人看懂，可能比讓機器看懂更重要。讓人看不懂的程式碼，就算當時寫得再精巧再完善，無法維護始終是致命傷，不說其他人接手，就算作者自己，可能過一段時間也回憶不起來當時的解決思路。
之前折騰過一段時間的靜態部落格工具Hexo，利用Github和Coding的Pages服務去生成個人部落格網站。後來又玩過Hugo，也是一個類似的工具。現在回頭想想，只是為了滿足自己動手摺騰的好奇心。像我這樣在社交媒體上的隱形人，自建站約等於零流量。不如迴歸一些較為主流的平臺，省去維護的精力，用這個時間多寫幾篇帖子。