形勢加快網絡開發
我一直在做一個項目，最近在UI開發似乎是消費方式太費時間。在這種情況下，就計算機科學或複雜性方面而言，服務器端的「業務規則」比表示方面複雜得多。
我發現自己的頭靠在牆上劃傷/撞擊，行爲問題與直覺方法不同，一直到成爲時間浪費和糟糕文檔的黑洞，我可能試圖獲得簡單的用戶界面元素排列正確。
我不是在抱怨;我知道有複雜性和廣泛的受衆支持Web開發，但我感到困惑的是，需要多長時間才能完成什麼似乎應該是簡單的部分，而複雜的邏輯，數學，科學編寫代碼需要多長時間等
問題
什麼是你的想法和親身經歷從概念，你可以有怎樣的感覺的方式去現實與網絡的發展和迅速做到這一點，或至少它可能需要多長時間？我有意不提及任何框架或語言，因爲我真的很想在這裏介紹一下你使用的Web開發堆棧，哪些工具或最佳實踐可以幫助你更快地完成工作，以及如何最終得到完全不脆弱的代碼並充滿黑客。
誇張，語言偏好和所有想法都歡迎，我至少想知道什麼被用於web開發，並且成功率很高，即使它不是最新和最偉大的事物。
感謝您的輸入。
-bn
我個人發現把一切都變成小任務有幫助。
我喜歡設計網頁的方式：
如果你有這一切都破碎成小任務，當你得到每做，你覺得更有動力繼續工作。
就像我說過的，這就是我的做法，它似乎很快，特別是因爲我每晚只能工作1到2個小時。
我使用UI設計器。他們非常適合這種事情。
我在我的應用程序需求中圍繞什麼是實用的，有時候在前端工作方面很容易。
我一直在使用.NET堆棧約5年，ASP.NET MVC堆棧約3個月，舊ASP約4年。
處理複雜性的關鍵是緩解它。在你的代碼中，總是把複雜度抽象到合理的水平。例如，假設有10個步驟來下訂單。在這種情況下，在更高層次上，您可能會有一種方法'SubmitOrder';根據它可能會有10個方法要求插入適當的記錄，處理庫存等。在每個「商業」層面，您只需處理這些業務問題，甚至可以在這些層次下面處理數據和機械細節。所有這些層的好處是你可以使每個層都處理一大塊工作，並且當你接近UI時，你有一個對UI來說很有意義的「接口」，以及應用程序需要的方式流。
以上添加了它第一段很混亂。請不要告訴我你正在使用MVC作爲錘子。當你需要像ViewState和Postback這樣的東西時，不應該使用MVC，所以不要在MVC中使用Telerik控件。 – Martin 2009-08-27 01:56:30
如果您使用'回發控件'，只需註釋一下您不應該使用MVC。稍後再編輯。 – 2009-08-27 10:54:57
我的公司主要是.NET開發，我們已經成功地在數據訪問層使用'網絡層'模板。這些模板被加載到CodeSmith代碼生成器中並指向數據庫。最終的結果是任何你可能想到的。它將生成您的DAL，webservice，winforms UI庫，Web UI庫，示例網站和管理工具等。一個節省一些開發時間的好工具。一探究竟。
就實際工作在用戶界面，我認爲這可能有利於實際聘請專業人士。我們有一位專業的設計師與我們進行一些合同工作。我們所做的一切都是將UI連接到我們的UI組件和代碼。
我認爲你對UI開發有點誤解。用戶界面的開發很困難，通常低估其重要性。
需要了解基礎知識 - 在跳轉到HAML之前，請了解您的HTML，以便了解您正在抽象的內容。在跳入jQuery之前，花點時間學習JavaScript基礎知識 - 您不需要成爲專業人士，但是當您需要將一些數字加在一起時，您應該而不是去尋找一個插件。對CSS的樣式有很好的理解。學習成爲一個有能力的Web UI開發人員的主題和技術有很多。
這就是說，對於綠地開發Rails很漂亮。選擇jQuery。並且不要選擇隱藏網絡真正工作方式的平臺。
要加快得到一個HTML頁面，看起來像你想：
首先，決定設計並繪製你希望它看起來像使用圖形程序（如果你已經有了一個UI設計師他們做這一步）。然後，編寫與您繪製的相匹配的靜態HTML和CSS。完成後，編寫輸出HTML的代碼，該代碼與您已決定的格式相匹配。
我這樣做是爲了一個非常複雜的Web應用程序狀態，並且發現首先手動編寫HTML和CSS，而不必與你的服務器程序搏鬥，這使它變得更快。
這個問題的答案取決於你是單獨工作還是領導一個小組。
如果你帶領一個小組，你會想掰開職責如下：
設計師 - 這些人應該對自己的圖形實體模型的創建和CSS創建/維護。他們應該擁有CSS作爲一項責任，以便他們知道不會創建出無法在沒有大量代碼膨脹的情況下創建爲無法進行網頁製作的無恥圖形模型。
標記 - 這些人應該擁有HTML，可訪問性，語義，RDFa要求以及與前端數據結構相關的任何其他方面的創作。這些人應該擁有JavaScript，效率要求，內容管理要求，內部流程和前端工具/流程管理，並且通常擁有所有客戶可見代碼的最佳實踐。
應用程序 - 這些人應該擁有服務器端應用程序代碼開發，內容管理系統創建/維護和數據庫訪問要求。這些人是應用程序和服務程序員，併爲數據庫和服務人員提供接口。
質量保證 - 這些人員在認證環境中測試最終產品的所有業務要求。如果發現錯誤，錯誤/票證應該更新並重新分配。直到QA簽署有效後，工作才完成。
業主 - 業主是負責編寫初始項目需求並作出關於項目部署的最終批准決定的人員/團隊。在起草業務需求之外，這個人應該沒有與技術過程的接口。
項目經理 - 此人確保項目不斷前進，並且里程碑按照任何截止日期完成。正是這個人而不是企業主幹預技術過程才能確保事情的完成。此人必須獨立於企業所有人行事，並且不得將其作爲企業的工具。項目經理不得擁有或建議對技術人員的要求進行更改。如果必須對需求進行更改，這是從技術到項目經理到業主的單向過程。
開發的流程應該如下：
1）設計人員創建圖形樣機，並重新分配的bug /項目門票項目企業主。
2）經商業批准後，應將門票重新分配給標記人員或拒絕回到具有特定變更請求的設計。
3）標記寫入HTML和內容。在項目開始之前，任何應用程序或數據庫需求應由業務指定，Markup團隊應爲所有可能的方案編寫代碼。內容結構應完全反映視覺標記上的內容組織，而不考慮呈現。該票據應重新分配給Design for CSS創建。
4）設計編寫CSS以添加演示文稿，以符合他們創建的圖形模型。設計團隊必須有權訪問HTML標記以根據需要添加類屬性，但不應允許進行其他更改。該票據應重新分配給應用程序以完成所有服務器端要求。
5）應用程序應該爲數據庫訪問創建所有必要的需求。如果先前的要求令人滿意或者將其重新分配給標記以更改/添加，則應將票務重新分配給UIT。
6）UIT應該是編寫用戶界面和AJAX需求所必需的JavaScript交互的最後一步。 UIT還應該證明事先完成的標準符合標準，效率和最佳實踐。如果工作不太可接受，UIT應該迅速拒絕該項目。如果需要額外的應用程序工作，則重新分配給應用程序，否則將票據重新分配給質量保證。
7）質量保證是最終的技術停止。這些人測試最終產品的業務和功能要求。如果沒有QA簽字，該項目不能發佈到生產環境。如果業務需求失敗QA不得簽收。在QA簽字後，票應該重新分配給業主。
8）企業主審查項目並確定是否達到所有要求。如果需要更改/添加，可以在此時提交。更改/添加不能提前提交，因爲頻繁更改會延遲所有項目。企業所有者有責任確保其初始要求完整且具體。如果要求沒有經過充分審查，這是企業所有者的錯，現在可以提交變更。正是由於這種責任和其他相關的商業責任，企業主應該因爲較少參與而獲得更多報酬。
這是完成工作最有效的方式。職責分離是非常重要的，遵守這一程序非常重要。如果這兩件事情都失敗了，那麼整個過程就會失敗，並且業務會大大增加開發成本
如果您是自己行事，而不是團隊的一部分，我仍然會遵循類似的流程，並將角色業務所有者推送到客戶端。如果客戶想要對項目完成做出更改/添加提前，那麼他們可以通過修改原始需求合同的變更附錄來支付更多的費用。你不會因爲增加的勞動而減少工資，因爲一個客戶無法彌補他們該死的想法。如果這是令人不安的話，那麼客戶可以支付更多的錢來取消合同。這並不意味着它是生意。如果你的時間不是一個有價值的商品，那麼你不應該單獨做生意。
您已經很好地分析了每一步的過程和問題。但你並沒有提出任何解決方案。記住主要目標是讓電腦爲人們工作而不是其他方式。有了這個說法，我很樂意聽到想法來自動化和優化這個過程的每一步，以實現快速發展。 – 2014-03-03 21:22:16
我個人更喜歡在絕對最後添加AJAX，因爲它可能會使事情變得混亂並使事情難以改變。 – Evernoob 2009-08-27 09:05:54
您可能會詳細說明或提及您將如何配合服務器端代碼開發？許多語言都允許您將HTML和服務器代碼嵌入到一起，但由於顯而易見的原因，這會使事情變得困難（如果不是，那就是另一種討論）。你在什麼階段編寫並綁定後端代碼？ – 2009-08-27 20:45:03
第4步 - 我在 – Martin 2009-08-28 01:10:51