夢斷代碼閱讀筆記之六
第三章--原型與Python
我們在編程的前期選擇語言的時候是最難過的，這真的是一個痛苦的選擇，文中提及很多種語言：C、匯編、Fortran等等。最後，選擇了Python語言。在我們的編程過程中也會出現類似的問題，一開始的方向和選擇就會決定了後期的安排和進度，所以我們必須在提前規劃好，找到最適合的一個方法來解決才是最重要的。
第四章--樂高王國
那個程序員都渴望這模塊化的代碼，信手拈來，想用就用。把幾個簡單的代碼段進行新的拼裝組合就能實現一個新的功能。但是事實總是與夢想相悖的。文中所提到的考克斯，致力於滿足大家的這一個夢想，但是最後的結論只能是：即使采用了最新的技術，所有的組件寫文檔以便理解，等等等等，這件事完成起來都是極其困難的。可以復用的軟件和現實是有一個很嚴重的悖論的，我們期待著更好的軟件，我們也期待著編程的簡易。但是真正好的有創新的軟件程序都是那些與往常不一樣的想法，與那些模版不一樣的創新之處。沒有創意就沒有真正地完美。
夢斷代碼閱讀筆記之六
相關推薦
夢斷代碼閱讀筆記之六
創意 解決 選擇 程序員 痛苦 創新 即使 似的 找到 第三章--原型與Python 我們在編程的前期選擇語言的時候是最難過的，這真的是一個痛苦的選擇，文中提及很多種語言：C、匯編、Fortran等等。最後，選擇了Python語言。在我們的編程過程中也會出現類似的問題，一開
夢斷代碼閱讀筆記之四
模塊 代碼 clas 堅持 大牛 方式 理解 spa 閱讀 第七章 OSAF的第一個“演示日”，看起來並不順暢的演示，但是卻是實現了以往沒有過的模塊，是工作人員們幾個月的心血。而這整個改變正是許多細節都發生改變的結果。用戶的錯誤理解卻真實反映出關註細節、無視上下文的閱讀方式
夢斷代碼閱讀筆記之三
原因 設計 開始 微軟雅黑 戰爭 分鐘 導航 不足 family 今天我看到了本書的第九章，本章主要講了關於軟件開發的方法論。同時作者為我們介紹了軟件缺陷編年史上數量不多但是足以警示世人的驚人災難。 1962年6月，水手一號探測飛船在發射5分鐘後偏離軌道，
夢斷代碼閱讀筆記之二
不同 beat 缺陷 源代碼 應該 鼓勵 開發 團隊 clas 在本書第一章裏，作者為我們介紹了一些關於開源的歷史和開源的開發方式。同時作者為我們對比了傳統開發模式與開源開發的優劣之處。這兩者的對比能讓我們對於軟件開發模式有一個更深刻的認識。 開源不僅給出
夢斷代碼閱讀筆記01
效果 軟件 目的 我們 四分 想要 軟件服務 spa 實現 夢斷代碼閱讀筆記01 2017.4.20 今天讀了《夢斷代碼》的第一章，十五歲，因為一個遊戲sumer，讓作者開始迷
jdk源碼閱讀筆記之java集合框架（四）（LinkedList）
ray private array public 源碼閱讀 jdk源碼閱讀 oid color 解釋 關於LinkedList的分析，會從且僅從其添加（add)方法入手。 因為上一篇已經分析過ArrayList,相似的地方就不再敘述，關註點在LinkedList的特點。 屬
nsq源碼閱讀筆記之nsqd（一）——nsqd的配置解析和初始化
con views pos 直接 rgba 函數調用 程序 spa 重命名 配置解析nsqd的主函數位於apps/nsqd.go中的main函數首先main函數調用nsqFlagset和Parse進行命令行參數集初始化， 然後判斷version參數是否存在，若存在，則打印版
nsq源碼閱讀筆記之nsqd（三）——diskQueue
hit emp files tro interact 一次 導致 store text diskQueue是backendQueue接口的一個實現。backendQueue的作用是在實現在內存go channel緩沖區滿的情況下對消息的處理的對象。 除了diskQueue外
06軟件需求模式閱讀筆記之六
操作系統 需求 pos 廣泛 正在 亮點 能力 spa 不同 軟件需求模式閱讀筆記之六 這一章主要是說明用戶功能需求模式。用戶功能豐富多彩，它包括查詢模式和報表模式。查詢是一個系統的亮點，一個查詢需求應該指定查詢名稱，查詢的業務意圖，顯示的信息，排序順序，挑選標準，瀏覽，交
06需求工程軟件建模與分析閱讀筆記之六
情況 標記 細節 客戶 管理 優先級 交叉引用 術語 重復 此次閱讀了解到了優秀需求規格說明書文檔的特性。 1、完備性：需求規格說明文檔是完備的，當且僅當：（1）描述了用戶所有有意義的需求，包括功能、性能、約束、質量屬性和對外接口。（2）定義了軟件對所有的情況的所有實際輸入
mxnet源碼閱讀筆記之include
c++ 單例對象 這一 str 結構 封裝 上下 使用 enc 寫在前面 mxnet代碼的規範性比Caffe2要好，看起來核心代碼量也小很多，但由於對dmlc其它庫的依賴太強，代碼的獨立性並不好。依賴的第三方庫包括： cub dlpack dmlc-core googlet
夢斷代碼讀書筆記
計劃執行 形式 境界 魔法 極限編程 每日 現象 運行時 生產力 夢斷代碼，Dreaming in Code， 是作者講述軟件開發路上一系列的坎坷與經驗之談。 第0章 軟件時間 從0開始的技術方式，自然也就講了計算機從0開始的原因。+1，-1正是我們對計算機所作的操
《夢斷代碼》讀書筆記
大量 普通程序員 任務 卓越 思路 改變世界 需要 修復 時長 1.黑洞式的缺陷——即無法確定修正所需時長的缺陷 2.在實際開發中，編碼只占軟件項目開發時間的1/6，有一半時間用於測試和修復缺陷。但只有少數項目經理會真正安裝這種思路來安排開發人員的時間 3.只有在任務能分派
vue中$watch源碼閱讀筆記
vue 告訴 應該 最好 notify type 十分 msg 建立 項目中使用了vue，一直在比較computed和$watch的使用場景，今天周末抽時間看了下vue中$watch的源碼部分，也查閱了一些別人的文章，暫時把自己的筆記記錄於此，供以後查閱： 實現一個簡單的
《大型網站技術架構》讀書筆記之六：永無止境之網站的伸縮性架構
映射 應對 方法 訂閱 知識 位置 n+1 轉換 bsp 此篇已收錄至《大型網站技術架構》讀書筆記系列目錄貼，點擊訪問該目錄可獲取更多內容。 首先，所謂網站的伸縮性，指不需要改變網站的軟硬件設計，僅僅通過改變部署的服務器數量就可以擴大或者縮小網站的服務處理能力。在整個互聯
CI框架源代碼閱讀筆記6 擴展鉤子 Hook.php
cti enable blog have 子列 rmi 是否 lap tool CI框架同意你在不改動系統核心代碼的基礎上加入或者更改系統的核心功能（如重寫緩存、輸出等）。比如，在系統開啟hook的條件下（config.php中$config[‘enable_hooks
設計模式實例(Lua)筆記之六（Adapter模式）
系統 資源管理 公司 個人 title 人的 實例 sel 我們 1.描寫敘述 “我”在 2004 年的時候帶了一個項目,做一個人力資源管理,該項目是我們總公司發起的項目,公司一共同擁有 700 多號人,包含子公司,這個項目還是比較簡單的,分為三大模塊:人員信息管理
ceph學習筆記之六 數據讀寫過程
ceph sds 數據寫過程1、Client向PG所在的主OSD發送寫請求。2、主OSD接收到寫請求，同時向兩個從OSD發送寫副本的請求，並同時寫入主OSD的本地存儲中。3、主OSD接收到兩個從OSD發送寫成功的ACK應答，同時確認自己寫成功，就向客戶端返回寫成功的ACK應答。4、在寫操作的過程中，主
Modbus庫開發筆記之六：Modbus RTU Master開發
客戶端 hold 不同的 rtu 客戶 and 一個 服務器端 操作 這一節我們來封裝最後一種應用（Modbus RTU Master應用），RTU主站的開發與TCP客戶端的開發是一致的。同樣的我們也不是做具體的應用，而是實現RTU主站的基本功能。我們將RTU主站的功能封裝
uunderscore源碼閱讀筆記
value 沒有 cor count return con div on() collect var optimizeCb = function(func, context, argCount) { if (context === void 0) { retu