提問回顧與個人總結

2022-11-24 18:51:11 字數 1340 閱讀 7431

專案

內容這個作業屬於哪個課程

班級連結

這個作業的要求在**

提問回顧與個人總結

以前提問題的部落格

個人部落格作業

我想知道部落格對於軟體開發人員的重要性很大嗎?哪些東西需要寫在部落格上呢?很多時候寫的部落格之後自己就不會看了,寫出來的部落格僅僅是給他人提供參考嗎?

通過個人專案、結對程式設計的部落格作業,我明白了寫部落格是一種很好的梳理整個工程思路的方式,例如用到了哪些技術、哪些關鍵實現**、以及學到了什麼新東西。通過長達2個月的團隊專案,這中間大大小小的二十幾篇部落格,對我們團隊有重要的指導意義,需求分析、技術文件能幫助開發人員有一個更清晰的思路,每日例會能清晰地反映團隊每個人的專案進度,起到了一個提醒督促的作用,而釋出宣告和事後分析則是對整個專案的覆盤和總結。

好記性不如爛筆頭,對於軟體工程師來講,部落格的作用是很重要的,寫部落格也應該成為一個長期的習慣。

如果兩人的**風格習慣有較大差異,例如程式模組的劃分、命名習慣差異等,還能保證較高的編碼效率嗎?

通過閱讀教材,我覺得在結對程式設計中,我們可以事先簡單約定一些規範,這樣在程式設計的時候就會減少一些矛盾衝突,提高程式設計效率。

如果開發人員審查後交給測試人員進行測試,會不會存在工作重複從而導致軟體開發效率變低的問題?開發人員和測試人員的測試任務劃分有沒有具體的原則和標準?

通過團隊專案,我發現這些測試工作並不是重複的,開發人員審查主要是從**本身的角度考慮的,在複審的過程中可以發現很多實現思路上的bug,而且也可能發現更好的實現方式,這些是測試測不出來的。而測試的話又分為很多種,白盒黑盒等,更多的是對實現的程式進行系統的測試。

在我之前的印象中,goto語句因為易導致程式的結構混亂所以不推薦使用,而且一般goto語句可以用其他迴圈語句來實現。因此這裡提到的可以使用goto讓我感到疑惑,而且我認為使用goto一般也很容易導致程式bug

通過上網查閱資料,我發現之前的想法太侷限了,goto不是不能用,而是要謹慎使用。在做好**風險管理的前提下,使用goto有時能使**更加靈活,所以只要理清**思路、做好複審工作,合適地使用goto是可取的。

當僱主、客戶、使用者和公眾之間存在利益衝突時,作為軟體工程師一般都會收到來自僱主方面的壓力,這個時候應該如何抉擇呢?

通過閱讀一些案例,我覺得應該首先考慮公眾的利益,僱主和客戶的利益最大化是在與公眾利益保持一致的前提下的。軟體工程師的行為都應該從自身規範起,從而延伸到行業、乃至社會和未來。這樣的工程師、這樣的職業從業者,才能成為一個對**構建世界有偉大貢獻,對社會進步有卓越奉獻的人。