對開發過程中文件的一些想法

2021-06-09 16:51:08 字數 1621 閱讀 2053

做軟體開發也已經有6個年頭了,最近總結了一下,針對文件這件事情,還真是有一些想法。不知道是不是對,只是自己看到的情況基本上就是這樣。

1、要不要文件的爭論

呆過兩家公司,兩個極端。

a公司的文件及其詳盡和完整,而且能始終保持更新。好吧,基本上就是cmmi4的程度。

這樣確實有好處:

·專案的整個階段都是受控的,基本上偏差不大,一旦出了問題之後,也能很容易回溯到最初出現問題的點上;

·新人進來之後的上手速度相對也快,按部就班跟著各階段的文件前進就可以;

·軟體質量是有保障的,每個階段都很好地執行pdca的過程,都有記錄都有認可;

·還有兩個很重要的好處:一是能讓人站在更高的角度來看軟體開發,至少是可以跳出某一特定階段(比如做概要設計文件時就要通盤考慮需求、技術、溝通等),可以更全面的思考整個專案;二是怎樣把事情說清楚又不冗餘的能力,個人覺得軟體開發中,這個能力很重要

b公司呢基本上就是沒有文件,所有的東西都在**裡面。一開始也覺得匪夷所思,但是時間長了思考一下,發現這也是沒有辦法的事情:跟這個行業相關。b公司的專案是產品主導的,並且競爭極其慘烈,時間就意味著生存,這種情況下迫使所有人放棄所謂正規的開發流程,全力突擊,文件自然是被捨棄的。比如5天就要做出一款產品,你試試。。。。

所以,要不要文件不是靠書本知識甚至是經驗就能判斷的,很多時候還有很多的限制條件。個人覺得認真負責的軟體開發人員特別是管理人員,應該綜合考慮行業、經驗、團隊特性等裁量出合適的文件管理方法和流程。

2、對於文件的態度

這個東西說起來其實很主觀,每個人都有自己的想法。個人覺得,其實很多人都是沒有能夠跳出乙個既定的思維,而這個既定的思維是你呆過的對你影響最大的專案組給你的。

具體說,我先在a公司做了4+年,這中間一直處於嚴苛的文件管理體系中,一直是這樣在做的。所以,當離開a公司的時候覺得一切就應該是這樣的,理所當然。進入b公司之後也想著用這樣的方法去做,並試圖影響別人。但慢慢的終於發現,這是不可能的。對b公司來說,現有的狀態才是最合適的,其他都是格格不入的。

這個時候該怎麼辦?我自己的看法:還是要裁量出最適合自己的方式,也就是調整自己的態度。在a公司形成的那些好習慣不能丟掉:比如詳細筆記、先思考後操作、每天做計畫和檢查等等,這些還是可以實施的;但同時又要適應b公司的方式,習慣沒有文件直接寫**(確實也提高了快速編碼實現的能力)

相反:假設我要是先在b公司做了4+年再去a公司呢?個人覺得這種情況會更難適應一些,畢竟人的惰性很能克服。原來在a公司的時候也確實有這樣的同事。所以,大家還是要養成良好的習慣啊。

要有時刻挑戰自己習慣並不斷裁量的良好心態。

3、不僅僅是文件的問題

文件的問題,歸根結底是開發流程和規範的問題。

良好且完整的開發流程,當然會對文件提出一定的要求,文件是不可或缺的,相差異的僅僅只是文件的覆蓋度、精細度和規範程度而已。

個人覺得,就算是像b公司這樣的情況,也應該要由一些文件支撐,特別是軟體框架設計相關的東西。是不是可以在專案完結的時候,專案組用總結會的方式整理一些文件呢?或者對coding環節的要求更加嚴格一些,比如**規範、比如注釋規範,借助doxygen等工具,生成**說明性文件,這樣對今後維護、新人介入等等都是有幫助的。

好吧,亂七八糟說了一堆,總結起來就是一句:文件是需要的,但是需要根據實際環境進行相應裁量,同時,作為軟體開發人員來說需要不斷克服惰性、多思考,確定文件跟自己工作的關係。

開發過程中用到的一些知識

在後台給前台控制項賦值16進製制的顏色 控制項名.background new solidcolorbrush color colorconverter.convertfromstring ff54c0dc wpf監控方法 timer timer timer new system.threading...

ionic開發過程中遇到的一些坑!

總結一些 在使用 ionic 開發過程中所遇到的問題。描述 使用 ionic start 專案的時候,專案安裝成功,但是在專案裡面跑 ionic serve 的時候就會報錯 這個問題可以參考 解決這個問題之前,我好想裝乙個 npm install express 不知道是不是要先裝這個 安裝好之後是...

軟體在開發過程中一些問題

軟體產品不同於其他的產品,軟甲開發幾乎就是純智力的一種行為,智力行為又是思想行為,往往會帶有很強的主觀意願。但是同時也會有一些相應的規範來約束。即使在開發過程中遵守規範,但是還是會遇到一些問題 軟體開發進度和成本難以控制。由於評估軟體的開發是基於以前的經驗和統計數值,因而專案的進度和成本難以控制,這...