在閱讀此書的時候,我儘可能和本身的實際經歷結合起來思考,的確產生了一些想法。程序員
年輕學生都志向遠大,上了一些課,就很想解決高層次的問題,一些學生很是想作高層次的「科研」,以爲「工程」是基礎,沒意思。並且他們認爲「我已經知道怎麼作了」。
我應該是書上例子的反面,最開始就是打算解決中低等層次的問題。在學習理論知識的時候,以爲高層次的問題很是抽象。好比對於高級算法的學習,經常是花了不少時間學習,可是過一段時間後就忘了,感受我的收穫不多。算法
因此沒有把重點放在進實驗室作「科研」的方向上,而是去了解移動端開發和傳統後端開發的知識,着手作小的項目。在完成了可以運行的網站以後,的確以爲在Web後端CRUD搬磚有點無聊,開始涉及機器學習,發現「科研」[算法]實際上對數學素養的要求很高,而我的數學水準只是應付考試的樣子。編程
在企業實習以後,發現把本身寫的代碼被merge到master分支,而後到線上環境被不少人使用,是很是有成就感的事情,因此感受作「工程」也不止是搬磚,壓力和成就感都是「工程」可以帶給本身的,而且因爲實際需求,不少時候工程開發不必定比論文灌水更簡單。後端
代碼規範能夠分紅兩個部分: 1. 代碼風格規範,主要是文字上的規定,看似表面文章,實際上很是重要。
以前其實對代碼風格是很是不在乎的,可是最近從新認識到了良好代碼風格的重要性。機器學習
在企業軟件開發的過程當中,我的最開始不注重代碼風格,結果發現本身寫的代碼不能經過線上的代碼規範校驗,採坑舉例:分佈式
g_
開始,而且全局變量的申明以後必修留空一行。private const
字樣,由於這是PHP6.x以後支持的用法,而已有代碼不少使用的PHP5.5和5.6,因此不能使用不兼容的語言特性。後來閱讀別人的代碼意識到,軟件的研發階段時間是不多的, 而維護的時間佔比最大,通常來講,看到的代碼多是上一個離職的人留下的代碼,何況不少程序員根本不寫註釋,這時候若是代碼命名很爛,風格不好,接手代碼的人會很痛苦。函數
在結對編程模式下,一對程序員肩並肩、平等地、互補地進行開發工做。他們並排坐在一臺電腦前,面對同一個顯示器,使用同一個鍵盤、同一個鼠標一塊兒工做。他們一塊兒分析,一塊兒設計,一塊兒寫測試用例,一塊兒編碼,一塊兒作單元測試,一塊兒作集成測試,一塊兒寫文檔,等等。
根據定義,我在網上找到的結對編程是這樣的:單元測試
然而我在短時間的企業實踐中不多觀察到這種編程方式,根據個人觀察,若是出現兩我的對着同一個屏幕,更多時候是在討論爲何出現了這樣一個bug,怎樣去修好(而且這種狀況下仍是由於其中一我的搞不定),而不是怎樣設計文檔以及編程的過程。學習
雖然兩我的一塊兒工做可以更爲全面的審視代碼,可是我的感受是一種下降效率的方式,不一樣的人思惟不一樣,代碼風格不一樣,話說兩我的坐在一塊兒寫同一個函數會不會由於大括號到底要不要換行而吵起來呢?測試
- 用戶體驗的創新 - www.hao123.com有什麼技術上的創新麼?
關於hao123.com是如何作大的,書中並無具體的描述。
在200x那幾年hao123的確是個現象級網站,那個時代不少網吧上網導航都默認是hao123。hao123在早期來看的確是一個沒有技術含量的網站,只是單純的收集各類網站的連接,看起來好像很容易被複制,可是查閱了一些資料總結一下:
而在這一年,互聯網也遭遇了一個寒冬,不少粗製濫造的小網站紛紛倒閉,不過hao123倒是挺幸運,熬過了這一關。這並不是意外,而在於李興平執着堅決的收錄原則:不收錄有不良內容或提供不良內容連接的,以及網站名稱或內容違反國家有關法規的網站;不收錄無實用內容的網站,包括那些尚無完整內容正在建設的網站;不收錄含有病毒、木馬、彈出插件或惡意更改他人電腦設置的或有多個彈窗廣告的網站;不收錄掛靠別人的網站下的網站,即沒有本身單獨域名的網站;不收錄在正常狀況下沒法正常鏈接或瀏覽的網站……正是由於堅持這幾大原則,hao123更爲健康,獲得用戶的喜好。[摘自CSDN]
其實是由於保證了網站質量,而的確不是由於技術上的創新。
這一章沒有什麼問題,可是更加清晰地認識到了敏捷開發的流程。每一個Sprint迭代中給每一個團隊成員分配卡片任務,時間以天數爲單位,同時每週例行站會和每週總結,比較適合快速迭代的開發,可是這種開發模式,文檔這些方面會弱勢一些。
『軟件工程』一詞最先是由 Margaret Hamilton 在阿波羅11號登月計劃準備期間提出的,她最開始使用Soft Engineering詞是爲了和硬件以及其餘工程學作出區別。
『軟件』術語最先出如今出版刊物是在1953-8月,被Richard R. Carhart提出,而最先使用「software」是在JSTOR電子刊物的一篇調研。
使用排名:
軟件特色: