/////////////////////////扯點交互////////////////////
//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 就不給力了.
//6 對很多大量重複的工作,使用一些基於模版解析的代碼生成,有助於效率提升.其實,這些是程序員,天生的感覺,什麼東西,你寫多了,自己知道如何去高效的,穩定的去實現他了,再多補充點代碼大全,設計模式之類的知識,做着做着,你就會慢慢的發現在一兩點上想通了,再做着做着,發現通了的地方就慢慢多了,有團隊前提下,積極溝通,慢慢的就成熟了.
//7 對phpunit 這玩意,不要閒着寫個控制器,加載個視圖也去unit一把,重要的核心的,需要障的東西,纔去測試.
//8 大量的使用有保障的代碼,和基礎類,收集的時間長了,好好的整理一翻.
//9 每一個實現的模塊，提供整套的例子.生成代碼時都註釋起來,用的時候方便,免得到處找代碼,有點vs 創建框架時生成代碼的感覺... 好了,非常感謝您有耐心看我扯,歡迎拍磚.
//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 就不給力了.
//6 對很多大量重複的工作,使用一些基於模版解析的代碼生成,有助於效率提升.其實,這些是程序員,天生的感覺,什麼東西,你寫多了,自己知道如何去高效的,穩定的去實現他了,再多補充點代碼大全,設計模式之類的知識,做着做着,你就會慢慢的發現在一兩點上想通了,再做着做着,發現通了的地方就慢慢多了,有團隊前提下,積極溝通,慢慢的就成熟了.
//7 對phpunit 這玩意,不要閒着寫個控制器,加載個視圖也去unit一把,重要的核心的,需要障的東西,纔去測試.
//8 大量的使用有保障的代碼,和基礎類,收集的時間長了,好好的整理一翻.
//9 每一個實現的模塊，提供整套的例子.生成代碼時都註釋起來,用的時候方便,免得到處找代碼,有點vs 創建框架時生成代碼的感覺... 好了,非常感謝您有耐心看我扯,歡迎拍磚.
