大齡程序員技術管理路上的悲喜總結

生在中國這片熱土，咱們作程序開發的人要面臨不少的挑戰。只要生命不息，挑戰就永遠不會中止。

好比最近瘋傳的 35 歲程序員送外賣。這明顯點出了在中國搞開發，要面臨的其中之一挑戰：年齡。

在整個 IT 領域，大多數的開發者都屬於普通人。只有極少數部分人能站在技術的尖端引領技術的前進與走向。那麼，普通的開發者，又很容易被新人替換。新人更經濟實惠，壓力小。而老開發人員技術的天花板沒法打破的狀況下。要面臨跟着一羣小朋友一塊兒起早貪黑的工做模式。甚至於會出現本身一把年紀，上面的領導比本身還小好多歲的窘境。

確定有人會說咱們這羣老人矯情。可是，又有幾人能作到心裏毫無波瀾呢？

本篇博文主要是針對咱們這羣普通的開發者處境所寫。請容許我在這裏販賣焦慮。

1、系統架構

做爲技術這條路線，最終都會偏架構方向。即便作技術經理或總監。都必須對系統架構要有必定的知識儲備，以備對團隊的架構搭建與變動作出準確的判斷。

這裏並非說咱們去設計一些千萬級別以上 PV 的系統架構。作爲普通的開發者，要接觸上億的系統平臺相對來講機會並非不少。即便接觸了，也僅僅只是這個平臺裏面的一個小螺絲。要能主導這個架構的設計，還稍顯稚嫩。我再次說明一下，這裏僅僅只對普通的開發者。不指那些尖端的高技術人才。

在個人理念當中，千萬級別及如下 PV 的構架，一般用不到微服務。因此，不要用微服務來坑本身。加劇架構的複雜度。

在這個體系裏面有如下技術/服務/文檔多是咱們要涉及的：

隊列服務：Redis、Kafka、RabbitMQ 等消息服務中間件。
緩存服務：Redis、Memcache。這裏不太推薦 Memcache。
多進程/多線程：用來異步處理一些 CPU 數據密集計算的任務或異步處理推送、短信等任務。
負載均衡服務：能夠採用阿里雲成熟的負載均衡服務 SLB 服務。
日誌存儲與分析服務：常聽到 ELK 就屬於一組組合。不過，我推薦使用阿里雲的日誌服務。集成了報警功能。這個很是實用。
文件存儲服務：系統上傳的文件不能與業務服務器存放一塊兒。會影響業務服務器的帶寬。致使業務訪問的數據交互延遲與超時。能夠採用阿里雲的 OSS。通常千萬級別自建這樣的存儲系統服務，從成本上來講根本不划算。
CDN 服務：即便咱們用了獨立的文件夾服務器存儲文件。可是，在訪問的時候因爲用戶所處網絡不一樣（電信、移動、聯通），以及區域不一樣（南方/北方）。因此，CDN 會加快用戶訪問文件的速度。提高用戶體驗。
數據庫：一主多從構架。具體要多少個從數據庫根據本身的業務量來設計。一般中小型平臺使用阿里雲的 RDS 比自建數據庫服務更加划算。不然，團隊會配備專業的 DBA 來維護數據庫服務器。推薦使用阿里雲的 RDS 服務。對了。這裏說的是MySQL 數據庫。其餘忽略。
監控系統：現現在像阿里雲這樣的平臺，都提供了監控服務。像服務器 CPU、內存使用率告警。數據庫資源報警。自建的話，不只維護須要專人，還可能會致使監控不完善形成的損失。千萬 PV 級別不推薦。
專用網絡 VPC：這個說的是阿里雲的 VPC 服務。固然，其餘雲平臺也有。它的核心功能是給本身全部的服務器虛擬一個網絡進行管理。避免直接被外網訪問，或直接訪問外網。說得再直接一點就是避免風險。
像我這樣普通的大齡開發者，經歷過的大大小小項目也挺多的。要真的能達到千萬級別 PV 的挺少的。一般要面臨的挑戰以下：

QPS：即每秒請求量。一般咱們服務器能支持 2000 + 便可。除非作搶購等這種秒殺型的活動，不然不少的 Web 業務根本用不到 2000+。
海量數據：不少時候制約性能的數據庫。對海量數據存儲就顯示很重要。好比，訂單分庫分表解決。分表解決單表查詢性能、分爲解決單庫性能。
2、網站劫持

網站劫持這是一個比較籠統的叫法。實際有以下幾種劫持：

URL 跳轉型劫持：輸入 A 域名，強制跳轉至 B 域名。
注入型劫持。
DNS 劫持。
而注入型劫持，又分如下幾種：

注入 JS 類劫持：在正常頁面注入 JS 代碼實現劫持。常見的就是運營商強制注入廣告 JS。
iframe 類劫持：將正常頁面嵌入iframe或者頁面增長iframe頁面。
篡改頁面類劫持：正常頁面出現多餘的劫持網頁標籤，致使頁面總體大小發生變化。
DNS 劫持：
在工做中，常常會有用戶跟咱們的客服同事反饋 App 打不開或報錯。這其中有一部分就是 DNS 被劫持所致。劫持以後 App 請求接口拿不到數據或拿不到指定的數據，確定會報錯。影響用戶正常的訪問。

URL 跳轉型劫持與注入型劫持均可以經過 HTTPS 方式解決。而 DNS 劫持就比較特殊了。

關於 DNS 劫持解決的辦法是經過直接訪問受信任的 DNS 來解決。由於，這種 DNS 的劫持一般是運營商 Local DNS 緩存問題形成的。好比，***者污染了根 DNS 服務器。致使運營商同步形成了數據的污染。天然訪問就會出現問題。

所幸，咱們能夠採用相似阿里雲這種平臺提供的 HTTPDNS 服務。來解決 DNS 劫持的問題。
HTTPDNS 的功能特性：

防劫持:繞過運營商Local DNS，避免域名劫持，讓每一次訪問都暢通無阻。
精準調度:基於訪問的來源IP，得到最精準的解析結果，讓客戶端就近接入業務節點。
0ms解析延遲:經過熱點域名預解析、緩存DNS解析結果、解析結果懶更新策略等方式實現0解析延遲。
快速生效:避免Local DNS不遵循權威TTL，解析結果長時間沒法更新的問題。
下降解析失敗率:有效下降無線場景下解析失敗的比率。
穩定可靠:99.9%的可用性，確保域名解析服務穩定可靠。
3、系統安全

系統安全真的真的特別重要。做爲一名開發老兵，心中始終要有一根弦：代碼千萬行，安全第一條。

常見安全防範：

網絡安全：經過專用網絡 VPC 把全部的業務服務器進行網絡隔離，再採購堡壘機進行服務器管理。
密碼強度：管理員帳號必定要採用 大小寫混合且包含數字的 20 位及以上的長度。業務系統用戶密碼不能爲純數字且長度必須大於8位。同時也要避免連續相同的密碼。好比：AAAAAAAA。
密碼按期更換：無論密碼保存得再完美，總會遺漏致使信息泄漏。而按期更換能及時發現並堵住這些漏洞。推薦每 3 個月更換一次。
SQL 防注入：如今基本上成熟的語言都有一套完整的防注入機制。好比 PHP 語言的 PDO 擴展提供的預處理機制（固然數據庫必須支持預處理）。
XSS（跨站腳本***）：XSS 能截獲用戶的私密網頁內容、Cookie 數據。一般是 JavaScript 腳本形成。最好的辦法是轉文存儲。
CSRF（跨站請求僞造）：危害極大。全部敏感數據的讀寫操做採用 POST 限制。而且不容許跨域請求。在信息提交時，再作一次令牌的認證限制。
文件上傳漏洞：主要是避免用戶上傳惡意的腳本代碼得到看咱們的權限。解決辦法是就嚴格限制上傳文件的後綴。同時把上傳的文件放到專業的文件服務器。好比，放到阿里雲提供的 OSS 服務器上。
4、代碼規範

即便你是外包或建站類型的項目開發，代碼規範能幫助你減小項目交叉維護帶來的痛苦。
無論是後端 PHP、Java、Go，仍是 Web 前端，仍是 Android/iOS 客戶端。必須有一套代碼規範。

PHP 目前通用的代碼規範：PSR。
Java 代碼規範：目前大多數都會遵循阿里開源出來的一套開發規範。搜索關鍵詞：阿里官方Java代碼規範標準。
Go：自己本身都代了一套代碼規範。直接遵循語言的規範便可。
Web 前端代碼規範：目前網上不少關於這個規範的整理。參照一套便可。
Android 代碼規範：http://www.javashuo.com/article/p-zpnyeavq-kg.html
iOS 代碼規範：http://www.cocoachina.com/articles/19599
其實代碼規範這個東西是一種約定俗成的規定。並非一層不變的教條。也要因地制宜的形式進行使用。不能生搬硬套。小團隊只要大致上沒有問題便可。大團隊可能就須要專門 Review 代碼的機制，以及代碼提交的輔助性插件來進行代碼規範的驗證。

5、工做彙報

若是你是老闆可能就不須要進行工做向上彙報。不然，無論是哪一個階層，工做彙報必須是工做中重要的一環。而每一個層次的員工彙報工做的方式又有不一樣的側重點。

這裏指的是工做彙報，而不是項目進度彙報。

（1）非核心開發員工

此類員工工做彙報應該有以下幾點：

具體作了哪些工做。完成百分比。如：登陸註冊功能開發。已用時 3 天。進度 80%。
遇到哪些問題。工做中遇到了哪些技術難題，本身是否能搞定，若是沒搞定是否請求過核心開發或組長級別協助。
後續工做計劃。這個是讓組長以及部門管理者知道接下來應該給你安排什麼任務。
（2）核心開發員工

此類員工做爲核心輸出。與非核心開發員工仍是有區別的：

具體完成了哪些工做。
工做遇到的問題。
協助非核心開發作了哪些工做。
後續工做計劃。
核心員工重點工做是編寫核心業務代碼。而且指導並協助非核心開發員工遇到的各類難題。必要的時候，還須要對這此處於最底層梯隊的員工進行技術培訓。讓他們快速成長，慢慢成長爲核心員工。
其次，核心員工不但能發現問題，還能解決問題。當須要部門管理者做決策時，是帶着A/B決策方案去。

（3）主管級別員工

這一類員工實則是與核心開發員工差很少。在覈心開發員工上面進行一層工做的協調分配的工做。

6、職責清晰

這一點是針對開發轉技術管理路線的人而言。要讓每一個開發準確知道本身所負責的事情。說穿了就是職責與責任。
若是職責不清晰，對一些事不關已高高掛起心態的人來講，會致使事情變得難以推動。只有明確職責以後，在事情沒有辦好的時候，就知道是誰的責任。

7、績效考覈

這個與第六點相呼應。惟一的難點是要能及時且準確對責任作出評估，該扣績效扣績效。這獎勵的就獎勵。毫不能拖泥帶水、瞻前顧後。特別是拒絕過度護短的狀況發生。

8、上下關係

不少剛從開發轉管理的人會有一個毛病。以爲要以技術實力去讓人服從。這明顯是不合適的。技術能力當然很重要，但不能本末倒置。天下技術千千萬。要以這種思惟去作技術管理。那我相信，這世界上沒有幾人能坐得穩。

因此，技術這東西得多去關注理論的東西即要。這樣才關鍵時刻能作出正確的選擇。

有些人還以爲要跟下面的人打成一片才能讓別人服從本身的工做安排。我並不這樣認爲。工做中率先不服從或意見最多的反而是那些日常你極力去討好的人。咱們在作管理的時候，只須要秉承公平公正公開的原則，去對待每個人和工做便可。

那些不肯意服從的人，無論是交好的或關係遠的，都應該及時進行制止和批評。若是依然如此，那是他我的問題，不是咱們管理的問題。除非咱們的工做安排確實出現了嚴重的不公平不合理的狀況。

以上都是本身瞎逼逼的一些總結。

管理這份活兒，它並不容易幹。但好在能在此間修休汲取一些實戰經驗來檢驗本身的不足。也是有幸之事兒了。