從來到新公司那一天起，我就知道這不是一個輕松的差事，將充滿未知的挑戰，將承受來自各方的壓力，將面臨和經歷各種各樣的挫敗感，但是沒想到來的這么迅速和猝不及防。

昨天接到技術大佬的指示，要兄弟們在設計、實現各自模塊功能的同時，注意代碼的健壯性，并考慮到異常狀況的相關應對預案，同時在寫代碼的時候，注意DFX，這無疑給我提出了一個及其高標準的要求，作為一個從未接觸過項目管理，從未涉足軟件行業，甚至從未寫過正式完整代碼的新人，我第一反應是崩潰的，那感覺就像是讓一個初中生去做高考試題，完全是看天書的感覺，在這種情況下，可能的結果有兩種：1. 交白卷，承認自己在這方面還是一個小白，這么艱巨的任務實在沒有頭緒，無法完成，我就希望自己可以安安心心的寫代碼，那么可想而知，我在大佬心中的得分也必定是零分，以后在高層領導心中我就是一枚棄子，我的價值和那些大學實習生沒有任何差別，隨時可以被fire掉；2. 信手涂鴉，按照自己對于項目管理的意淫，按照自己的“天真無邪”的設想把握整個項目的進展，按照自己對于技術大佬思想的理解，采用撞大運的方式行動，腳踩西瓜皮，滑到哪里算哪里，亦然可想而知，這樣還是零分，就像在高考試卷上寫下了一對小學應用題的答案，肯定幼稚可笑至極，在高層領導的心中，我的水平也基本被定性為與大學實習生相同。

那么有沒有第三選擇?

任何事物都具有兩面性，甚至多面性，大佬布置這樣明知我無法勝任的任務，原因可能有二：1.考察，試探我的能力，看看我究竟能交出怎樣的答卷，是優良中差的哪一檔；2.形勢緊迫，實在沒有多余的人手可以安排，只能讓我趕鴨子上架了，那么如果我做的好的話，應該有機會得到更多的重視和機會。

那么有應該怎么做？從大佬的意思來看，他的核心目標是保證產品的質量，即希望我們交付給用戶的產品可以穩定的運行，不至于像一臺破自行車一樣，除了車鈴不響以外哪里都叮當作響，而且還不能上路，這樣的產品是不會得到客戶的認可的，自然也無法為公司賺得利潤。

目的知道了，那么圍繞這個目的我應該怎么做？從目前現有的情況分析，1. 大家現有的代碼還停留在功能開發的層面，對于代碼的可靠性，健壯性還沒有最基本的考慮，對這方面工作的重要性還沒有足夠的，應有的重視，甚至最基本的意識都沒有。2. 大家編寫的代碼還沒有統一的規范，代碼的可讀性弱，可維護差。3. 沒有項目文檔，各個模塊的功能在不斷的調整和增加，大家對于彼此負責模塊并沒有足夠的了解和把握。4. 對于一些校驗性的工作，前端和后端的和合作不夠充分，哪些前端做了驗證后端就不用校驗，哪些前端做了驗證后端還需要檢驗大家并沒有形成統一的意見。5. 對于代碼的可能遇到的異常情況還沒有考慮。

可以做的事情是什么。核心思想：1. 以時間換取空間，能拖一周，我就有一周的學習機會來汲取更多的知識應對大佬的拷問，所以只要每一周都比上一周有進步，我就贏了。2.先發致人，積極主動，主動把自己的想法發給大佬，主動把自己的進展發給大佬，讓大佬看得見你在積極的做這個事情，同時在放低姿態積極的尋求大佬的指教，讓他看到你的態度，你的改變，你的結果。

那么第一周的時間，具體的行動，有什么做法呢。

1. 同一公司內部的編碼規范：利用兩周的時間，每天早會給大家講解一個java語言的編碼規范，讓大家按照編碼規范來修改自己的代碼，在修改代碼的同時完成技術文檔的創作，技術文檔的格式我會先寫一個標準，然后大家統一在這個格式下書寫。

2. 每周六有兩個小時的代碼review時間，在這兩個小時中，會有1到2個組員介紹自己每個方法的思路，組員內部采用一對一的相互找錯的方式， 表格如下：方法名，問題點，發現日期，如何修改，修改日期，每個人每周必須找到對方3個-5個問題點。

而我自己將訪一訪技術大牛，讓他們給我提點意見，好讓自己可以在下一周乃至年后可以拿出更加切實可行的方案。