構建之法 第1 5 17章

2022-07-25 07:54:09 字數 1438 閱讀 8136

**對理想團隊模式構建的設想以及對軟體流程的理解

第一章   概論

程式=資料結構+演算法  這句名言大家都知道。可是,作者連問三個問題,讓我意識到,做乙個軟體工程師,絕非寫非常棒的程式這麼簡單,程式只是軟體的冰山一角,軟體背後還有工作量更為龐大的一系列工程,要做好這一系列背後的工程,才有乙個好的軟體產生。作者後面也對這三個標誌性問題做了回答,程式是基本功,軟體工程決定軟體質量,商業模式決定軟體企業的成敗,從業者和企業的職業道德規範影響了軟體使用者的體驗

程式設計師阿超的略帶幽默的例子,非常生動形象的解釋了,「程式「是什麼,而「軟體」又是什麼。我來稍微總結一下。

簡單的程式        使用者        應用軟體       加入平台         軟體服務

乙個程式設計師       ——>    乙個程式設計師       ——>              乙個程式設計師

一袋煙的功夫      加需求     熬個夜         再多點要求     太複雜,無能為力……

這個例子,展現了軟體工程對於做好乙個軟體有多麼重要,當然軟體工程絕對不是乙個人的事,肯定要有乙個完整的團隊,乃至到了軟體服務階段,需要乙個軟體企業。通過這個例子,也展現了很多軟體工程的基本概念,源程式、資料、構建、源**管理、配置管理、質量保障、需求分析、軟體測試、程式理解、軟體維護、服務運營、軟體生命週期、軟體專案管理、使用者體驗等等。做好軟體工程,那麼就要考慮商業模式和職業道德規範,乙個良好的軟體企業也就應運而生。

軟體工程,顧名思義,就是把軟體專案做成乙個工程,形成乙個工程化的產業。先形成乙個流程,再用軟體工具實踐操作,解決問題,讓軟體更加人性化。

我構建,故我在。隨著對軟體工程的深入理解,將來必須要形成乙個大局觀。

第五章 團隊和流程

「非團隊」,簡單來說就是乙個和尚有水喝,兩個和尚抬水喝,三個和尚沒水喝。

「團隊」,簡單來說就是各有所長,分工合作,最重要的是交流。不同的團隊模式各有利弊,比較常見,也比較成熟的是功能團隊模式和老闆驅動模式,前者成員自由交流頻繁,後者目標明確。

對於軟體開發流程來說,最重要的並不是編碼,而是需求分析。軟體專案,大多都是由使用者發起,最終回到使用者。好的開始等於成功的一半,需求分析做的好壞,直接決定專案的成敗。

第十七章 人,績效和職業道德

團隊,說到底還是有乙個個人組成的,人的能力和素質,才是最根本的。不論做什麼崗位,都要像「豬」一樣踏踏實實把任務做好,當好這個做事的p1.

團隊也遵循著正態分佈原理,一部分最好的人,一部分最後的人,大部分是一般的主流,區別對待還是讓員工們比較容易接受的,隊友評估應該是最開明公正的吧

如果要我在白菜蘿蔔裡選,肯定選白菜,自己做好,再去幫助同事,踏踏實實做人做事,積極溝通交流,應該對我們這些大多數人是最好的選擇。

《構建之法》第8 9 10章

第八章 需求分析 軟體開發團隊就是為了使用者著想,於是總會在程式專案開發前進行專案的需求分析 本章節講述軟體需求的4個步驟,1 獲取和引導需求 2 分析和定義需求 3 驗證需求 4 在軟體產品的生命週期中管理需求 在軟體工程中分析軟體需求需要考慮相關者的利益關係,例如使用者 顧客 市場分析師 監管機...

《構建之法》第13 17章

第13章 軟體測試 問題 軟體測試方法有哪些?第14章 質量保障 問題 什麼是軟體的質量?第15章 穩定和發布階段 問題 軟體發布前要注意什麼?第16章 it行業的創新 問題 在it領域,怎樣做到產品創新?第17章 人,績效和職業道德 問題 軟體工程師要具備哪些職業道德?乙個程式設計師的生命週期 讀...

《構建之法》第4章

第四章是關於兩個人合作的概論 大概就是 規範性 複審 結對程式設計 和兩個人的合作的方式技巧 軟體從來不是乙個人的工作,是乙個團隊的作品。在開始之前我們需要先對程式設計有乙個規範性,不然團隊中的每個人只按照自己的思維去 行走,這是不行的。所以我們要準守 的規範性,這樣對團隊以及他人在工程進行中對 的...