寫程式碼容易,程式設計並不容易

類別: IT

當我的程式設計生涯開始的時候,我認為“程式設計很簡單……怎麼會需要去學校學習呢?”但經過學習和實踐,我瞭解到程式設計很難。

不知道是程式設計不難還是我什麼都不懂。 ~MemeGenerator.net

自我評價對我自己來說一直都很重要,因為在一天結束的時候,不管別人怎麼想,自己的想法都很重要。我會在評價中思考強項、弱項、學習、訓練和個人成長。這個過程讓我反思、理解並思考成為一個程式設計師究竟意味著什麼。

教育:編碼?程式設計?關鍵性的抨擊?

我在技術領域的第一份工作主要是通過 HTML、CSS 和 JavaScript 操作一些元素並建立視覺效果。在這段時間裡,我沒有真正想到自己是一個程式設計師,對於這個問題,我從來沒有想要成為一個真正的程式設計師。不久以後我想使用 NodeJS、PHP 和 MySQL 做更多事情,這時候我開始考慮這個問題。把我作為程式設計師的所有巨集偉想法加起在一起,我在第一份工作中把自己當作一個小小的“軟體工程師”,一直都在積極地制定方案。

“經驗告訴我,我會頗具氣勢地拍、打和敲擊鍵盤,但那並不是程式設計。”

程式設計需要思考和理解各種資料型別、結構,並理解程式語言賴以構建服務的技術。差異主要在於完成特定任務時所使用的流程。重點不在於資料型別、設計模式、演算法型別、效能或任何與程式碼和應用程式質量相關的內容。相反,它被納入了實際的工作機制和技藝之中,這往往需要耗費大量的時間,最終變成一隻難以維護的巨獸。一直執行輸出到不同地方,並積極地測試輸出,直到它非常類似於一個功能。如果有什麼事情給我一種程式設計的感覺,但我在實際操作中並沒有做到將想法付諸行動。

思考資料

資料結構是我感受到教育不足的一個方面。資料結構背後的想法是,你有不同的方法去儲存、提取、排序和搜尋資料。最初當我開始程式設計,我從來沒有想過各種資料的任務與資料型別的效能。對需要儲存、排序或遍歷的任何事物,通常預設使用陣列(包括雜湊、json、字典,以及鍵-值資料集的其他術語)。

從電腦科學的角度看,集合、堆疊和佇列對我來說是很有趣的,但在 Ruby 程式語言中看到一些實際操作之後,對我來說並不那麼吸引人。在我看來,堆疊和佇列是一樣的,它們允許你從資料的末端獲取資訊,佇列的例外情況是,你只能按照它們加入的順序獲得這些項。當我開始想象這一點時,我想把東西放在一個列表中,等待處理,減少可在後臺執行的任務的開銷。事實上在高層次的程式語言如 Ruby 中對此付諸實踐,並沒有多大意義,因為它基本上是在往陣列中 push(後追加)或 unshift(前新增)元素。

比如,Ruby 中的棧可以像下面的程式碼一樣簡單。

class Stack  # init stack   def initialize     = Array.new()   end  # put a new item at the end of the stack   def push(x)    .push x  end  # get the last item in the stack  def grab    .pop  end  # is the set empty true false bool   def empty?    .empty?  endend# implemented stacks = Stack.news.push 'a' s.push 'b's.push 'c' s.inspect #<Stack:0x48b66454 =["a", "b", "c"]> puts s.grab # "c" puts s.grab # "b" puts s.grab # "a" s.grab.inspect # nil

佇列和上面建立的資料型別基本上是一樣的,Ruby 已經有一個類了。

# ruby Queue Classq = Queue.newq << 'a' q << 'b'# Tests Examples using Queueputs q.length  # prints 2 puts q.pop # prints aputs q.length # prints 1 puts q.pop # prints b puts q.length #prints 0

它的簡單性是基於一個非常簡單的陣列,這本身就體現了它的美。我看到自己在命令列指令碼中使用棧或佇列,但我不確定還可以在別的什麼地方使用它們。

二叉搜尋樹在處理搜尋資料的時間和速度上吸引了我。我經常發現從資料中獲取資料非常容易,但在陣列中搜尋需要花大量時間。這就是為什麼需要二叉搜尋樹,我非常喜歡哈佛的這段視訊。雖然我並沒有使用這些東西來做過什麼,但是非常想用它們來實現點東西,然後將之與原生 Ruby 的陣列方法進行比較,看看二叉樹比普通的陣列或雜湊快多少。我在關於二叉權勢的研究中試圖找到實際的用例,於是發現了這些有意思的文章。

  • 搜尋字串— 來源於 yuya-takeyama的 Gist

  • 數值搜尋— 來源於 Zach Kemp

可維護性

我的第一個 Web 應用在可維護性方面可笑極了。沒有編碼規範,沒有設計模式,沒有對定義的方法進行整理,沒有使用名稱空間,也沒有物件和模型。如果一定要我去修復缺陷(肯定會有),與其去找實際導致缺陷的方法,還不如重寫來得快些。

設計拙劣導致亂糟糟的程式碼。

我難以處理的問題之一是條件巢狀和迴圈巢狀。這些迴圈中存在大量的 if 語句和驗證,但這個問題本身來源於一個系統性的問題,即不清楚怎樣恰當地組織和拆分程式的不同部分。我曾嘗試著在一個巨大的方法中處理所有事情,不關心哪些程式碼可以重用,也沒建立一個模組來擴充套件物件和方法的功能。為了節省篇幅,下面的程式碼擷取自真實的程式碼。

print " <h3> Display Weekdays: </h3> ";// Looping in a view ... should have been factored diffforeach($imageRecords["display"] as $ => $displayRecords) {              // WTF is this a nested foreach      foreach($displayRecords as $value => $dispRecord){       $tempWeekdayValuesArray = array();          if($value === "weekdays" && !isnull($dispRecord)) {             // 3rd nested foreach WTF!             foreach($dispRecord as $weekday => $weekbool) {                 // :( condition foreach day ::SHAME::                 if($weekday == "monday" && $weekbool == 1) {                    // logic removed                   }              }                         }      }}

我不會把責任推到別人身上,這段壞程式碼是我寫的,我會承認這一點,然而其中一些本來可以通過程式碼導師、或者通過程式碼審查和“拉”請求來加以緩解。回顧這段程式碼,我感到慚愧,但這是一件好事,因為它表明了我作為一個開發人員的成長程度。自由在某些意義上是一個問題,但不是在其他方面。例如,對這個專案我被限制於使用 LAMP 技術棧,這是不容協商的,但與此同時,這真的是唯一的限制。我沒有使用設計模式,遵循任何風格指南, 使用程式碼分析器,或遵循程式碼公約的任何政策。這就建立了一個系統,你可以自由地使用自己的裝置,並且如果你還沒有了解應用程式的長期性和錯誤修復,那麼它會損害你的最終結果。

我已經真正體會到了文字編輯器的好處,在你編寫程式碼時它會給出提示(指出潛在的錯誤)從而為你節省很多時間,同時我也開始欣賞與程式設計相關的一些美好細節。一個寫得很好的程式碼庫,會遵循文件標準、清晰的約定和風格指南,閱讀起來就像一封電子郵件或一篇網文那樣流暢。(當然,有時候使用的程式語言本身就更好)總地來說,我也發現我很喜歡這本書中的許多原則, Robert C。 Martin 和其他作者的《敏捷軟體匠人的整潔程式碼手冊》

測試驅動開發

在我看來,測試驅動開發的好處足以證明其優點,但我明白,並不是每個人都同意測試為程式碼庫提供任何價值。我不會爭論測試的有效性,但我確實想分享它如何幫到我。在實際建立程式碼之前,為程式碼編寫整合測試和單元測試已經在很多方面幫到我。它幫助我編寫更整潔的程式碼,高效地編寫程式碼,並幫助我解決了我遇到麻煩的問題。

編寫更整潔、更高效的程式碼與程式設計中的許多事情有交叉。可讀性、效能和編碼時間是 TDD 幫到我的主要方面。我發現我能編寫程式碼,不必重構(多次)使其可以上生產線或進入版本控制庫。它不僅幫助我減少了 bug,而且幫助我減少了跟蹤和修復 bug 所花費的時間。修復 bug 時,我發現我可以接受預期的輸入或輸出,編寫一個與之匹配的測試,然後努力使該測試和所有其他測試通過。這樣可以消除 bug,並確保程式碼實現其預期的目的。

在開始編寫實際的方法或物件之前,TDD 可以幫助我組織思路。在更復雜的功能中,它可以幫助我將功能分解成其需要正常工作的集。也就是說,邊界條件就是邊界條件,並且在最初建立程式碼時往往更難於考慮到邊界情況。最終我覺得測試驅動開發有助於使我成為更好的程式設計師。

寫程式碼容易,程式設計並不容易原文請看這裡