完成XHTML，CSS項目後，我們應該嘗試優化我們的代碼嗎？

完成XHTML，CSS項目和Even客戶端後，我是否應該嘗試優化我的HTML，CSS代碼（如果有任何範圍的話）？完成XHTML，CSS項目後，我們應該嘗試優化我們的代碼嗎？

如果是，那麼如何更好地改進和優化代碼以及可以/應該優化哪些東西？

我應該優化以獲得最小的文件大小，還是應該優化代碼以提高可讀性？

來源

2010-03-20 Jitendra Vyas

我建議看看Yahoo! YSlow和Google Page Speed。他們會給你提供比優化HTML/CSS更好的性能增益提示。

來源

2010-03-20 03:24:46 ceejayoz

+1對於谷歌網頁速度 – pixeltocode 2010-03-20 03:51:58

我想你應該考慮做以下，順序如下：

業績回顧：回顧你如何和你的團隊可以工作更好的項目更快地創建出更好的產品。頭腦風暴是本可避免的障礙，以及下一次如何避免它們。
安全審計：分析系統是否存在潛在的安全漏洞。正如俗話所說，「100個加入者只用1個'哦！'擦拭乾淨。」安全錯誤往往是那些類型的oopsies。
文檔：提供技術團隊在18個月後才能加快應用程序以添加新功能所需的文檔。
專業發展：提高你在某個領域的技能，這樣你就可以像在這個項目中一樣在你的下一個項目中取得成功。
早早回家：Wii，XBox，放風箏，燒漢堡，做任何你想做的事，併爲你在這個項目上做得很好而感到高興。

只是我的0.02美元的價值。 :-)

來源

2010-03-20 03:27:28 Jaxidian

如何做你的第二點？ – 2010-03-20 03:30:44

@jitendra：如果您在這方面需要幫助，那麼我建議您閱讀微軟出版社的「Writing Secure Code，Second Edition」 http://books.google.com/books?id=_7LEW8VHZk4C&hl=zh-CN After你已經讀過這篇文章，你應該對如何開始這件事有一個很好的理解。我讓團隊中的每個人閱讀本書的部分內容，然後才能觸摸代碼。 – Jaxidian 2010-03-20 03:43:35

但在XHTML CSS代碼中是否存在任何安全原因的可能性？ – 2010-03-20 03:49:35

根據我的經驗，在事實之後進行大量的「優化」往往會造成更多的傷害，然後再做好。如果客戶很高興，沒有明顯的可擴展性問題，代碼或多或少都可以維護，不用擔心。此外，沒有理由優化HTML/CSS的速度，因爲瓶頸幾乎總是在數據庫連接中，文本文件的總下載大小通常相對較小。如果你真的需要他們變小，看看一些自動壓縮。

就個人而言，如果我是你，我只會稱它做完，然後走開。

來源

2010-03-20 03:39:50 Morinar

+1「只要完成並走開」 – pixeltocode 2010-03-20 03:51:13

我會選擇文件大小優化的可讀性，以確保下一個打開HTML/CSS文件的人不會有糟糕的一天。

來源

2010-03-20 03:43:10 pixeltocode

取決於客戶是多麼高興我猜，他們將成爲回報客戶的可能性，如果這是您的項目目標。

如果它既不在這裏，也不在那裏，我不會打擾。太麻煩了，沒有重用。唯一的例外是，如果它顯然是壞的SQL被黑客一起「使它只是工作」，經常使用，或重的JavaScript動畫，我會繼續並開始一個新的項目儘快審查後，你是一個成功的即將完成。

如果您修改代碼 - 您需要重新測試它。

爲什麼不花時間測試呢？

您可能從重構代碼中獲得更多價值，供您自己使用（如果可能）。

如果您滿意地滿足所有要求 - 將項目交給客戶的時間比他們預期的要早。

來源

2010-08-12 02:11:05

完成XHTML，CSS項目後，我們應該嘗試優化我們的代碼嗎？

回答

相關問題