2009-09-14 29 views
15

我即將開始在一個新的項目上開展一個新項目,並且遇到了一些問題。他們不是MVC的大粉絲。令人信服的同事使用MVC

這讓我感到困擾的原因是,他們聲稱他們當前使用Zend框架時,他們真的沒有。他們幾乎不使用數據庫模型類,就是這樣。沒有MVC,沒有擴展Zend類來實現他們的目標。

我工作過的最後一個項目使用Zend非常沉重。項目完成後,我們剩下一個很好的MVC框架。非常乾淨的控制器,大部分重型邏輯都在它所屬的型號中,並且是一個很好的型號 - 網關係統。用手寫的SQL從sphagetti代碼開始,這有點令人震驚。

所以,我問你,StackOverflow社區。我如何說服我的同事轉向MVC框架?我感覺他們害怕使用MVC,因爲它意味着兩個既定程序員的學習曲線(這是一個小創業公司)。我一直在考慮在當前項目中使用MVC和所有Zend善良(在我自己的時間)做一個副本,並在幾周內向他們展示它們以瞭解他們的想法。

關於如何將同事轉換爲MVC的想法?

回答

16

有一個很好的帖子,你應該讀「他們沒有在學校教過的最重要的東西是什麼」。其中之一是社交技巧。它看起來像你在這裏落在你的臉上。

首先,你是團隊中的新手。你要告訴他們該做什麼或如何去做?如果你重寫代碼,如果情況更糟糕,你是個白癡。如果你成功了,你是一個屁股。無論哪種方式,你都是笑柄或出路。

你需要做的是解決以下問題:「我如何學會適應這個團隊,幫助項目取得成功並貢獻力量?」從這個角度來看,向其他人展示你比他們知道的更多,他們是白癡並不是解決方案。擴大你的視野 - 你的問題可能是10%技術,40%學習如何作爲一個團隊的一部分,30%的社會和20%的溝通。

從項目的角度來看,您認爲更重要的是什麼?你認爲按時完成項目會怎樣? a)所有人在錯誤的框架內高效和諧地工作。 b)團隊在一個框架內分成一個人,另外兩個人忽視他,每個人互相看起來對團隊經理/管理層都不利。

你已經說出了你的作品,現在閉嘴,做他們告訴你要做的工作,做得很好,做得很快,並且,如果你願意的話,儘可能多地將MVC放入(你的部分)只要你不告訴其他人如何編寫他們的代碼:)如果你非常好,你可以快速完成任務,然後讓他們做更多工作,然後重複上述步驟。

一旦你贏得了他們的尊重和理想的友誼,然後嘗試再次提出這個問題。

+3

我走過了「一次添加一個部分」的道路。我添加了一個模型 - 網關係統來取代手寫sql的實踐,並且他們真的對它發光了。我們會看看事情進展如何! – 2009-09-16 22:10:28

+0

好方法!這有助於「幫助這個項目取得成功和貢獻」的總體目標。 – 2009-09-17 13:53:43

+2

+1回答者,提問者+1不生氣的關於相當粗暴的批評,並實際上接受它。帽子掉了! – 2009-12-24 01:20:35

4

如果這是一個沒有技術人員的「小型創業公司」,那麼您很可能不會再從管理層那裏獲得更多時間來重做已完成的大部分工作。 「上市時間」是他們可能用作解釋的關鍵詞 - >「讓它首先快速工作」。

我也不喜歡它,但這可能是你的現實。

1

你可以嘗試瞭解他們的優先級。

如果他們想快速完成工作,框架存在的一個原因是要做大量的樣板工作,節省您不得不花費時間編寫的時間。

如果他們想要可維護的代碼,那麼以常規設計模式在常規結構中佈置代碼顯然是有益的。

如果他們想可驗證代碼(我不知道太多關於PHP可測試性)中是衆所周知的模式肯定擴展類帶來了更大的可測試性。

如果它只是無能當時的教育是唯一的答案(什麼更好的方式來做到這一點比使用一個精心設計的框架?)。

2

試圖說服他們使用你喜歡的模型不太可能奏效,最重要的是,他們很可能看不到你所做的同樣的好處。

小步驟效果最好。不要一天出去重寫2周的工作,你只會讓自己看起來像一個屁股。

相反,只要做到最好,同時與同事保持密切聯繫。除非他們遲早相信他們全部知道(在這種情況下,根本沒有希望),否則他們會在事情上詢問你的建議。只要解釋他們是如何的,更重要的是,爲什麼你會解決這個問題。

儘量不要將它看作是一知半解,而是始終準備參數。並且不要指望在幾個星期內成功。這需要時間,但如果你的同事值得他們工作,他們最終會從中獲益。

當然,如果他們有反對使用任何模型或MVC的非常具體的論點,你將不得不尊重這種觀點。

0

基本上,你想要做的是在你的工作環境中引入一個相當深刻的變化。即使對於具有優秀社交技能的人來說,這也是一件非常困難的事情。你必須在很長一段時間內採取小步驟,敏銳地意識到自我,說服人們,並最終兌現你的承諾,即改變將會變得更好。

不久前我聽到一個相當不錯的播客/採訪這個話題:link。那裏有很多有用的信息。最令人震驚的是,很多人根本就不喜歡改變,也不會去做。你必須讓他們成爲流程的一部分,並讓他們投資。

3

這是「你永遠不應該做的事情」之一。

http://www.joelonsoftware.com/articles/fog0000000069.html

正在向MVC資源的最佳使用權呢?

你無法將自己的時間計爲「免費」,因爲這是作弊。如果所有事情都是在你自己的時間完成,你可以在任何時間做任何事情 - 重寫它RoR,寫入Lisp等。

所以,假設它需要你花費N個小時。你是否還在迴歸測試所需的時間內添加了它以確保它完美地工作?沒有?然後再添加2N小時。如何讓其他開發人員熟悉新代碼?沒有?然後再添加2N小時。

所以,現在我們可能長達5N小時。在下一次發貨日期之前需要完成哪些其他的事情?你還可以適應這些額外的5N小時,仍然可以做到這個日期嗎?如果是這樣,之後的發貨日期是什麼?可以在5N小時內完成的項目是否比在MVC中重寫更有價值?

重寫的時間和維護方面的好處是什麼?

您可能沒有從項目管理的角度考慮這一點。從這個角度來看,我個人懷疑重寫是對你的時間的最佳利用。

0

你可能無法說服他們,但你有權發表你的意見 - 畢竟你是團隊的一員。無論你是否新手都無關緊要。

相關問題