最近幾天一直在思考一個這樣的問題，怎么樣才能讓制造工作快速高效的完成，并盡可能減少bug的存在。初始想法是源于自己的這次失敗，并不簡單的是失誤。一大片的進度延遲是誰也不想看到的，但也不是任何人都能在規定的時間能完成，這和個人的經驗以及熟悉程度相關。其中必然有某種關聯，我能想到的有下面幾個方面：

1、進度上

進度上的超前安排是必須的，畢竟一個項目有其規定的納期，只有為各種難于預測的障礙提供足夠的時間緩沖才能保證時間上的可行性。同樣，在納期內的合理調度也是我目前難以把握的，因此這一方面我無法提出合理的建議。

不過我倒是有一個大膽的提議，那就是由APP的實施者自己提供最遲的完成時間，綜合各方面的可能性提出的自我完成時間，想必是比較合理的，因為只有自己最清楚自己可能在哪里花費更多的時間。當給出一個壓縮過的時間之后再由實施者自己提供的時間必然也是壓縮過的，但這是必要的，因為他會感覺到壓力的存在，并在可接受的壓力范圍內作出調整。

來自外界的壓縮過的時間，特別是感覺到難以實現時，會讓人不自覺的產生一種來自心理上的抵觸。可能表現的并不明顯，但不可否認這是存在的。而自己給出的時間盡管也是壓縮過的，但因為是自己的預估，這種壓力更多的體現在盡力完成上。

上面的想法好像過于放松，畢竟這是理想狀態下的，難以顧全到大局，可行性也不曾得到驗證，只能作為一種參考。可行性分析還要靠各位把握、分析的結果請告知，以便我了解自己的想法和事實的差距。

2、管理上

我們提倡輕松愉快的工作環境，這個環境的造就和維護就靠各位管理人員。誠然，自由的工作環境更能培養出具有創造性的思維，這是項目中不可多得的機會。融洽的相處和定期的一對一交流更能把握好這個節奏。

一對一的交流會讓人有一種不曾被忽視的感覺，這對于員工的存在感有很大幫助。當一個人有強烈的存在感時會有更強烈的自信的表現，盡管可能我對此并不熟悉，甚至錯誤百出，但這絲毫不影響其熱情。

而項目的進展和個人的發展顯然是最好的聊天話題。不要認為小兵就不關心項目，每個人都對自己的工作存在一種特殊的情感，這種情感在被得知對整個大局具有一定的完善和推動作用時表現的尤為突出，這將形成一個自信心的良性循環。而個人的發展更是每個人都關心的重要方向（不排除有人不關心），目標管理也是一個很好的載體，但畢竟沒有面對面交流來的真切。幫助員工分析其期望的發展以及可以提供的機會更容易拉近彼此的距離，產生師生活朋友般的交流效果。越是有經驗的leader越能把握好這個度，不然很可能經過一席談話，“送”走一位您想挽留的人。

公司的發展方向決定了部門的發展趨勢，部門的發展趨勢決定了部門內部員工的發展，當二者出現重大沖突的時候謊言顯然是出不可取的，因為這降低的將不僅僅是對公司的認可，更可能是對管理者的抵觸。個人的發展是多方面的，也是多途徑的，或與與其最終的結果不同，但方向可能并無太大偏差。而如果絲毫沒有相同之處的話也需要給予充分的指點，我想這是作為一個領導者的職責。

而管理上的具體的實施，恐怕也只能是我的一種猜想，畢竟我不是管理者，雖然我期望早日成為。和進度上的安排的認識一樣，不論這樣的認知是否可行，還請給予指正，畢竟這也是管理者的職責之一：關注每一個員工的思想動態。

3、自己

員工個人的做法才能真正決定項目的進度，畢竟通常情況下管理者是負責協調，而不是實施。員工的個人行為可能決定了項目組的環境，當然這一切還是可控制的。

終于說到自己更為熟悉的部分了。我先說一下我自己的做法，再說自己的拙見。

（1）、拿到式樣書時

最初拿到式樣書的是我我習慣性的會通篇看一下，以判斷工作量的大小。個人感覺工作量的大小并不取決于代碼行的多少，更多的是依賴于業務的復雜性，上百行的賦值和比較并不比十數行的check復雜。個人感覺上是：通常情況下的單純的刪除操作時最為簡單的、其次是單純的功能增加或完善（例如添加CSV輸出或者在其中增加幾行界面上以存在數據）、業務的修改和完善則相比會更復雜一些（即便只是增加不多的功能也需要盡可能的完整了解此業務）、新規的部分則由業務的復雜度、明確程度、使用范圍來決定其工作量大小

（2）、式樣理解

也就是業務軸review，很容易被忽略的一個環節，同時也很難把握，能把過程說的很清楚明白的并不多，除非是在完成此本APP之后。不同經驗的SL把握的情況也不盡相同，時間和經驗的限制致使我們無法充分進行此部分的review。個人感覺大的方面可以把握為：邏輯上的變化、畫面上的變化、數據的變化。

邏輯上的變化一般來說是比較少的，如果有的話想必就是一本比較大且復雜的了。如果是邏輯上的變化，那么此本APP還是建議全部理解為妙，不然倉促下手會造成極大的返工，理解的細致程度還由個人把握，建議的標準時能畫出數據流圖。

畫面上的變化一般是顯示內容的增刪改，增和刪只要小心一些一般不會造成太大失誤，而修改的話可能會帶來界面布局和部分空間屬性的變化，稍加注意也不會有太大問題。

數據的變化主要關注一下修正部分的數據以及PL/SQL文是否變更即可。

（3）、是否存在技術上的難點

上面的式樣理解是拋開了技術問題的。畢竟這是強制性的變化，式樣理解和實現是有一定的差距的，技術上的難點也是相對于陌生的操作和可能出現的邏輯性代碼。此時不見得能或需要解決，只是做到心中有數，以決定后續需要花費多少時間來解決。

（4）、代碼制造

刪除項目是比較簡單的，在確保沒有其他變更的情況下注釋掉實現此功能的代碼，并解決由此產生的錯誤。我們可以直接注釋是因為強大的開發工具會進行自檢，需要注意的是：是否有其他操作（數據庫訪問、文件輸出）使用到刪除的數據，并確保已經按照式樣書處理。

增加功能則不太好描述了，視增加的內容不同而不同。簡單的增加數據項和check處理則相對簡單一些，只需要按照式樣書的要求進行，一般不會出現過于嚴重的bug。業務上的添加可能就相對復雜，不過上面已經畫過數據流圖了，了解數據的走向之后應該會變得輕松一些。

關于這一部分是很難把握的。因為技術上的難點和理解上的誤區在此變得無處遁形，他可能是你原地踏步或者兜圈子。技術上的難點在明白需要知道真正該問的是什么之后倒也不是太難解決，如果是理解上的誤區可能會花費更多的時間，雖然我們提倡不會就要問，但是很多時間也會出現不知道該問什么的情況。

制造期間的任何不曾被注意到的問題都可能成為一個巨大的問題，因為他阻礙了程序的正常運行。于是這一階段會比預期看上去漫長和進展緩慢的多。我很贊成為每一個曾經出現的出人意料的問題建立一個資料庫，以便其他人遇到同類問題時能迅速解決，不過問題的種類是那樣的繁多，完善的問題庫可能像MSDN一樣龐大，而且需要花費的時間也非我們能夠承受。我們只好慢慢成為“見過類似問題、做過類似問題”的經驗者。

這一階段就是成為經驗者的必經之路，小心謹慎、遭遇問題、試圖解決、尋求幫助。看起來很簡單，做起來真頭疼。

（5）、自己review

這一部分的重要性也是不言自明的。合理的安排是：自己測試同制造有相同的時間，不過這點事很難做到的。我們總是盲目相信自己的成果物，以至于絕大部分的問題都是別人發現的，不容易產生遺漏的做法是：復制出來一本式樣書，一點一點的對應下去，并改變對應過的背景顏色，就像測試一樣，不過相對簡陋的多，這樣至少保證不會出現顯而易見的錯誤。這樣可能會出現很多測試不到的地方，畢竟你并沒有對式樣進行深入的分析，只要這個點不是變更內容，十有八九是可以無視的，新規制造不在此列。

（6）、差分

這真的是一個不錯的辦法，除了花費一定的時間，但是這對于小小的錯誤是很好的自檢辦法。畢竟你我都不希望僅僅因為一個被忽略的小錯誤而多出一張障礙票。

似乎沒有足夠的時間很難保證質量地完成上面的一系列操作，這點我也贊同。只是這個很必要，也會在之后減少不必要的返工。

End?Sub

回看上面所言，似乎有些籠統，但是這個對我來說真的很難表述清楚，或者說要表述清楚的話需要重寫幾本類似于《需求分析》、《可行性分析》、《Thinking?in?Java》的書了。目前沒有如此想法，各位都是從開發者中來，希望以上所言能起到拋磚引玉的作用，我們都想把項目做好，雖然我們的能力著實有限。若是各位老大能夠總結某些經驗并實施，相信會有好的作用的。

轉載于:https://www.cnblogs.com/jzzlo/archive/2012/03/21/2409115.html

總結

以上是生活随笔為你收集整理的提高代码改造过程的小想法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。