2010-01-04 29 views
3

我的PHP代碼中使用的SQL數據庫的數據來自非程序員製作的excel文件。當我無法解釋我使用其excel文件時遇到的問題時,我通常會嘗試對其進行編碼。這導致我的一些漂亮的代碼。有沒有其他人有這方面的經驗?試圖對其他人進行編碼通常會更好嗎?還是堅定要求更強大的表格結構?與非程序員妥協

+0

您在此之前發佈此相同的主題在這裏:http://stackoverflow.com/questions/1996752/tips-for-communicating-with-non-programmers – dmckee 2010-01-04 00:42:16

+0

相同的主題,不同的問題。早些時候,我在談論有效的溝通。在這裏,我問的是當有人給我發送一張不理想的表格時,在哪裏畫線。 – Brian 2010-01-04 00:45:26

+1

他們完全一樣。每當你不畫線時,你的交流就非常強烈。 「這不會吸太多*太多了,給我更多的喜歡它」,現在你可以選擇你想努力工作以節省他們的努力了。 (對此並不持懷疑態度:有時候值得接納它們,有時候不是...... – dmckee 2010-01-04 00:53:29

回答

2

如果您決定要堅定並需要更健壯的表格結構,您需要爲非程序員提供清晰,簡潔,明確的文檔以及良好的錯誤報告工具,以便他們能夠更快速很容易弄清楚他們什麼時候發生了錯誤以及它是什麼。沒有什麼比讓別人向你大喊「你需要這樣做,或者程序不能工作」(甚至是說得很好但很堅定),然後三個月後不得不再次完成任務如果不回頭問程序員,就無法弄清楚標準是什麼。

因此,有時只是對不良數據進行編碼比較容易。它還有助於使您的程序更加靈活和強大。但是如果你開始向後彎腰去做,那麼確保非程序員檢查錯誤是否容易,而且信息是清晰明確的,並且有關於他們所期望的信息的良好文檔爲輸入。

1

你應該要求數據是正確的。不要對最終錯誤的東西進行編碼。

3

作爲一名SQL專業人員,我可以向你保證這是完全正常的。我經常不得不面對數據庫設計和查詢工作不佳的C#開發人員。哎呀 - 我不得不處理那些做得不好的SQL專業人員。 (並且可以承認過去也做得不好)。

我會盡量鼓勵學習和自我完善的文化。尋找重構的機會,並嘗試安排一個固定的時間(每月幾天)進行重構,假設你有適當的測試以確保功能實際上沒有改變。

4

這取決於,誰的時間更有價值?這並不像你想象的那麼直截了當。最後,這是一個商業決策,而不是技術問題。

如果你有10,000個用戶,用戶的時間可能更有價值,你應該儘可能地接受代碼,因爲這樣可以節省時間。

  • 如果您的應用程序是公開的,這是一個競爭優勢:是用戶友好的
  • 如果您的應用程序是內部的,這是成本控制:總擁有成本

如果你有5個用戶,他們是不是特別重要,繼續前進,任何你喜歡的需求,它會帶他們更少的時間在總體上解決他們的數據比它會爲你的代碼周圍的的問題。

如果你有1個用戶,而且是首席執行官,那麼你最好是適應,因爲他們的時間比你的更有價值。

+1

請記住,您對「不良」數據編碼得越多,您就越有可能引入錯誤,這最終會在一定程度上影響您的所有用戶。我認爲問題在於如何界定用戶友好型和自殺型之間的界限 也許可能需要手工編輯excel輸入,而不是編碼數據 - 在這些情況下手工工作經常被忽略。 – DaveC 2010-01-04 00:58:01

0

你們都可以同意一種標準格式,並且同意如果數據不是以這種標準格式(如果它符合格式,它不會被導入到db中)會發生什麼。

有多少用戶向您提供數據?驗證excel文件格式的工具是快速獲勝嗎?用戶可以驗證他們的文件,並在任何行或列不符合標準格式時通知他們。

0

到目前爲止,曾有一位客戶請我遵循一套結構,並向他解釋說,特別需要這種結構,因爲該程序已經設定了一些遵循的規則。 (畢竟他是從excel管理的CSV文件)。

圍繞它進行編碼只會成爲你的噩夢。只要同意像拉斯說的標準就可以了。

0

您應該提供一個清晰的規範或接口,並且只接受根據該規範的數據。

在某些excel模板的情況下,您應該儘可能地爲數據輸入端的人儘可能地做到這一點。這可能涉及鎖定行,爲定製GUI提供宏以便於輸入等。

您可能想要求一些比CSV更簡單的方法。

如果可以,您應該嘗試在導入到數據庫之前儘可能地驗證數據。

當然,解決這些問題並不是一個好主意 - 而且聽起來像浪費了寶貴的編碼時間。

順便說一句 - 這似乎是Tips for communicating with non programmers(儘管也許措辭有點不同)的一個騙局。

1

是的,你應該要求正確的數據。

但是......你可以幫助他們。創建一個工具來驗證他們可以使用的數據,然後才能找到您。