大型web項目研發的反思
親愛的小夥伴們
不知道最近的技術分享有木有
讓大家收穫滿滿思考多多呢
但其實在實際的業務中
不僅僅需要技術的提高
好的團隊合作開發模式也會事半功倍~
◆◆◆
今天就請出我們部門
去年剛剛升級的超級奶爸
——『天奇爸爸』童鞋！
為大家帶來敏捷開發方面的「小心得」
近一年內我們經歷了兩次大型web項目的研發。20個前端,30個後端開發了4個月，10多個測試人員測試了兩個月，當然還沒包括這個企業級產品和周圍產品的聯調測試。前端項目裡面不包含庫文件有353個文件夾、1218個文件、276163行代碼。
兩次項目開發中歷經的重複、混亂、無序，讓人抓狂的同時，不得不讓我們開始思考軟體開發中的一些方法論。
讀了Martin大叔的博客和敏捷開發序言尤有感觸，列舉下來和大家一起反思。
持續發布
結合項目，個人認為持續地發布項目應該是持續地讓大家看到一個當前的軟體成果。看到成果後，團隊溝通項目進度、讓每個人意識到當前情況。主要有以下開發流程改進：
?持續發布、讓更多人知道項目進度、每個人更有全局意識、主人翁意識（痛點：每個人只知道自己的小模塊的進度，其他部分很少知情，協作能力比較差）
擁抱需求變更
我們平常開發的時候經常會聽到軟體開發人員吐槽需求又變了，甚至津津樂道程序員揮刀產品經理的新聞典故。在現今信息爆炸的社會，瀑布流的開發模式早已經步履維艱，擁抱變化、適應變化的敏捷開發模式才是正途。
?對產品的需求變更要做好心理和技術準備(痛點：項目里產品變更很令人討厭，多次的需求變更後，代碼一團糟、到處是補丁。我們要做好測試、不斷重構、接納和適應需求的頻繁變更)
業務和開發要協同工作
我們項目開發過程中，開發人員很多對業務不了解，甚至到後期對自己做的功能也不能說出個一二三四。
?更多的要求懂業務人員的進入，開發人員和業務人員頻繁溝通。不懂業務，怎麼可能寫出穩定、靈活、易於維護的代碼呢？自己寫代碼的時候，心裡都犯嘀咕，這樣可不行。
?項目初期關鍵開發人員參與需求討論環節，最終形成的PRD文檔需要產品宣講需求，使所有研發人員與產品理解一致。
信任每個人
敏捷開發里還有一個說法要面向人編程。在有些管理者的眼中，人就是一個螺絲釘、可以隨意替換（泰勒管理法）。但是，許多歷史和現在的事情告訴我們人的主觀能動性特別大。好的裝備到精神消極、渙散的人手裡和到鬥志昂揚的人手裡有天壤之別。
?尊重每個人的想法、激勵每個人發揮自己最大的主觀能動性。
?鼓勵團隊成員完成研發任務，獎懲相對存在。
簡潔為王
在物理研究歷史中，有很多複雜的理論來描述天體、宇宙，最後牛頓三大定律、愛因斯坦質能方程式這些簡潔的方案被證明才是正確的。數學之美中吳軍博士說過他在google的領導信奉：ak47理論，好的東西大多是簡潔的。
同樣我們的項目裡面，複雜的代碼、邏輯最後被證明充滿了bug、難以使用。
?我們寫代碼的時候，重構的時候，看到複雜的邏輯都需要三思，且選擇適合的重構方案，過度重構增加研發複雜度。
定期反思改進
項目開發中，每個人都埋頭寫代碼，到最後一溝通發現很多重複的地方不同人在重複實現。
?好的項目開發流程中，應該有一個人不停的了解每個人的進度、代碼。在每個開發者之間建立溝通，及早發現重複代碼、讓項目有機集合。項目開發中好的想法、方案及時溝通普及、開始執行。
?項目初期或過程中對整體系統熟知，提取出公共組件進行封裝使用。
綜述
實踐證明：寫好測試、頻繁重構、適應持續的需求變更是通向高質量軟體的必由之路。
很多公司的軟體開發歷程表明：缺乏測試、缺乏重構、抵觸變化的軟體最後都是一團糟，不得不完全重寫。
希望我們在開發過程中畫好測試->開發->重構的開發圓，提煉出越來越高質量的代碼、減少加班、提升代碼知識含量。
好啦，今天的分享就到這裡啦~
小夥伴們有任何小心得
也歡迎留言與我們討論互動喔！
◆◆◆
請大家持續關注我們的公眾號
我們會不斷地分享更多有趣的乾貨~
筆芯~
