[散分] 講點俺們做背景那些事!
本帖最後由 mu_rain 於 2012-11-01 11:18:30 編輯
寫點俺用的背景那些口水雜記,以下是個人見解,歡迎各大俠指點.
/////////////////////////扯點互動////////////////////
//1 登陸介面一定要靚,第一眼決定了很多.[道理就不解釋了]
//2 選一個合適的前端互動包,我用的是easyui,主要是看中了他的layout,視覺效果不要太深沉,像csdn 這樣清爽的配色即可,互動不要太眩,對一個長期工作者而言,太多的過度效果,會讓人想吐. 僅在重要處理時,來點效果即可.
//3 關於後檯布局,我沒有太多的想法,基本上照著ide的那個布局的感覺去做做.
//4 內部信箱是個快速溝通的方式,也是通知發布,工作提醒的好手段,有興趣,還可以折騰點sns [例如,你手下的xxx 於xxx登陸後台,他今天做了***],這裡遇到了一個,大家不收信,不願意去使用的問題.木有辦法,直接強制回應對話方塊彈出,點擊確認後,不再騷擾,並閑著沒事時,與行政,老闆,推廣這東西.再說了,資料都在自己這,搜尋時也方便,要查個什麼,都挺快的.
//5 菜單的互動,點擊後,工作區tab 效果,這個同事都很樂意接受.[和ide 一樣的不囉嗦了]
//6 添加上傳處理[需要firefox 瀏覽器支援],發布時為html５ 顯示時html 版本. 詳細看帖 http://topic.csdn.net/u/20121018/10/16e8f8d2-2955-4680-9e69-167681f0363c.html
//7 表格式資料,每行交替顏色,滑過時淺色,選中時深色. 事雖小,給業務人員帶來的效果是很明顯的.
//8 操作全ajax 處理,批操作完後,hold 住查詢條件. [例如對今天的資料做審核,查詢條件,為今天,未審核,按時間排序]這樣,每操作一次,再reload 一下資料,不用二次去選取查詢條件.
//9 最後一點,也是最重要的,用心去服務. 技術在基礎實現沒什麼大問題後,服務是一個展示出不同能力層次的好地方,服務好了,人人看你爽,只要碰到一個明智的,正常的老闆,幸福會來的.還有就是不要急,有時,業務也會扯不合理的東西,慢慢疏導,用心溝通,時間長了,都會明白的.
/////////////////////////談點功能////////////////////
//1 許可權管理部分,我採用的簡化文化,把角色和菜單關聯一下.通過可見度,完成基本的角色許可權控制. 然後在控制器的鉤子上加一個過濾表,防止非法闖入. 對這塊,多說兩句,把握一個原則,less is more. 難的不是技術,是對人,所以建議一開始,就行成一個良好的約定,不要過多的去滿足太個人化的整合需求. 一旦有一個不好的開始, 人類的慾望的變化,直接讓你崩潰,對需求方而言,你小子寫再快,難到有他想得快. 當然,比較嚴格,已有成熟業務的體系另當別論. 大家都用過一些 bug 管理, oa 類的產品,如果想做細緻點,就照做比較合適. 我在07 年,還做過一個類似許可權樹的東西,一個子結點角色,發布一個檔案,他向上三級,直系鏈的結點可以看,向上找三層,其下子結點遍曆,再與發布人,有項目往來曆史的人可以看之類似的需求,現在想得就蛋疼,最後的建議,別給那些無聊的人太多的空間. 他們做項目的目的,就不是為了出產品,而是為了自已那所謂的價值的存在,想深了,這事麻煩,所以 less is more!
//2 登陸是 不要去寫 where `name` = '$name' && pwd = '$pwd' 這樣的查詢, 先查使用者,再比對密碼. 對每次的提交做必要的xss 處理. 用360檢測一下網站安全,把一些基礎的全安漏洞處理一下.當然,還有很多東西,需要伺服器工程師去協作,儘早明確這個概念,別一個人折騰得啥都做,全能戰士是很悲催的.
//3 用lang 對語言文字進行處理.這樣改文字時,就在一塊,比較方便.[代碼大全裡,一直有講這個中心控制的原則]
//4 添加使用者操作行為追蹤,通過鉤子對每個控制器進行追查,並寫入useraction進行日誌.以資料為中心,對每個資料進行追蹤處理,對重要的資料,進行資料鏈的追蹤.
//5 後台是基於配置的,並基於約定大於配置的原則,對固化的東西,多採用約定的方案,對需求變化的東西,採用配置,便如資料列表顯示哪些烈,對哪幾個欄位進行使用者追蹤,對哪些使用者行為進行追蹤.
//6 產生餅圖柱圖之類的,就直接用google 的api ,省事省心,找了N個php 的製作圖,難用的居多.當然google Api 不能滿足時,就硬著頭皮用phpchart 相關類了. 確幸的事,這種事情還沒發生.
//7 多寫些支援excel的東西, 例如:大量匯入資料,大量匯出.
//8 swfupload ,editor 等 這些東西封裝好,用的時候直接加上去就ok.寫的時候 用css 樣式去控制調整這些東西是否在兩者之間轉換.對通過 json 資料,資料庫表產生的 select radio 用form_helper 封裝一下. 我關注了一下,每個架構都有form 產生的地方. 但對僅一個input 的,閑著沒事,也不用form_helper 去create 了.除非你整個表單都希望由配置產生. 但基於項目經驗來看,這裡,是TMD 業務要求變化最多最快的地方. 用手去寫,確實是最實際的手段.感觀直接,維護方便.當你要封裝的東西,大量的是不可預期的時候,就要想想封裝的必要性了,要想想是否過度設計了.
//9 對每個資料,插入前後有beforeInsert afterInsert 主流架構都支援, 其實還有挺多,寫到這裡就要收手了
/////////////////////////忽悠點代碼////////////////////
//1 組合自己的類時,可能涉及到autoload , 不要直接把架構的autoload 給改了[年青時喜歡這樣折騰],把自己的代碼,放在合適的地方去組合進去,方便裝卸.研究可以,沒事不要亂改人家架構的代碼,雖然基於代碼癖好,總覺得架構會在有些地方很爛,但記住,自己不要多手,別進行不亦樂呼.其一,你寫的東西,沒有團隊與大量qa,tester 的支撐,容易出問題,其二:萬一架構升級了,你難道再去折騰一遍???
//2 別寫代碼時就過度設計,更不要濫用設計模計,注重代碼的體驗,在寫一個架構時,要多角度去體會,以後代碼會如何去寫,多品味這樣寫的好壞,多與團隊人員溝通. 對大型架構,學之者生,用之者死,精華拚命的吸收,用的時候,不要盲從.
//3 在熟悉和理解自己公司所處的業務時,要根據特性controller,model的基類重構一道,你熟悉了業務,自然有感覺怎麼去寫了.
//4 一定要有一套命名的標準. 舉個例子 userModel(model) user(controller) cfg_user(配置) v_user_index(視圖),盡量見名知義. phpstorm 有個很好的 ctrl+shift+n 能根據檔案名稱快速的找到檔案,這樣非常有助於提升效率.
//5 常用的熱鍵,快截鍵都封裝好. 例如寫個 foreach 直接 fe+斷行符號,就全部出來了, lm+斷行符號就是load model 的全部代碼. 上次有位牛人,有個貼子,editplus 可以這樣用. 精華一定要多吸引,我用的是phpstorm ,也有著大量的快截鍵的,editplus 能實現的,大點的ide 也可以做到的. 至於,查看類的結構,追述代碼,整合svn ,phpunit ,語法檢查,代碼提示這些editplus 就不給力了.
