2020ASE第一次課程做業—指望與篤信

前言

​ 這篇博客的主題是：指望與篤信。借這一次寫指望與篤信博客的機會，也簡短地進行一次自我反思與自我剖析，反思一下過去，總結一下如今，展望一下將來。

​ 首先我想談一下我選高等軟件工程這門課的心路歷程以及我寫這篇博客的心態變化；我本科院校在南開，並非北航本校升學，因此在我上第一次課以前，我瞭解高等軟件工程這門課的途徑是學長學姐和身邊同窗對這門課的評價。我聽到了兩種聲音：

• 第一種是：高軟必選！！！這是一門可以真正能讓本身有質的提高的「硬課」；
• 第二種就是：這門課只有三個學分，上這門課的時間精力投入不亞於十個學分的課程，高軟不值得；

​ 這兩種聲音在我腦海中交織纏繞，我一時間不知道如何抉擇。這讓我開始反思我本科期間的經歷，修過與高等軟件工程這門課相關相似的課程：企業實習、面向對象分析與設計、軟件工程、企業應用開發。按理說，我應該對軟件工程或者說對工程這個概念有很深的理解纔對，可是實際狀況並非，我這方面的基礎知識，我對軟件工程的理解依舊是一地雞毛；由於我犯了一個致命的錯誤，選課完成課程項目永遠是以學分爲導向、以高分爲導向，而真正忽略了在這個過程當中應該去掌握理解的地方。因此在研究生階段，我給本身定下的一個小目標就是，行爲決定以自我提高爲導向，因此高軟值得！

​ 看了一些同窗的博客，被同窗們坦誠認真的態度所打動。之前的我，對待老師的做業，通常會掩飾本身的真實狀況，交一份看起來盡善盡美的做業上去，永遠作不到對本身徹底坦誠，這樣是極其很差的；老師疲於備課，學生疲於應付，兩者在相對平靜的表象下都沒法獲得自我價值的真正實現。如今我深入地轉變了個人見解：我首對我本身的發展，自我能力提高負責，其次纔是對老師的做業任務負責；一樣的，我認爲，老師首先應該對學生的發展負責，其次纔是對教育體制負責。

​ 可能以上談的一些與課程內容關係並不大，視野也比較小，僅僅侷限與我自己，並無放眼整個軟件工程行業，可是這是我當前最真切的見解，若有不一樣的見解，也請各位批准指正。

課程指望

對於這個問題，我想拆解成三個小問題來回答。

狀態A:我如今怎麼樣？

本科軟件工程專業科班出身，有過網站後端開發、微信小程序全棧開發、移動應用開發相關經歷，也修習過軟件工程相關課程；可是如今有一個新項目擺在我面前的時候，也許不會有第一次接觸的恐懼，可是在面對相關的代碼細節、技術要領這些問題上，我和從頭開始彷佛也並無質的區別。

因此這裏我要問本身個問題，不論是導師仍是業界大廠，都十分看重項目經歷，那麼一次項目經歷，帶給本身的提高是什麼？本身在每次參與到項目中的時候，應該注意什麼？

• 我認爲最重要的一點就是團隊協做，一個團隊以什麼模式運行，用什麼工具協做，以什麼方式溝通，團隊總體的知識技術以什麼方式更迭，怎樣作到成本最小化收益最大化；
• 其次就是技術積累，只要不是徹底相同的項目，接觸的時候必然會遇到新的知識，新的技術；一方面互聯網產業技術更迭很快，須要咱們具備快速學習的能力，另外一方面新習得的技術如何內化爲咱們本身的技能，除了頻繁的練習，那我認爲有效的一種方式是概括總結輸出，造成本身的技術文檔庫。
• 最後可是一樣重要的一點是，分析實際狀況，抽象爲可計算可拆解模型的建模能力也是關鍵的一點。

以上是我目前視角下可以看到的方面，固然不少問題我現階段還沒法解答；從以上三個方面來評價我以前的項目經歷的話，我從以前的項目經歷中獲得的收穫應該是相對很小了。

狀態B:從此我想成爲何樣？

對照以上分析，在項目能力上我但願可以獲得以下發展：

• 團隊協做流暢，不論是做爲隊長仍是隊員，都能很好地把控項目節奏，掌握協做工具，高效溝通交流；
• 技術能力強，技術種類廣，學習能力強，迭代週期短，擅長快速學習和概括總結；
• 可以抓住實際問題的主要矛盾和次要矛盾，將之抽象建模，並可實現爲性能較健壯的系統。

在這門課上我期待收穫到什麼？

1. 對軟件工程更高維度或者更深層次的認識與理解。以前一直以爲本身就像一個無情的搬磚機器，並無在項目中注入本身的東西；同時以往關注的點可能只是這塊功能是否可以實現，除此以外更多的還要考慮這個健壯性和運行效率，一個雞肋功能佔據極大資源的狀況是不可取的。

2. 重拾從事軟工行業的自信。因爲我的因素和2020年疫情的影響，我距離上一次項目經歷已經隔了好久，自認爲本身的代碼能力是相對偏弱的，且因爲計算機行業的興起，學習和從事互聯網行業的門檻下降，帶來的是競爭壓力的加重，如何培養提高本身的核心競爭力，在互聯網浪潮中站穩腳跟是亟待解決的問題。

3. 自我知識體系的重塑。不少內容以前也曾瞭解過，不過如今也印象不深，更像是一團亂麻，面對問題時，也不能有效地理出頭緒，這就須要在這門課學習的同時，對過去的知識結構進行從新的整理與概括。

4. 更高的代碼能力。不論是搭架子仍是實現某個具體功能，我目前來講，是很不熟練的，此次課程的課下練習時間也是一個訓練的機會。

   以前一直聽過這種說法，代碼能力通常分爲這麼幾層：

   • 第一層，起心立志，學習和記憶基礎知識；

   • 第二層，識別基本語法，掌握一些通用成熟的固定技巧和常規表達式；

   • 第三層，讀懂代碼，能看懂代碼，能根據需求實現功能。但具體原理不是太清楚，不太清楚的意思是：不知道怎麼用好，怎麼用很差，存在什麼隱患，有哪些亮點。寫出的每一句代碼，未必有理由，修修改改能獲得正確的輸出結果或實現相應的功能。有必定的可複製的方法或流程，去完成類似的事情；

   • 第四層，有意識地寫代碼，能模仿寫代碼，寫出的每一句代碼，都有理由，自問自答能夠解釋上一級別不肯定的問題，並造成一家之言；

   • 第五層，無心識地寫代碼，能明白地寫代碼，不停的自我否認，自我重建，達到優雅的境界。

   自認爲還處於第三層上下，有很大的提高空間。

5. 更完備的文檔能力，這是一個之前忽視的點，沒有花氣力培養過這方面的能力；逐漸發現文檔能力的重要性甚至不亞於代碼能力；

6. 團隊合做能力，團隊合做經驗的積累，團隊配合方式的探索。

以上列舉次序從我的考慮到團隊，與重要性無關。

提的比較抽象，沒有將收穫目標落實的某一種具體的技術上，但倒是離不開各類具體的技術。

我之項目觀

在回答取得項目成功的關鍵因素這個問題前，有必要考慮一下什麼樣的項目纔是好的項目這個問題。

什麼樣的項目是好的項目或者說是成功的項目？

• 具備實用價值，能夠實現相應功能解決一些問題，或者說研究價值，「有用」，而不是玩具項目
• 有完備的文檔
• 有完整的貢獻管理與維護
• 甚至有周邊項目與盈利生態

那麼取得項目成功的關鍵因素有哪些？

1. 選題有意義，抽象建模合理
2. 團隊合做順暢，高效溝通，能把控節奏將項目按進度向前推動
3. 利其器，根據模型，選擇合適的框架和技術進行開發
4. 集思廣益，充分重視代碼評審環節，確保提交高質量代碼，後續還要對項目進行跟蹤維護
5. 重視文檔，從各個過程重視軟件文檔的撰寫，文檔也是軟件不可或缺的一部分

個人項目計劃

項目內容：基於訂單的家庭工廠協做系統（需求、設計、實現和測試）

典型的生活日用品製造業每每由一組家庭式工廠協同配合，共同生產和組裝，完成最終訂單。系統有幾個關鍵功能：下單(接單)、訂單分解、訂單分配、訂單進度追蹤、訂單完成風險評估、訂單完成效果分析等。要求實現基於網頁或手機端的系統。場景相似與淘寶網購、美團外賣等。

開發任務：我的負責後端開發

我的計劃

因爲還在項目前期，暫未涉及到里程碑和工單任務，目前的計劃集中在自我知識技能儲備提高上：

• 作好心態建設，確保每週至少10h時間投入，作好隨時加班準備
• 軟件工程、UML、設計模式學習鞏固
• python基礎語法，django框架的使用
• 課上認真對待，課下認真開發，互相評審，積極反思

團隊計劃

• 積極參與，高頻率同步我的與團隊間的狀態步調
• 前期分析需求，設計系統，選型出相對合適的框架進行開發
• 中期開發積極推動進度，和團隊成員拆分工單，共同攻克難點
• 後期積極評審代碼，維護代碼健壯性與高效性
• 整個過程當中積極完善文檔

以上就是我第一次博客的所有內容，可能聊了不少無關的內容，這都是當下的我最真切的想法，但願這門課程結束的時候在回頭看，又有新的體會。