編寫額外的代碼以避免學習新的框架

Question

我是一個在我工作的地方的單人店，當我在那裏開始工作時，我沒有經驗和一個低於標準的計算機科學學士學位。最重要的是，我在公司的第一個項目不僅要搞清楚好的設計原則，還要學習一門新的語言。不用說，我的代碼在一開始就很糟糕，從那時起我添加的所有新功能都被黑客攻擊了。對我來說，我的軟件能夠像以前一樣運作，這真是太神奇了。

我任職期間我學到一噸，和我渴望我的重構代碼，使其更具可讀性所以未來的新員工可以深入並幫我一下吧。我也非常希望能夠更輕鬆地添加新功能，而無需一起破解東西。我認爲學習像Prism for WPF/Silverlight這樣的框架是有用的，但是我有一個很大的待辦事項列表（因爲我是一個人的商店），而且看起來它需要相當長的時間只是爲了學習如何使用它。

現在我已經閱讀了關於棱鏡的地方，我知道它背後的基本原理一點點。此外，編寫我自己的代碼並不難，它可以完成Prism所使用的一些相同的功能。我已經在一定程度上做到了這一點，並且我正在取得更好的模塊化。

我的問題是：我應該去寫更多的基礎結構代碼，讓我正是我需要的，並沒有更多的，或者我應該花時間去學習類似棱鏡的時間？或者可能會這樣問：我應該花時間寫自己的簡單定製解決方案嗎，還是應該花時間去掌握一個可能比必要更復雜的豐富，龐大的框架？在作出決定時應考慮哪些因素？

Answer 1

我寫了我自己的PHP MVC框架，用於最近的項目，正是我所需要的。這很有趣，教會了我很多，並且總體上很好，我永遠不會再做。雖然是一個很好的輔助分心項目，但它極大地降低了我在項目中的生產力。

真的，這很大程度上取決於您需要開發多少基礎設施。如果它只是一點點，不會超過一個小時或兩個小時，那就去做吧。如果需要花費大量時間，請使用其他人的工作，繼續前進，並完成項目。

Answer 2

如果要保持你的寫作將是一段時間了，並安裝了該應用，特別是其他開發人員，那麼任何時間花在學習和整合的標準框架將是值得的。

它會爲應用程序是怎麼寫的任何熟悉框架開發者將能夠更快地把它撿起來提供文件。它應該減少必須編寫的代碼量，並幫助您專注於具體的業務問題，而不是編寫應用程序。

Answer 3

的核心問題是，有多少次，你將重新使用框架，每一次的再實施類似的東西工作，而不是爲您節省？請記住，你從頭開始編寫的東西，如果它應該是任何好的東西，都必須經過測試，針對不同的環境（客戶端& c）進行驗證，並且保持不變 - 所有內容都將免費提供給您「通過使用一個良好的，積極維護的框架。

如果你打算僅僅使用該框架幾次，也許淨收益仍然贊成從頭開始重寫 - 但是如果框架覆蓋了一個字段，而不僅僅是幾個例子，學習使用該框架的投資回報（假設它是好的！ - ）和從頭開始重做的東西將會是，極大的正面！

Answer 4

我大學畢業時也處於類似的情況。在我入住這家小公司的時候，我收到了一家大公司的報價約1.5年。我的教訓是這樣的（可能是你和其他人不同）：

1. 這是一個真棒想法，在一家小公司工作的權利失學。我這樣說是因爲你必須戴許多不同的帽子。例如，您可以編寫代碼，測試代碼，部署代碼，編寫存儲過程等。最終的結果是您熟悉從概念到任何其他過程的整個過程。我認爲這種經歷是至關重要的。
2. 我喜歡寫代碼。我記得那些日子我會開車回家，想起我在生產支持問題上花費的時間。我花了更多的時間來支持客戶，寫一些「我不主要寫代碼」的東西。
3. 爲一家大公司工作對大學來說是一個糟糕的主意。當你在一家大公司工作時，他們對你有特定的角色，並且你有特定的界限。如果您是一家大公司的開發人員，則可能是您沒有將應用程序部署到生產環境，或者調整存儲的特效庫。
4. 爲一家大公司工作對於一個小公司來說是一個好主意。那是因爲如果你在小公司工作，它會迫使你不僅僅學習編碼而且要學習更多。如果你明白你會成爲一個更好的開發者。
5. 與優秀的開發人員一起工作會讓你變得更好。當你和一羣好人一起工作時，你會變得更好。這是因爲每個開發者都有一個特定的歷史，他們爲這個團隊帶來了，而且你們都相互學習。在我主要工作的團隊中，有：MSBuild專家，Silverlight專家和F＃專家以及其他好人。所以有些人從我那裏學習MSBuild，我向他們學習。只要跟那些很好的人談話就能讓你變得更好。

所以如果我是你，不要在那裏花太多時間。也許1年或2年後，找到一個有一些有才華的開發人員的工作。你將在5年內成爲更好的開發者。我知道我是因爲我的舉動。

Answer 5

隨着你給的背景 - 大多是受過自學和沒有同行討論你當前的發展 - 你應該絕對檢查出其他庫和工具。至少，獲得新的輸入是如何設計代碼和解決問題的。你可能會覺得你已經取得了一些成就 - 而且你有，祝賀 - 但這是一個高原，而不是高峯。

「我沒有時間去學習新的東西，因爲我有太多的事情要做」
- 這就是我在你的理由更多的代碼讀取。 這是一個警告標誌 - 您正在將自己轉移到危險的位置。沒時間學習？沒時間記錄？沒時間想想所有的影響？沒時間做對了嗎？沒時間培訓新員工？沒時間一天打電話給它？

你不會通過學習棱鏡或任何其他庫來解決這個問題，但這是錯誤的理由。

三，代碼讓你沉悶。有更多的代碼維護會讓你變得更慢。一個人創業公司可以每天和幾周啓動數百個，甚至數千個LOC。隨着項目和組織的規模越來越大，最終平均只有幾十個。

作爲一個個人經驗的建議：寫建築塊，而不是框架。當你不得不一遍又一遍地用不同的公司標識製作同一個應用程序時，框架非常棒。或者，正如TDWTF的Alex所說，the key is in the differences不是相似之處。

---

我不希望你停止寫代碼，遠離它。但是你正在討論一個權衡問題，並且根據你提供的信息，我會建議把重點放在學習新事物上。

Answer 6

我會玩逆勢：YAGNI（你不需要它）。

如果什麼框架

• 設計很糟糕？
• 是越野車嗎？
• 太慢了嗎？
• 兩年內會有所不同，舊版本將不被支持？

關於框架的討論通常假設框架很好，現實情況是框架與其他任何東西都有所不同，許多框架都被你永遠不需要的東西所覆蓋。

這裏的一些建議，希望對你更具體的問題熊：

• 繼續使增量改進。這聽起來像你正在使用這種方法很有成效，而且它爲你付出了代價。

• 瞭解更多關於框架的。或者多個框架。也許你可以在1到4天內嘗試一個小型試點項目。

• 學習框架不是爲了使用框架，而是爲了挑選出最好的想法並將它們應用到自己的設計中，這是一種光榮的戰略。

• 如果您決定暫時不採用框架，這是一個很容易的決定，可以稍後再訪問。如果你決定採用框架，以後退出可能會非常昂貴。提前支付一些額外費用可能是值得的，以減少製造非常昂貴的錯誤的可能性。

我想我被燒的最多的是依靠別人的代碼庫，從我下面改變出來。我稱之爲「我寫過的每一個Perl腳本在一年後都被打破了」的問題。但是我在許多不同的小項目上工作，這些小項目往往會受到突如其來的影響，並且與創建時間相比，它們的壽命很長。如果您有多年的日常工作，那麼您可以更輕鬆地適應外部框架的變化。

Answer 7

誰擁有該工具？

這就是我每次需要解決每一個問題時都要問的問題。這是評估開發該工具所需努力的主要因素。

當啓動一個大項目時，每個人都定義衆所周知的（在項目範圍內）有用的語句;思考放大抽象層取決於頻率的問題，重要性的問題解決方案，努力開發解決方案。