讓我安安靜靜的寫代碼


我只想寫代碼

從源代碼控制管理,到構建工具,再到軟件測試,最后部署,這種管理開發工具鏈的復雜性現在已經超過了開發人員的能力,很難得到真正的實現。

像大多數開發人員一樣,我因為喜歡創造東西而愛上編程。不是任何東西,而是讓其他人覺得有用的東西。我喜歡不斷的解決問題,我喜歡看到在我的腦海中存在很長時間的抽象概念轉變成現實存在的東西。在為創造而工作的過程中,在第一次成功運行測試時,我會有種特別的快樂。它是一種混合創造和消費的感覺,直到最后,終於,我可以測試新的功能,驗證它是否正確工作,並感受到內心瞬間欣喜若狂,血脈賁張。

所有的開發人員都知道這個快樂。而且,當然,他們知道耐心,紀律,和長久工作才可以獲得這種快樂。那些日子,大浪洶涌的喜悅和對前期工作的滿意已經變成非常難忘的經歷。

但現在,所有方向都指向錯誤:每天的工作是不堪重負的非編碼活動;因此,歡樂的高潮點,不僅罕見,相隔也相對較遠。歡樂之間的事情感覺像苦差事。私人項目中,我不斷聽到自己的咒罵,“我只是想編寫代碼。”

很長一段時間,我已經將這種無奈歸因到今天軟件的復雜性。很久以前幾百行C++的簡單程序早就從我的經驗中消失了。騎自行車的經驗已經等效於大型噴氣式客機旅行的經驗;充滿延誤,檢查,對個人選擇的限制,和突然不明原因的取消 - 所有這一切導致成本的顯著提高。哪里容得下快樂?

但事實上,病因不是軟件項目本身固有的復雜性 - 盡管它肯定是一個促進因素 - 在軟件開發中使用工具造成了大量的開銷。一個簡單的項目 - 例如您自己的開源移動應用程序。比方說,比較您走過的距離和它的直線距離。例如一個概念十分簡單的東西,就像容易開發,但有足夠的挑戰從而使它有趣的軟件。首先,您將需要選擇一個源代碼控制管理方案。如果您想要任何社會團體參與,Git肯定是最好的選擇。使用Git麻煩的是,它是建立在自己的小世界里的。您可以使用教程,學會讓您從一個最小的A點到B點。但是,如果一個潛在的貢獻者要fork您的代碼,您最好理解pull請求,分支和合並,以及一系列其他的操作的概念,可能有,也可能沒有您用過的其他的代碼管理系統的概念。即使他們在概念上類似,Git也用不同的動作來完成同樣的行為。

假設您知道您打算使用的IDE或編輯器,您現在需要解決構建周期。每一個移動平台都有自己偏愛的構建工具。除非您寫的東西令人嘆為觀止的簡單(所以,您寫的不是這個程序),您需要做的不僅僅是想出一個簡單的構建腳本。您需要了解構建工具背后的理念:它是如何工作的,它需要什么,以及如何定義您自己的具體項目。如果您使用的是“約定優於配置”工具,您可能會發現,您用錯誤的方式創建自己的項目,現在需要回去並且改變整個目錄結構。

我們還遠遠沒有完成。您將需要部署應用程序。然后您將不得不在某些設備上進行測試。假設您想清除這些障礙 - 沒有一個微不足道的障礙 - 您需要一個bug跟蹤機制。同樣,如果您想別人參與,您需要使用一種常用的缺陷跟蹤工具,而不是給自己的筆記或電子表格。最后,如果您想讓別人使用應用程序,那么您必須首先獲得各種供應商店的批准。這還有趣么?我們甚至還沒有開始寫代碼。

項目開銷,即使是簡單的項目,也是如此的沉重,這是一個奇跡,任何人都可以找到時間編寫程序,但很難從中獲得原來的那種快樂。軟件開發已經成為大多數業務活動,而不是創造性的活動。這里的根本問題不在於應用程序的復雜性,而是工具的復雜性。在過去十年,因為追逐可擴展性,全面性,性能以及除簡單的一切,工具已經失去控制。大多數工具都有自己的API,許多工具擁有自己的DSL。您要么學會一個新的子語言,您要么對它們進行編程來二次開發。在每一個方向,復雜性是一個難以避免的現實,它帶您遠離核心開發活動:編碼。

一個可用的最簡單例子是一個移動應用程序例子。如果我選擇了一個Web應用程序,我們需要增加因處理語言的多樣性要求,部署棧元素,時間碎片分析,NoSQL數據庫而造成的開銷。我們甚至沒有觸及雲的其他復雜性。我肯定我自己不是唯一對這種情況感到疲憊和無奈的程序員。下周,我將討論開發商和網站如何解決此問題。同時,如果您已經開始處理這個問題,請分享您的方法。

— Andrew Binstock
主編
alb@drdobbs.com
Twitter:platypusguy
Google+

文章翻譯自:http://www.drdobbs.com/tools/just-let-me-code/240168735


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2021 ITdaan.com