DIV CSS 佈局教程網

開發工作不僅僅只是寫代碼”這句話來自3EV網站的Dan Frost，他在一篇文章中闡述了開發過程中應該注意的一些事項。原文內容如下：
　　開發者是創造數字世界的主力軍，他們不應該只扮演編程工具的角色，而應該對開發工作有更高的要求。那麼，開發者可以從哪些方面提高開發能力呢?下面我就談一下我的想法。我的建議可能不全面，但希望能夠給你帶來一些幫助。
　　1. 不要只盯著代碼
　　如今人人都會寫代碼。很多業余愛好者也可以搭建網站、編寫應用程序，編程已經不再稀奇。
　　隨著網絡的普及，許多人只需通過自學就會編程，但無論是自學者還是科班出身的開發者們都有一些同樣的問題。我面試過一些有很高學歷的應聘者，這些人大多獲得了計算機學位、修過AI課程，擁有各色計算機等級證書，但他們仍然缺乏一些很重要的認識。
　　開發者們不應該只盯著代碼，還需要注意開發工作中的兩個方面——橫向面和縱向面，比如，開發者應該懂得如何在團隊裡與別人協作，也應該清楚開發項目中系統層面的設計。
　　我認為與開發者合作的人也應該閱讀這篇文章。因為如果你對開發了解越多，你可以在合作的時候對開發者提出更高的要求，比如讓他們概括出討論的問題，讓他們提煉出系統的核心功能，用圖片和實例展現應用實現的功能等。
　　2. 重要提醒
　　我想我有資格給開發者們挑毛病，因為我也是一名開發者，並且我了解開發者一些共有的問題，盡管他們對代碼了如指掌，並且能按時完成工作。但他們仍然要注意兩方面：更專業和更具人性化。
　　3. 網絡影響
　　你只要搜索一下專業網站上面的開發技術就可以得到許多答案。比如框架知識、浏覽器、CSS 和JS。搜索引擎會為你找出需要的框架、平台和應該關注的發展趨勢。
　　而這些東西只是我們的工具，它們幫助我們構造項目，但是它們不是項目成功的關鍵。即使一個開發者了解系統中每個細節、掌握了所有API功能和新的CSS技術，他也可能會開發出毫無意義的產品。
　　開發者需要知道如何運用工具，同樣也需要了解觀眾，也就是用戶、團隊和其他開發者。他們需要了解他們的工具對環境的適應程度(換句話說，產品的環境)以及工具的用處。
　　有一種開發者被描述為“wide and deep”，這種開發者懂得如何做好團隊合作，同時掌握著開發的核心技術。如果他們加入項目，會大幅度提升項目進程，改變項目的步調，如果沒有他們，非技術人員就會陷入一些瑣碎細節中停滯不前。
　　4. 我們需要的
　　我最近正在列一份清單，上面羅列了建立網站、管理主機需要的所有東西，可以作為新人學習技術的基礎指南。我們通過不斷的探討來修改清單的內容，希望這份清單能為新人建立一個好的開始。
　　我們給出的清單包含了大部分學習開發需要的知識。其中有經典常用的工具，也有一些新式工具。
　　在開發實踐中，這些工具對推進項目的進展很有幫助，優秀開發者的工具積累應該比編程語言、CMS、框架這些知識更豐富。因為你需要調度、測試、CI、強化版本控制(團隊合作，不是單靠你自己)，同時你不能只了解幾條指南，還需要了解項目的核心理念。
　　5. DevOps
　　這些輔助工具和技巧適用於DevOps模式(DevOps是一組過程、方法與系統的統稱，用於促進開發、技術運營和質量保障部門之間的溝通、協作與整合)。一直以來，DevOps模式中“運營”和“開發”的對決都難分高下。運營主要用來保持事物的運作。而開發用來研制新事物(往往使事物停止運作)。這種矛盾導致了兩個陣營爭執不休。
　　假如開發者不能充分了解產品，他開發的功能往往與產品不匹配，這樣寫出來的代碼也不適合產品。因為他們沒有考慮過產品的使用環境，所以他們的編碼忽視了與產品的調配，而將重心放在了功能的完善中。
　　要注意，這些細節都會導致可怕的延遲，而遠程服務器管理的形式則會加劇這種延遲。
　　如果想成為優秀的開發者，就應該深入學習開發過程中所使用的所有工具。一旦開發者全部學會了這些工具的用法，將會有很大的進展。
　　持續部署和DevOps的相關實踐已成為了一種標准，還沒有對這些理念進行研究的開發者或公司已經落伍了。如果你跟不上發展的步伐，那麼其他人總有一天會超過你。
　　網上有許多對“DevOps”概念的介紹，這種理念與PHP、MySQL或是Rails不一樣。它是降低軟件和工程協作風險的一系列方法。DevOps理念關注的問題主要在於調度、自動化和保持生產流水線更快更好的運行。
　　如果你使用了這種開發模式，你會發現無論是在其他部門還是其他公司之間，開發者們都能有良好的團隊協作。如果他們通過API與第三方合作，他們會研究對方可能出現的問題。但如果他們與服務器管理員合作，他們只會關心他們需要如何配置以及他們的軟件如何安裝在服務器上，這樣做遺留的問題是很麻煩的。
　　6. 代碼調錯
　　Onion’s 首席技術官Michael Greer在關於Web開發者必會技能的問題上給出了一個很好的答案：
　　“懶惰”：拒絕兩次做同一件事情——寫一個腳本或算法來實現
　　“懦弱”：經常測試，擔心過載和代碼影響
　　“魯莽”：經常嘗試新鮮事物
　　“懦弱”是注意細節的另一種說法。要知道，開發者的生活中百分之九十九是由調錯和測試組成的。
　　開發者要了解的是，修復應用程序不僅要懂得挑錯誤代碼，還需要出色的解決問題能力。比如，解決用戶的發票不能下載的問題，不需要花費一天的時間來開發生成PDF文件的功能，只要簡單的將頁面設置成可打印即可。有時一條鏈接比一個星期的編程更能解決問題，而一個只知道寫代碼的程序員很難想到這樣的捷徑。
　　盡管目前有各種各樣的測試工具，但測試對開發者來說依舊是一個奇妙的盲點。開發者應該學會使用單元測試、Selenium、負載測試和像 Xhprof這樣的分析工具。還應該學會使用一些性能檢測工具，比如NewRelic，這些工具可以幫助你保持應用程序盡量少的占用內存。
　　調錯也是開發中一個重點環節。因此，開發者們不僅要學會運用調錯工具，還要知道如何為一個問題調錯——我對Michael Greer的清單做一點關於調錯的補充：
　　“急躁”：忽略那些無關緊要的問題，將時間用在解決真正的問題上
　　以上就是一些基礎原則，開發者要學會抓住主要，忽略次要。真正的開發高手不看代碼就能找出問題。不幸的是，許多人容易盲目的對一個無關緊要的問題推敲數十小時甚至好幾天，解決一個問題也要用同樣的方法試驗十多次。
　　7. 用戶需求
　　作為開發者，要懂得其他人的真正需求。你可以盡情享受編碼帶給自己的樂趣，但與此同時要清楚所有的代碼都是有用的。
　　開發者們需要了解業務、操作和業務流程，這些會有對開發工作很有幫助。只有懂得這些，開發者才可以開發出符合用戶要求的產品。一些開發者能顯示出不同尋常的生產力，不僅由於他們快速的編碼能力和淵博的堆棧知識，更大的原因是他們懂得用戶真正的需求。
　　回到我最初的觀點，現在的開發變得越來越容易，對於開發人員來說市場也變得更有競爭力了。想要更加出色，就要懂得業務需求、開發出讓客戶滿意的產品。因此，開發者應該關注市場。
　　懂得數據如何隨時間變化。以開發者的角度考慮，這些數據應隨著目前流行的或即將流行的技術一起改變。這樣看來，當你的客戶提出一個新點子時，應該考慮到用戶的實際需求，並且提前做好預算。(相反，最壞的情況是，開發者宣稱他們的新技術可以解決所有問題。)
　　開發者們需要掌握很多方面——比如了解終端數據庫的每個領域，如果數據發生改變，客戶端會如何顯示?有沒有更好的方法解決問題?數據庫管理員們往往認為，外界對數據庫的反映很糟糕，但其實是他們展現給了外界一個很糟糕的數據庫。這個世界充滿了混亂和不可思議的情況，數據庫管理員們一定要學會如何應對。
　　8. 繪圖和書寫
　　繪圖是最直接的描述事物的途徑。開發者們必須有能力將他們的構想在白板、紙上展現出來。
　　優秀的開發者要能通過紙上繪制原型圖來表述清楚意圖。如果開發者只會點頭、空口談論或是只會使用編輯器演示，那麼很難取得別人的信任。
　　最好的代碼從速成的繪畫原型開始，多次失敗可以讓你成功的更快。
　　9. 享受樂趣
　　如果要你花費數十小時去解決一個問題，你會怎麼對待?
　　學會享受這種過程——即使這只是一般的工作。作為開發者，最失敗的態度就是對團隊的工作毫無興趣。遺憾的是這樣的情況很普遍，發生這種情況往往是由於開發者們沒有把自己視為團隊的一員。(熱忱的程序員會使自己“在工作中得到更多的樂趣”，你也可以試試)
　　Web和應用程序的開發仍然屬於新興領域，計算機技術的發展需要更多的高級開發者。開發者們不能滿足於現狀，需要盡快投入到高級開發行列中，提升開發工作的效率。
　　10. 保持銳氣
　　這是我要說的最後一件重要的事情：
　　保持銳氣，尋求競爭，無論到哪個團隊都成為最挑剔的那個。
　　團隊中最挑剔的、也最惹人討厭的開發者往往是開發能力最強的角色，而其他人往往滿足於現狀。如果團隊中缺乏這些高要求就很容易造成團隊進度緩慢、競爭力下降。提高自身要求是一種很好的習慣。
　　開發者們還可以通過工作以外的項目獲得更多的經驗，並且學會總結在這些項目中得到的反饋和批評。現在得到的批評越多，將來的批評就越少。當有一天你開始對別人提出的要求進行更全面的考慮，那時你就成為了炙手可熱的高級開發者了。