可供創業團隊技術開發參考的10條經驗


對於創業團隊開發人員來說,不要高度追求技術的高大上,有效解決問題很重要。

這篇文章和大家說說有關創業公司的純技術方面的想法。對於一個互聯網創業公司來說,有這幾個特點:

  1. 什么都要求快。這個快也許並非來自用戶,而來自於自己,比如恨不得開發一天就開發一個新功能。

  2. 變化快。比如一個想法落實到開發,可能會有很多變化。

  3. 資源稀缺性。資源就是時間、金錢和人力成本,對於創業公司來說,有效的花費資源本身就很重要,看看多少創業公司都是胡亂花錢而撐不下去的,而對應的技術上就是能省則省。

針對這三個主要特點,創業公司在技術使用的策略上有什么准則呢?個人認為就是“簡單化“,當然這個簡單是建立在理性分析的基礎上的。技術人員有個通病,認為技術實現越復雜,越膨大,越全面就越能體現技術水平,這是非常錯誤的一個觀點。衡量技術水平的唯一標准其實就是“是否有效支撐業務發展”,要看結果論,比如說開發速度快,后期問題少,假如能做到這些,那么這個技術團隊就是牛的。

而提倡簡單化的理論,就會讓你從另外個角度去審視技術本身,下面的一些技術使用建議也許看上去並不高大上,好像每個人都能明白,但假如能有效的實行,在創業初期能夠解決大部分的技術問題。

1.使用雲服務器

對於創業團隊來說,並不知道你未來用戶有多少,需要使用多少服務器資源(Web 服務器,DB 服務器 等等)並不好衡量,而雲服務器的可擴容性則能很好的滿足這個需求,換句話說創業初期使用雲服務器能有效節省成本。

當然雲服務器的特點還不至這么多,它代表了一種開發模式,這就是分層架構,比如雲服務器的類型有很多(雲服務器、雲緩存服務器、雲數據庫服務器、雲存儲服務器),正因為有了這樣的分層模式,讓你有了更好的選擇。假如自建服務器,很多技術團隊可能會把 Web 服務器和 DB 服務器放一塊,從而帶來很多問題。

另外雲服務器也有沙箱功能,在安全性上也有很好的保證。雖然可能很多人覺得現在雲廠商做的不好或不安全,不過說句實話,你自己搞可能更差。

當然使用雲服務器也並不能說明一定就省錢,這取決於你是是否真正了解系統以及其背后需要的資源。

2.重視你的數據存儲

先入為主,推薦 Mysql 存儲數據。

在設計上要盡量規范化,索引利用合理一點,因為數據有個特點,假如前期設計不好,后期想重新調整結構是非常痛苦的一件事情,原來公司某個產品,最重要的博文數據庫表(blog 表)有個字段存儲的是文章的具體內容(content 字段),從而導致這個表非常龐大,查詢性能和內容非常不好控制,就我了解到的情況是目前 content 字段還是沒有從 blog 表中拆分,這不僅僅是技術的問題,對於一個在線的服務,數據量很大的服務,做表結構的調整是非常困難的,所以前期盡量設計好。

Mysql 主要的作用還是存儲,雖然可以通過 Sql 完成很多復雜的查詢,但是建議盡量少使用,否則性能會急劇下降。我幾年前了解到一個爆款的產品,用戶量上來后,第一個壓垮她的就是數據庫,最大的原因就在於查詢非常不合理,做了非常多的聯合查詢。

假如不合理使用 Mysql,很多人會質疑性能不行,其實這都是錯覺,我一直相信的一個原則就是,既然這么多人用,說明必然有他的優勢,我們要做的就是學會使用而不是抱怨。

對於 Mysql 這樣的數據庫,很重要的觀點就是備份和安全性,剛工作的時候領導說過這樣一句話,“代碼可以重構,但是數據不能丟,所以在寫操作數據程序的時候一定要慎重”,而 Mysql 是非常成熟的軟件,備份和安全性上有很多選擇。

另外一個觀點就是假如你並不知道數據量和訪問量是多少,開始不要選擇分庫發表策略,也不要搞很多路由策略,盡量簡單點。單表數據量在一百萬級別,只要設計和使用上保持穩健性,性能不是問題。

Mysql 的主輔同步本來是做備份用的,但是現在很多人多當分布式查詢使用,其實也能分擔很多查詢壓力。

現在很多 Nosql 服務特別多,比如 Redis ,對於創業公司來說建議不要使用:

  • 第一就是這些服務並不完全成熟,在使用上很需要有很多經驗,尤其在備份和安全性上,在運維上並不簡單,需要有極大的成本。

  • 第二雖然它有很多有點是數據庫比不了的,但是還是那句話,它能做的 Mysql 也能做,對於創業團隊來說,上手簡單和維護簡單,成本是優先要考慮的。當然假如應用場景非常適合用 Nosql 這樣的服務,還是要大膽的使用。

3.一定要有一個開發框架

開發框架在我看來有兩個最主要的作用,分別是規則和最佳實踐。

所謂規則就是框架定義了一些制度,框架理論上不應該讓你隨意寫代碼,尤其在 PHP 語言中,由於太靈活了,假如沒有一套框架去制約開發者,那么寫出來的系統會很脆弱。

最佳實踐就是框架集成了很多優秀的思想和功能,要做的就是去合適的用,框架能夠解決分層的問題,能夠解決安全性的問題。

所以在創業團隊一定要有一套開發框架,但是在選擇上必須謹慎,不要選擇太難以理解的框架,比如說 PHP 框架 Laravel ,對於使用者來說需要具備很強的設計模式和 OOP 理解能力,沒有經驗就選擇簡單易學的框架;第二個選擇框架不要選擇封裝太多的框架,舉 Jquery 的例子,很多人可能會 Jquery 但不會 Java,所以選框架應該選用接近開發語言本質的框架。

另外框架沒有絕對的好壞,一個創業團隊能夠快速上手的框架就是好框架,使用框架 20% 的功能即可,開發人員喜歡過度的使用軟件,說到開發框架,不要強迫開發人員使用統一的 IDE,只要最終代碼輸出標准一樣即可(比如 PHP 語言重要符合 PSR-2 即可)。

4.假如使用 Cache,必須有一個優良的 Cache 管理器

在互聯網產品中,可以說 Cache 為王。很多人不管三七二十一必須要使用 Cache,可個人覺得系統假如沒有瓶頸(這個詞需要好好理解),不一定需要使用 Cache,首先有容量資源成本,另外也會增加系統的復雜度,從而導致開發和維護成本提高。

假如實在需要使用 Cache,一定要充分理解應用場景,是 pull 式的 Cache,還是 push 式的 Cache ,如何衡量 Cache 的效果。

假如必須要使用 Cache ,一定要有一個 Cache 管理器,什么意思呢?對於技術人員來說,代碼在寫的時候,意識不到 Cache 的存在,全部優雅的封裝了。而封裝能帶來開發和維護成本的減低。

最重要的一點就是不要過度追求命中率這一指標,從而把代碼搞的非常復雜。比如使用 Memcached,可以基於 Sql 查詢語句做 Cache ,多采用 pull 的方式,過期時間可以設置短一點(意思就是不要主動的去更新 Cache)。另外一種使用方式就是將數據庫的聯合查詢的結果主動放入到 Cache 中。

5.盡量異步化

異步化是一種開發策略。對於創業團隊的產品來說,資源有限的情況下,沒有必要每個功能追求及時響應,比如說現在很多 SNS 產品,沒有必要評論數、點贊數及時更新,排行榜也不用及時更新,假如什么功能和需求需要做到極致,對於開發和時間是極大的挑戰。

所以對於創業團隊來說,請有效使用異步化,舉簡單的幾個例子:

  1. 比如說用戶點贊。沒有必要程序即時響應這個用戶有沒有點贊,直接將這個請求放入隊列,這樣這個接口的響應和吞吐能力就提升了。

  2. 每天博文訪問的排行榜。沒必要查詢數據庫,每天或者每個間隔時間從數據庫中查詢出結果放入緩存即可,減少了多少數據庫的查詢。

6.日志系統

在互聯網應用中,日志無處不在,操作系統運行的日志,服務器的日志,軟件的運行日志,數據庫操作的日志,應用程序日志,產品業務日志。這些日志是了解服務運行狀況的最好的來源,在創業團隊,最忌諱系統出了問題不知道如何分析問題,產品人員需要一些數據卻拿不出,系統的歷史運行狀況也完全一抹黑。

所以對於創業團隊來說,一定要重視日志,對於開發人員來說,在開發框架中一般都有日志模塊,良好的定義好日志格式和含義。假如服務器眾多,可以使用一些分布式日志系統來搜集和壓縮日志,其實 Linux 發行版自帶的 Syslog 其實非常好的一款軟件。這樣從側面說明我們不用尋找多少高大上的軟件,用好操作系統自帶的工具就很不錯了。

7.監控

有了日志,下個話題就是監控。監控都是基於日志的分析,確定合適的閥值,選擇是否報警,所以對於技術團隊來說,有了日志就要充分的分析。而一套完善的監控系統很重要,能夠對系統的運行狀況有更好的了解,主動的去發現問題,而不是等待用戶去投訴。

監控的維度可以有很多,比如系統運行的慢日志、資源調用的錯誤率、數據庫更新頻率突然飆升,某個接口訪問數異常,寫代碼其實很容易,難的是如何知道系統出現異常背后的原因。

監控軟件其實有很多,在使用的時候一定要精確定義閾值和閾值背后的含義,比如說我們公司也有監控系統,可問題出了后還是沒有通過監控系統發現,最后發現報警短信太多了,忽略了,運維呵開發人員對於報警短信也麻木了,所以說使用監控系統很簡單,正確使用則有難度。

8.Wiki 系統

Wiki 個人理解其實就是提倡寫文檔。文檔的作用其實很多,如何寫不重要,重要的是這個文檔的作用是干嘛的、能讓人看明白嗎。

假如一個新員工來了,看了文檔后,就知道系統包括了什么模塊、自己如何快速開發、如何上線,這就是一個好文檔;

假如要優化一個原有的服務,開發人員不是通過代碼去找邏輯,而是通過文檔去了解大概的邏輯和包含的模塊,當然文檔也不需要太詳細。

文檔是開發人員和運維人員之間的協作工具,比如服務器的 IP 是多少,系統中資源的路徑和 IP 是多少(比如數據庫的域名、外部 API 的地址),說個簡單的笑話,原來公司運維人員維護了一百多個 Memcached 端口,最后發現找不到使用方是誰了,最后不得不發郵件讓大家認領,可大部分最后也沒人認領,有了文檔這些問題就能解決了。

文檔是開發人員之間的協作工具。在創業團隊,變化太快了,大部分都是通過人與人之間的溝通,可溝通假如總是變化,最后發現雙方理解的有偏差,浪費了很多開發時間,而約定的文檔能在一定程度上解決這問題。

上面舉得例子就簡單解釋了文檔的重要性,其實文檔代表了一種開發思維,可以這么說沒有文檔,代表開發混亂,有了文檔從側面也能大概看出代碼實現的是否合理,這才是文檔最重要的用戶。

寫文檔避免的幾個誤區,

  • 第一就是不要太遵循寫作規則,能夠說清楚就行。有些開發人員不想寫文檔的原因之一就是寫文檔比寫代碼還要求嚴格;

  • 第二就是文檔一定要保持更新。比如說一個功能上線初期是有文檔的,后來代碼一直在迭代,最后開發人員發現文檔和代碼的邏輯完全不一樣,大家也就失去了看文檔的動力,所以文檔最重要的就是要持續更新;

  • 第三文檔不要強制開發人員去寫,也不用及時讓大家去更新,讓大家的約束少一點可能效果更好。

9.代碼構建,部署,發布系統

對於創業團隊來說,假如一個新員工來了,需要快速能夠讓其進行開發,所以需要有一套集成化的環境,主要包括:代碼協作工具,代碼構建,代碼部署(開發環境、仿真環境、線上環境)。

為什么需要這套環境呢?目的就是為了縮短產品上線時間,讓技術人員專注於業務開發,而不是被其他的一些因素困擾;第二個目的就是為了產品的質量。下面分別說下:

在很多開發團隊,有的時候出現問題,都是開發人員直接線上修改代碼,從而導致潛在的問題;還有任何開發人員都有線上的服務器的權限,導致安全性得不到保障;在產品上線后,測試人員說怎么測試的時候沒有問題,一上線就有問題,開發人員說測試人員測試的環境不是線上環境;新來一個員工,一個星期都沒法搭建自己的開發環境;反正很多此類問題,從而也導致了時間的浪費和質量的下降,而更大的危害就是失去別人的信任。

所以有這樣一套環境很重要,不用特別的高大上,下面就簡單說一說:

  1. 首先要有一個代碼版本控制系統,這個現在大部分都會使用,也不用特別介意用 SVN 還是 Git。

  2. 讓運維人員寫一個腳本,能夠配置開發環境、仿真環境、線上環境(環境一定要隔離),說真的,簡單的 Shell 腳本就能完成。這里的環境不僅僅是服務器,包括數據庫資源等等,這時候大家也意識到 Wiki 的重要性了,假如沒有文檔,不可能能搭建這樣的系統。

  3. 代碼構建系統,其實在 PHP 這樣的高級語言中,本質上不存在代碼構建這一說,假如有特殊需要,也是可以通過 Shell 腳本來實現。

  4. 代碼部署系統,在開發環境中,完全可以借助 IDE 和 FTP 將實時變動的代碼同步到開發環境中;假如代碼需要部署到線上,可以借助於 SVN 和 Rsync 這樣的工具將有差異的代碼快速發布到線上,有問題也支持快速的回滾。

10.假如可能的化由開發人員做運維

運維這個崗位其實需要了解網絡,Linux ,Shell等相關知識,而開發人員本身也應該掌握這些知識,假如開發人員不了解這些,而只是會編碼,那代表他並不真正會編碼,了解這些知識開發人員可以更好的理解一個系統,當系統出現問題的時候能夠從多方面去排查,更好的維護。

在我工作的這么多年中,開發崗位和運維崗位總是不能很好的協作,出現問題的時候開發人員說這是網絡問題,是運維的服務器不夠,或者說數據庫響應慢;而運維人員則更痛苦,你開發人員寫的什么程序啊,數據庫全是聯合查詢,導致數據庫性能嚴重下降。出現這些問題的原因在於雙方對於對方掌握的技術領域不了解,互相不理解或者不明白對方的職責,而這些會導致整個產品和系統的穩定性出現很大的問題。

所以對於創業團隊來說,假如技術能力足夠,運維工作盡量由開發人員來做,當然這里的運維可能更多的是產品運維的角色(在大企業,運維崗位的分工也越來越明確),具體的工作比如說安裝軟件開發包,進行 Nginx、PHP 配置,切割日志,這些工作本身也不復雜,開發人員假如能夠掌握好,對於系統的維護是由極大的好處的,另外潛意識告訴開發人員,出現問題沒有人能依賴,代碼和環境需要你自己去攻克。

以上就是我的觀點,大家可能發現了一個規律:這些都不涉及到人的因素(比如開發人員素質,協作能力),大家只要遵守就能很好的完成。而完成這些,就能解決軟件開發中的大部分問題,讓你系統更穩健,讓你的開發更快速,讓你的成本更低。對於創業團隊開發人員來說,不要高度追求技術的高大上,有效解決問題很重要。


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2021 ITdaan.com