亚洲伊人色欲综合网,宝贝过来趴好张开腿让我看看,亚洲性色成人av天堂,欧美成人一区二区三区在线观看

在大眾的眼里，都認為編程的難度非常大，其實對于編程語言而言，其中的難度差異并不是很大，每個語言都有自己優勢和劣勢的地方，但有一個難點是所有編程人員共同的問題：軟件開發的難點。

本期就和大家一起來說說，如軟件開發的難點，希望能夠通過下面說的這些問題，幫助小伙伴及時解決自己的困難。

不少人都認為，一款好的編程語言可以使開發者在工作時事半功倍，幫助他們快速解決問題，毫無疑問，這一點在很久前的匯編與 Fortran 時代確實如此。現如今編程語言已經逐漸發展成熟，但編程者仍舊需要面臨一些困難和挑戰。但和編程語言無關，原因來自于以下幾點。

阿姆達爾定律

作為編程人員，在需要執行一系列任務時，我們不禁會想起阿姆達爾定律：在計算機的處理器和內存之間,改變其中一個都可能讓計算機速度性能得以大幅提升,但是,很多人都在該提升內存的時候,去提升了處理器,結果就是,花了最大最好的資源,卻沒有起到最好的效果。

舉個例子來說，就是當你想要吃面時，把水燒開需要十分鐘，煮面條也需要十分鐘，即使你找到方法加快了燒水的方法，做飯的時間也不會減少到十分鐘之下，也不可能燒面的速度提高兩倍。

這就是阿姆達爾定律想要告訴我們的關鍵：你能夠獲取的最大速度提升受限于優化的工作所占的比例。

通過這個定律我們來對應著看編程工作會發現，造成工作難度大的原因有很多，首先，我們的工作需要按照一定的順序完成，畢竟同時間做不同的事情很有可能導致每一件事情都做的亂七八糟的結果。

比如，每天的上班時間9點，你可能在盡情的敲代碼、構建或是參加會議，但是你只能同時做一件事，不可能邊敲代碼邊開會，我們將定律套入會發現，即使設法將構建時間降到0，但是并不會快速提升你的項目速度，其他的因素仍舊會限制你的工作效率。

就拿我們之前的例子來說，當編程語言還沒有如今發展的這么成熟時，將程序轉化成計算機可以運行的代碼是一件十分困難的事情，甚至很久以前，我們需要將程序轉化為1和0，然后手動將其輸入計算機，這需要耗費我們在工作中的大量時間。

如果我們能夠找到更有效率的方法（比如Python）來命令計算機，那么將大大的提高我們編程的效率。正如我們現在，編程語言發展越來越好了，不需要像以前一樣使用傻瓜式操作，以前花費90%的時間的操作，現在只需要10%的時間就可以完成了，這意味著如今即便將這部分工作的時間降至0，也只能提高1.11倍的效率。效率提升比以前減少了81倍。

但是由于90%的軟件開發工作都是非常困難的任務，而編程語言只占了其中的一部分，所以即使其再好也不能（直接）減輕我們的負擔。

為什么編程的工作還是這么難？

傳達需求

上述我們分析了，編程工作難其實和編程語言的關系不大，那編程的工作具體難在何處呢？這里用一個實驗來告訴大家，首先假設我們不用計算機需要干什么，而是將一件需要做的事情告訴你的朋友，為你的朋做下所有的決定。

有沒有發現，你需要花費大量的時間才可以向你的朋友解釋清楚所有的背景信息，他需要了解程序處理的現實問題以及你需要提供哪些功能。你必須解釋清楚所有的內外部因素。并且其中會發生的突發情況和需要處理的細節特別多。

同時，你還需要考慮不同組件的兩兩結合以及用戶可能會嘗試的各種操作以及會發生的事件，這些都需要你清楚的告知你的朋友。其中的難點不限于，你需要掌握所有的實際細節，并且通過朋友能夠理解的方式來傳達所有的信息等

而到目前為止，我們還沒有談及計算機以及編程語言，理解需求等，這些都是更為艱巨的任務。

描述與規格

描述和規格并不是十分容易區分，我們時常會踏入其的思維陷阱。如果你只有一段描述（“紅色汽車”），則你可以測試實際情況是否符合該描述（“是紅色，但不是汽車”），但是這段描述并不足以傳達如何制造一輛汽車。而這就是規范的用途。

在編程時需要做很多的決定，只是單單的記錄下決策的結果，你就會得到一份雜亂無章的規劃，所以在編寫程序的時候，僅憑描述并不能很好的幫助你完成編程的工作，你需要一份規范。

在看到一段描述（“列出文件”）時，我們很容易認為這是一個規范，因此我們覺得應該能夠告訴計算機執行該動作。但實際上，這中間有大量的決定需要考慮（“文件應以什么順序列出？每個文件一行嗎？”）

在我們編寫程序的時候，規范往往只是一段描述，計算機無法知道“繪制矩形”，但是如果它不知道這個矩形的位置、大小等主要因素，它就無法運行，所以在編寫代碼的時候，你會發現很多尚未完成的決定，這也是為什么我們經常會產生錯誤的原因，我們很難根據一段描述創建規范。

如何解決軟件開發的外在難題？

最快的解決方法是，我們可以尋找一些不受阿姆達爾定律限制的方法，如果任務之間的速度不是完全獨立的（比如優化一個任務能夠加快另一個任務的速度），那我們就可以考慮從技術方面入手解決這個問題。

在編程的時候，更好的語言和開發環境往往可以大大的加快效率，更少的人編寫程序則可以減少組織規模。因為如果都由同一個人來編寫接口的前后臺，就可以削減溝通效率，不僅可以降低編寫代碼的成本，同時改變了工作的方式，還能降低其他的工作成本。

迭代速度是另一個杠桿。你需要了解所有的細節，然后建立一種思維模式。或者可以根據一些顯而易見的細節，構建一個小型的思維模型。最后根據這個模型創建一個小程序，并驗證這個思維模型，這樣每次的編程過程都會為你累積模型，你的模型也會越來越豐富，越來越準確。