之前也沒有深入意識到它的重要性。直到後來,去接手一些遺留系統,那種混亂,尋找代碼和代碼文件多麼費力。系統通過了不少人手,人員調崗,人員離職。每一個人都有本身的風格,折騰一下,就閃了。丟下一個千瘡百孔的系統。php
人的眼睛是相信現實的東西,沒有經歷過那種坑,就沒法理解。因此當咱們怎麼說要規劃好目錄結構,要好的命名方式,一些技術都不覺得然。包括我之前也同樣,我之前可以接受好的東西,可是我沒理解,就不會有深入發自自覺性去這樣作。心裏只是想:這個問題不大吧。css
由於現實案例最讓人印象深入。總結一下遇到的問題nginx
上面兩個是比較坑人的目錄結構,接手的人員太多了,加的目錄也重複。程序員
-------------------------------------------------------api
後面這個系統使用mvc框架,相對好,可是也出現不清晰的地方,暫時系統的功能不是不少,因此目錄不多,看起來很清晰。可是,隨着時間的推移,加的功能愈來愈多,纔會看起來混亂。緩存
好比:上面這個curl目錄就不太好。不該該放到根目錄下的。這樣會給人誤導,使得接手的技術,某天增長新功能,也會新增長一個文件夾放到根目錄。那麼,後面功能加的多了,你們都會這樣子作。架構
那個時候纔去思考解決辦法。我一直在想,怎樣才能讓項目在可控的範圍內呢?
出現問題的緣由是什麼
雖然好的風格在業界都是有共識的。但爲何形成那麼混亂的系統。緣由是什麼呢?
有人說緣由是:各個技術人員水平不同。因此這個問題很難解決。一籌莫展。
也有人說,緣由是,系統經受的人太多了。這個技術維護一段時間,而後另外一個技術維護一段時間。這樣就形成了千瘡百孔。除非公司保證技術人員的穩定性,但這個很難。因此這個問題也很難解決。
仔細,深刻去思考。我在想,這些都只是代表上的緣由。難道由於這樣就沒有解決辦法嗎?
如何解決,不少人也有本身的想法,概括起來有:
一、要求系統維護人員遵循風格統一。寫好規範文檔。讓你們按照規範來作。提交修改代碼,須要進行代碼審覈,但是這須要成本。一箇中小型公司,技術人員有限,都是忙着開發功能去了,抽出時間來審覈代碼(哪怕是大致審覈),也是須要時間投入的。
因此現實狀況是,進行代碼審覈,在不少公司每每作不到。
二、成員培訓。歸根結底仍是要放到人的自覺性上去。因此要常常給你們灌輸好的風格意識,進行培訓。這個方案其實有效果。具體得依賴於團隊技術領導本人的我的影響力,能不能以身做則,用代碼示範影響到成員。因此仍是依賴於某一個經驗豐富且有影響力的人,一旦缺了這我的,就會致使人心渙散。尤爲是當這我的若是離職怎麼辦呢?
上面辦法都是正確的。可是會有阻礙和困難。我在想,能不能作到不依賴於某個特別的人而讓團隊成員自覺作到呢? 而且,可不能夠,忽略掉團隊成員技術水平的差別性呢?
根據心理學,就是示範效果。雖然你們水平不同,可是看到一個好的示範,會不自覺的遵照。另外就算其不遵照,也會感到沒法使用。本身都會感到羞恥。
好比mvc的框架,定好了controllers,views,models,後面剛入門的人,都能按照目錄結構去加代碼。
具體要作的是:對系統的代碼和目錄預先設計好。規劃好目錄結構。什麼目錄放哪一種類型的文件的。
之前聽過一句話說:架構師的目標就是讓程序員變得更加不用很費不少精力,按照預先規劃設計好的方式去作就能夠。
如今看來這個很是有道理。
心理學:若是已經有的東西是混亂的,那麼也會以爲痛苦,乾脆湊合一下算了
作系統前,把系統的規劃好mvc
不規劃好,後面接手的人就會不知道標準。app
安裝目錄包括一下幾個文件夾:框架
安裝目錄/public/
安裝目錄/app/
安裝目錄/cache/
說明:
一、public目錄下是對外開放的目錄。也就就是nginx配置指向的目錄。目錄裏面的子目錄接下來在詳細介紹
二、app,全部源碼存位置。
三、cache,模版編譯緩存存放到這個裏面。爲何要放到這個裏面呢?
public目錄下的子目錄
public/index.php
public/js/
public/images/
public/css/
app目錄下的子目錄
app/controllers 控制器文件
app/models 模型文件存放目錄
app/views 模版文件目錄
app/config/ 全部的配置文件存放
app/library/ 全部的公共庫文件。文件夾名稱也能夠命名爲lib,就是library單詞的簡寫。
app/logs/ 日誌文件目錄。php代碼記錄的日誌信息
app/api/ 裏面放一個sdks文件夾。全部的sdk放入裏面去。每一個sdk一個文件夾。好比sdks/pmsSdk/ sdks/memberSdk/
app/tools/一些工具放入到裏面去。好比定時腳本,則放入task文件夾中去。app/tools/tasks