【今天被公司開除了
好難過
事情的起因是我覺得很冤枉的：
昨天領導發通知說：
「明早8：00開會
帶好你們吃飯的傢伙在辦公室集合。」
結果到辦公室一看
懵逼了！
同事們都帶著膝上型電腦
我特麼拿了個碗……】
【茄子甲：大家一起照張合影吧！
眾茄子：好啊，好啊！
茄子甲：我喊一二三大家一起喊：人類！
乙隻茄子好奇地問：為什麼要喊「人類」啊？
茄子甲：他們人類照相的時候不是喊「茄子」嗎！】
專案開發中要注意的各個問題？？？
實話說，《程式設計師修煉之道》真的沒有《**整潔之道》這本書好，它範圍廣，多少有點失望，這是最後一篇總結，希望大家能喜歡。接下來我會總結《重構-改善既有**設計》和《併發程式設計》等一系列的書，希望大家喜歡…..
需求之坑
需求是對需要完成的某件事的陳述。
不要蒐集需求，挖掘他們。完美，不是在沒有什麼需要增加，而是在沒有什麼需要去掉時達到的。
找到使用者為何要做特定事情的原因，而不只是他們目前做這件事情的方式，這點很重要。
用文件記載需求背後的原因將在每天進行實現決策時給你的團隊帶來無價的資訊。
與使用者一同工作，以像使用者一樣思考建立需求文件
使用專案詞彙表。專案需求會有很多專有名詞，維護它們
不要在盒子外面思考（找到盒子）。注重實效的團隊
不要留破窗戶(發現**問題盡早修復)。無處不在的自動化多交流，這是成長的乙個重要捷徑
不要重複你自己（**等等）
正交性圍繞功能而不是工作職務進行組織。
一切都要自動化開發**，專案構建，專案編譯都可以使用現在主流的自動化工具，比如git，hudson等等開發工具，實現自動化，提高效率
不要使用手工流程無情的測試乙個注重實效的程式設計師通常會對自己進行無情的測試。以免以後經常有別人找到我們的bug所帶來的恥辱。
早測試，常測試，自動測試。測試什麼單元測試，整合測試等等。要到通過全部測試，編碼才算完成
測試資料
資料只有兩種：現實世界的資料和合成的資料，實際上我們兩者都需要，因為這兩類資料的不同性質將揭示出我們軟體中的不同bug。
演練gui系統
對測試進行測試
通過「蓄意破話」測試你的測試徹底測試
測試狀態覆蓋，而不是**覆蓋何時進行測試很多專案往往會把測試留在最後一分鐘，我們需要比這早得多的開始測試，任何產品**一旦存在，就需要進行測試。
把網收緊
如果bug漏過了現有測試網，你需要增加新的測試，以在下一次抓住它。
乙個bug只抓一次一旦測試人員找到了某個bug，這應該是測試人員最後一次發現這個bug，應該對自動化測試進行修改。
全都是寫
把英語當作又一種程式語言為專案製作的文件基本上有兩中：內部文件和外部文件。內部文件包括原始碼注釋，設計與測試文件等等，外部文件比如使用者手冊，不管是什麼文件，都是對**的反映，如果有歧義，**才最要緊。
把文件建在裡面，不要栓在外面**中的注釋根據原始碼中的注釋和宣告產生格式化文件相當直截了當，但首先我們必須確保在**中確實有注釋，**應該有注釋，但太多的注釋可能和太少一樣糟。
可執行文件
模型是原始碼，模型的一種檢視可以編譯，其他檢視意在用於列印或在web上檢視，我們的目標是總在模型上工作，不管模型是**自身還是某種其他文件，並且讓所有檢視自動更新。
列印還是編排
發布出的書面文件（需求）都有乙個固有問題，它剛列印出來，可能就過時了，任何形式的文件都只是快照。
標記語言
文件和**是同一底層模型的不同檢視，不要讓文件變成二等公民，對待文件要像對待**一樣用心。
不要做形式方法的奴隸在現實中,專案的成功是由它在多大程度上滿足了使用者的期望來衡量的.不符合使用者預期的專案注定失敗。昂貴的工具不一定能製作成更好的設計
溫和的超出使用者的期望
對於需求，要和使用者交流期望。
交流期望
與使用者進行交流，而不是試圖控制使用者。
額外的一英里
給他們(使用者)的東西要比他們期望的多一點，生活需要驚喜，使用者也一樣。
傲慢與偏見
在你的作品上簽名（在**上寫下你的大名，有很多好處哦！）你的簽名應該視為質量的保證
來自歌德《浮士德》
優雅程式設計之這樣處理邊界，你就「正常」了！
貓和狗結婚，不久鬧離婚。法官問原因，狗說 貓婚後每晚都不回家，行為不軌。貓大喊 冤枉啊，我只是去追老鼠。狗說 法官你聽聽。如何優雅處理與第三方api的邊界問題？1 學習性測試 在專案中引入第三方api的新版本，測試專案是否正常工作，當然我們基本上沒有時間去重頭學習和研究第三方工具或者自己寫 來實現第...
Python優雅程式設計技巧
標籤 空格分隔 python 需求 把list所有成員元素加倍。普通的方式 bag 1,2,3,4,5 for i in range len bag bag i bag i 2優雅的方式 bag 1,2,3,4,5 bag elem 2 for elem in bag 普通的方式 bag 1,2,3...
優雅程式設計之這樣注重實效，你就「正常」了（十二）
專案開發過程中，注重實效的途徑？下面是來自 程式設計師修煉之道 中，自己的一些總結 重複的危害 系統中的每一項知識都必須具有單一，無歧視，權威的表示。不要重複你自己 重複是怎樣發生的 讓復用變得更容易 正交性 正交性 從幾何學中借來的術語，如果兩條直線相交成直角，他們就是正交的。兩個事物中乙個發生變...