統一命名後也有很多問題,比如不能相應路徑的變化,還是樣式表好用,隱藏細節啊呵呵,多麼優秀的軟體設計思想.和諧與統一往往是焦不理孟.統一有乙個很大好處,關鍵點一更改,全域性都發生變化.同時這也是他的乙個壞處,有些時候,也許會在不知道的地方發生了不想它發生的變化.所以什麼都統一也是不應該做的事情.
專案到了後期,病毒也來湊熱鬧,此時時間非常的寶貴,掃瞄防毒的時間當然沒有,而這時機器時不可能格式化的(格式化所有盤,當然不可能,重要的檔案會丟失;格式化系統盤,也不成,很多軟體要重灌).只好先將就著,但系統卻越來越慢.有些時候問題就這麼簡單.團體的素質真的很重要,如果大家都有一定的計算機維護經驗,這事情其實可以不發生.但是人是很懶的,不出問題的時候你預見到了問題,為他好讓他做,他覺得麻煩或者說認為擔心多餘,這都還好,如果心理脆弱一點覺得你是在刁難,找茬,可就麻煩大了.像這種局存在雙贏的解決方案嗎?我相信是存在的,只是很難......
專案到了後期,面對堆積如山的問題,大家的思維變得非常之敏捷.工作效率也是非常的高.有些人這個時候就會說,早這樣何至於此.個人覺得這種話非但無益反而有害,這只是個希望,卻沒有任何具體的解決方案.很多人會因為這美好的願望而採用簡單粗暴的解決辦法,反而違背了初衷.
其實經歷了幾天的專案後期的運作，突然更深一層明白到敏捷開發的一些思想。在後期，需求異常的明確：通過驗收。驗收的標準也相對明確。所以我們的工作效率非常之高。軟體開發中最糟糕的是什麼？變化的需求。而在工程中的其他人，也是很怕這個的，需求的變化原因很多：溝通不足，理解錯位，時間緊迫，客戶要求。老話說：30之後才明白，計畫不如變化快。類同於敏捷開發說的遵循計畫不如相應變化。也就是拿變化去刺激專案以進化式發展。很多人一遇到變化就蒙了，可事實上我發現，變化的時候是需求最明確的時候。我現在的理解是:與其製作完美的計畫，不如有計畫的去製造變化。在專案中，客戶的不滿就是我們變化的主因。所以敏捷中才有客戶合作勝過合同談判一說。不過，面對有些客戶，比如說**，這點明顯是很難實現......
最後貼一下敏捷開發宣言：
個體和互動 勝過 過程和工具
可以工作的軟體 勝過 面面具到的文件
客戶合作 勝過 合同談判
響應變化 勝過 遵循計畫
（目前來說，僅僅明白了後兩個，勉強理解第二個，對於第乙個，還不敢說理解，下次專案可以試著加進一些敏捷的思想來）
趕工心得（三）
今天的心得就是 混亂之治。到專案得後期，不准時有發生。人人都在努力，但是卻一直在犯錯，尤其是美工覺得是對的，程式覺得是錯的，程式覺得是錯的，美工覺得是對的。美工為了加速自己的工作採取了一些技巧，可是導致了資訊結構與頁面原型的不配套，那麼在製作靜態頁面就模板會一直卡殼。在這個案例中,只有前兩者同時正確...
趕工與快速跟進
進度壓縮技術是指在不縮減專案範圍的前提下，縮短進度工期，以滿足進度制約因素 強制日期或其他進度目標。趕工和快速跟進是常用的兩種方法，下面就來分析一下這兩種工具。一 趕工 1 怎麼用？得有資源 通過增加資源，以最小的成本增加來壓縮進度工期的一種技術。趕工的例子包括 批准加班 增加額外資源或支付加急費用...
爬蟲心得（四）
這次採集正好趕上我的畢業，所以，晚了三天才看到郵箱裡面的任務，這次處理很順利。但是，也是自以為很順利，結果還是經歷了一些困難。現在就列一下所遇到的問題 目錄 1.requestdetail函式和processarticle函式的作用 2.處理文章 現的img和video標籤 3.注意 request...