“程序員修煉之路 小說()”查找最新章節！
　和余信商量了一下，項目中不能一個女的都沒有，所以專門把吳傑調過來放到了自己的組裡。但她不負責編碼，負責驗收所有人的成果。也就是說葉奕凡的組實際上比其他的組少一個人，因為吳傑是共用的。

　這樣的話，三個組裡人員的分配，基本上很平衡的。

　分組之後，任務就很明顯了，各組承擔各組長設計的功能。

　做開發的時候，也有一個和做頁面相同的難點，就是怎麽通過代碼，使各自的功能，顯示相應的菜單項。

　這可比做頁面要麻煩的多，因為裡面含Java代碼，不僅僅是HTML了。

　葉奕凡在家裡又熬了兩個晚上，從框架的一個示例中，提取了使功能中顯示菜單項的辦法，寫了一個指導文件，一共分七步來做，就可以實際顯示菜單的功能。

　然後把這個指導文件發給所有員工，大家按這個指導各自配置去了。

　第二天早上一來，余信就很正經的和他說:“有兩個員工，按你的指導文件，沒有配置成功，如果有一個人，那是他的問題，但兩個人的話，要考慮一下指導是否寫的瑕疵了。”

　葉奕凡一聽，稍有點不相信，因為自己真是調試著代碼，一步一步寫的東西，不至於有問題，如果有問題的話，應該是所有人都弄不出來才對。

　於是又問了一下:“哪兩人個沒配出來?”

　余信一指:“他倆。”

　原來是二王，葉奕凡馬上心裡有數了:

　“我敢和你打賭，肯定不是指導文件的問題。”

　然後把安景和徐希田叫過來，吩咐道:“你們一人跟一個，看看他們為什麽沒弄出來。”

　過了半個多小時，兩人回復都弄好了。葉奕凡問道:“找到原因了嗎?”

　徐希田回答道:“其實就是沒嚴格按指導做，有時該大寫的不大寫，有時處理順序還前後不一樣。”

　把這個事兒告訴了余信，他也對兩人情況有所了解了。

　項目整體高速展開階段了，但做了兩周後，就很明顯出問題了。

　進度跟計劃差的越來越大，大家瘋狂加班，基本每天都到10點多，除了葉奕凡的組，進度還過的去，其他兩個不但趕不上進度，反而起來差的越大。

　和國方面有些急了，余信也急了。這個項目非常重要，以前的項目，大都是和國人為主，華夏這邊隻做其中的一部分。也就是說，萬一華夏這邊出問題了，和國人加加班就能給解決。

　而這回的項目，是一個新的開始，項目分後台和前台兩部分，和國人負責後台，華夏負責前台，如果前台這部分崩了，和國人是沒有任何辦法彌補的，項目就得砸。

　如果項目砸了，後果是很嚴重的，主要負責人輕則要被弄出部門，重則要離開公司。

　華夏這邊可能輕易不會讓人辭職，但和國那邊還真有可能。

　於是加班更嚴重了，最早也得11點走，到12點也是正常的事。

　項目的主要工作內容是，各組長前期在和國做的設計，算是外部設計，組員們先做內部設計，再編碼。內部設計是用一個叫UML的工具，畫的兩個圖，專業上叫類圖和時序圖。

　一個標準的機能，假設一共需要八天的話，那麽內部設計計劃用四天，編碼用四天。

　而實際上，編碼四天不夠的，正常應該六天才能做完。那為什麽要計劃成四天呢?

　原因就是當時有一個理論，UML的工具功能比較強大，用UML工具，畫完類圖之後，可以直接把類圖導進編碼工具中，這樣就會把編碼前期的框架直接生成，所以能夠減少兩天的時間。

　而現在的問題是，大家編碼能力都不錯，但UML多數人不熟悉，只有徐希田以前用過，相對水平高一些。所以很多人連UML做圖用4天，都不敢保證能做完，到編碼階段，設計也經常有變更，一邊編碼，一邊再去改UML，整個進度就一拖再拖。

　而且這種交叉工作，弄的大家心理上也疲憊不堪，士氣越來越差。

　這個系統，將來預定是葉奕凡和文連夏長期做維護的，也就是說，這是他以後的飯碗。

　如果項目失敗了，余信會受到很大牽連，葉奕凡不得不找其他飯碗，而其他人無所謂，再換個項目就可以了。所以為了自己的飯碗，也為了余信能立住，葉奕凡是必須讓這個項目成功的。

　他以前稍微接觸過UML，記得這個工具非常強大，可以把很多種語言的代碼導進去後，生成相應的各種圖。

　於是就找徐希田討論這個問題，正好他以前也這麽用過。葉奕凡就讓他演示一下，發現這個步驟簡直太簡單了，而且速度快，一個功能十來分鍾就可以把圖作出來。

　可能需要手工調整一下位置保證美觀，但半個小時也足夠了。

　半個小時，完成計劃中需要4天的工作量，這是多大的突破啊。於是在當天的項目會議上直接提出了自己的觀點，就是讓大家先做編碼，再反向生成兩個圖。

　沒想到的是，自己話音剛落，就被莫升否定了。“哪有先做編碼，後作內部設計的。”

　張瑞比較迷信莫升，基本上以他的意見為意見，看莫升反對也就跟著反對了。

　其他大多數員工，也反對，顧天明等少數人沒有說話。

　大家反對的理由，並不是說這樣做有什麽問題，而是最讓葉奕凡無法接受的理由:

　“以前沒見過這麽乾的。”

　有反對的，有沉默的，就是沒有讚成的，這個意見還沒討論就被否決了。

　余信始終沒有說話，葉奕凡知道他的處境，他是疑人不用，用人不疑，雖然他覺的葉奕凡說的話肯定會有道理，既然用了莫升做ITA，這方面的事，就得由莫升來拍板。

　這一下討論就進行不下去了， 事情暫時放置了起來。

　又過了幾天，葉奕凡偶然看到徐希田做完類圖之後，並沒有用類圖自動生成代碼的框架，而是在編碼工具上，重新把所有的元素手工輸入一遍。

　這一下不淡定了，馬上問徐希田:“你為啥不自動生成代碼，還要用手工輸入呢?”

　徐希田看著葉奕凡，想了想，露出一個苦笑的神情:“不習慣啊。”

　徐希田是這些人中，對UML最熟悉的，連他都不習慣，哪能指望別人能節省兩天的時間了，也就是說，每個功能兩天的時間，是結結實實的浪費了，就算往死裡加班，別說追趕進度，這兩天的時間都不一定能趕回來。

　換句話說，如果任其發展，什麽也不做的話，這個項目的失敗是必然的。為了方便下次閱讀，你可以點擊下方的"收藏"記錄本次(第112章 項目要失敗?)閱讀記錄，下次打開書架即可看到！

喜歡《程序員修煉之路》請向你的朋友(QQ、博客、微信等方式)推薦本書，謝謝您的支持！！()