你如何讓人們在不將項目暴露給整個代碼庫的情況下工作？

我是OnePage的聯合創始人兼首席技術官（http://myOnePage.com/joel）。你如何讓人們在不將項目暴露給整個代碼庫的情況下工作？

我很想聽聽大家的意見，並回答這方面的問題：

我敢肯定的Yahoo!或Google不會將他們的整個代碼暴露給他們的開發人員！我只是想知道你用什麼方法來限制人們看到完整的代碼？在所有項目中，顯然都會包含代碼的一部分，其中包含數據庫和API密鑰的重要訪問憑據。

謝謝

2009-09-12 joelg

A）。我會把錢放在谷歌上，暴露一個*解決方案*的全部代碼庫給他們的任何開發人員以及B）。你需要證明爲什麼這是一個真正的問題。從我的POV來看，如果你限制了我在軟件上的工作能力，你會發現我並沒有爲你工作很長時間。 – annakata 2009-09-12 14:26:49

非常有趣！我對這個問題的反應印象深刻。我當然不是在試圖讓人們失望，我同意這可能是結果。我認爲信任是關鍵。非常感謝回覆！ – joelg 2009-09-12 14:33:21

不使開發人員能夠訪問的代碼一定會證明適得其反在長期的。這將限制他們在增加新功能方面的生產力/有效性。所以恕我直言，重新考慮這一點。最好僱用你信任的人，讓他們訪問代碼，而不是限制它。其次，你想限制什麼程序代碼行或數據庫的細節，登錄憑證等？登錄到db的債權通常駐留在屬性文件中。您可以加密屬性文件的內容並混淆讀取屬性文件並對其進行解密的代碼。爲了確保程序員不理解代碼，可以混淆你的代碼庫。但混淆帶着自己的包袱。

底線：你正在試圖解決在restrcting錯誤的問題開發人員訪問代碼庫

來源

2009-09-12 14:21:35 Cshah

我完全同意，信任是關鍵。我正在重新思考一下，這是我原來的看法，但如果我們讓人們成爲實習生，我們不希望給他們充分的機會，這似乎是公平的。我堅信，這不是確定的代碼或想法，而是執行。儘管如此，爲了在團隊中實現最大程度的靈活性，我們希望避免長時間的招聘流程，如果我們確定某個人很好，我們希望儘快讓他們加入。感謝您的迴應，我一定會考慮通過的選項。這只是憑證，所以這可能是一種選擇，但我同意不理想。 – joelg 2009-09-12 14:31:40

他們將需要在某個階段看到所有的代碼。用於調試/分析等。根據您使用的技術，您可能無法隱藏它。他們可以反編譯包（例如Java可以讓你這樣做）。

此外，它發送錯誤的消息，說某些人不能看到代碼庫的位（除非你真的在代碼中有開創性的東西？）。

如果您想從安全性的POV維護一些保密性，那麼憑證等應該是可配置的。開發人員可以獲得開發/測試環境等的憑證信息（例如開發數據庫）。

部署到生產線時，您的第一線支持人員（或任何受信任的人員）應提供此信息，因此您的開發團隊將無法訪問該信息。

來源

2009-09-12 14:01:02

這是我面對Brian的問題。每個開發人員都有本地設置，但除此之外，我正努力實現最大程度的自動化，實現持續部署的目標（timothyfitz.wordpress.com/2009/02/10/continuous-deployment-at-imvu-doing-the-不可能五十次-A-天/）。我同意這是一個不好的信息發送出去，但我覺得最好的方法是逐漸給人更多的訪問權限。我想要最大的靈活性和靈活的方法來避免浪費時間進行檢查，因此需要能夠快速獲得人員編碼，同時保持控制權，以防發生某些事情。 – joelg 2009-09-12 14:23:39

我不認爲這會影響敏捷性。我希望開發人員能夠輕鬆地進行測試，然後生產，並且只需要生產支持（或者任何人）向屬性文件提供生產憑證。在我工作的一些環境中，部署之間簡單地保持原狀，單獨重新部署代碼。 – 2009-09-12 14:48:51

我認爲阻止訪問整個系統的最好方法是創建一個系統，讓你有一個非常寬鬆的連接。這意味着您可以將創建serviceX的任務分配給開發人員，並且此開發人員只需實施「穩定」版本的ServiceX ...

給他確切的要求，他必須實現的界面和一組的codecontracts，你是「完成」...

現在你只需要執行他的代碼到你的系統，並希望它不會炸燬。

我不明白的唯一部分是爲什麼應該有代碼訪問憑據等？那些屬於配置;）

來源

2009-09-12 14:09:44

謝謝Heiko。鬆散耦合絕對是我認同的方式。我們確實擁有配置文件中的憑證，但現在在存儲庫中。你是說這應該離開倉庫嗎？我正在努力實現全自動化。 – joelg 2009-09-12 14:25:26

我同意上面的Jeff;）獲得您可信任的開發人員......或者給他們任務提供明確的界限。我也會有不同的發展，階段和生產憑證套 – 2009-09-12 14:30:10

我同意。理論上擁有不同的證書組是非常好的，但它是否會在部署中引入一些必需的手動工作？ – joelg 2009-09-12 14:37:08

我認爲真正的解決方案是聘請你信任的開發者，併爲他們提供他們所需要的東西。如果你覺得你必須從員工那裏隱瞞事情，那麼存在一個大問題。這就是說，你可以把事情分解成單獨的模塊，然後把每個模塊放在不同的存儲庫中，並且只允許每個開發者訪問你想要的存儲庫。

來源

2009-09-12 14:10:41

我完全同意你的傑夫。我已經擁有了我信任的開發人員，我很高興他們能夠訪問所有內容。這個問題出現在我想讓一個人成爲實習生或者他們開發一些東西並評估他們的時期。此外，您是否認爲所有Google員工都可以訪問PageRank算法？並不是說我們在這裏有什麼突破性的，就是最好的例子。 – joelg 2009-09-12 14:21:02

通過顛覆，您可以設置ACL和組。檢查：

Authorization Options在svnbook
Access Control for Subversion with Apache2 and Authz
等

來源

2009-09-12 14:15:59

這聽起來很有希望的帕斯卡。如果可能，那很好，但問題是開發人員需要限制訪問權限，但仍需要能夠測試他們的代碼。這種情況下的解決方案是什麼？ – joelg 2009-09-12 14:27:19

嗯，我不是說我會這樣做，我不知道你的上下文中有什麼可能，但也許你可以分發代碼的二進制版本，或者只是混淆一些部分，或者提供一個存根用於測試目的， ......無論如何，你必須信任別人:) – 2009-09-12 14:43:25

提供外部開發者提供組裝或某些種類的API。

我曾經寫了支持使用第三方模塊博客應用程序。我提供了一個抽象類和一個供程序員實現的接口。如果我需要公開如用戶對象的核心對象，我會縮小它 - 基本上提供只讀對象，我會再擴大使用的「另一面」。

來源

2009-09-12 14:31:45 roosteronacid

這絕對是一個不錯的選擇。我猜如果一個API被開發出來，那麼我們可以讓人們在基於API的應用程序上工作，而不必將它們暴露給核心代碼。謝謝 – joelg 2009-09-12 14:34:51

這是有道理的，以限制訪問某些生產憑據只有那些誰管理的生產環境中的人（假設你確實有專門的人來做這個）。

然而，在一個創業公司像你這沒有意義隱藏/從開發人員混淆實際的源代碼的部分。這似乎是官僚主義和不必要的，它只是向開發者發出一個信息，他們不能被信任或不夠重要，無法看到整個事情。它也可以導致保密文化而不是透明度 - 這些價值是你想在你的公司培養的嗎？

據我瞭解谷歌的，他們是與公司內部的源代碼相當開放。他們的算法也不是一個很大的祕密， Google定期發佈討論其技術的學術論文。

來源

2009-09-12 14:36:23

嗨，肯。不要誤會我的意思，我是一個開放性的大力支持者，這就是我們現在所處的階段。僱傭開發人員不一定是這樣，關心的是讓實習生幫忙，而不一定留在我們這裏。大學或學校裏那些在暑假有空閒時間但不會完全必要的人，我們甚至不希望他們，因爲我們想鼓勵進一步的教育。對這裏的迴應非常滿意，我開始認爲開放肯定是更好的選擇。謝謝！ – joelg 2009-09-12 14:42:36

根據我的經驗，將實習生視爲潛在員工並像其他開發人員一樣對待他們很好。如果他們喜歡和你一起工作並且很好，那麼他們會在畢業後爲你工作。您可以（也應該）讓他們簽署新發布協議，以防止他們離開後泄露任何專有信息。 – 2009-09-12 14:51:00

隱藏的源代碼是不是解決最困難的問題。例如，您可以將其拆分到不同的存儲庫中，並在其上放置不同的密碼。然後將編譯後的代碼（例如jar文件）分發給需要它的團隊。或者將代碼的功能暴露爲web-api以避免反編譯威脅（如google-graphs）

但是，IMO真正的挑戰是如何讓開發人員在使用存在於您的代碼中時組織和他們無法訪問的源代碼。

所以，如果你寫一些代碼，你希望你的開發人員能夠重複使用代碼，而無需訪問源。在這種情況下，重要的是代碼必須有一個非常乾淨的API，並且應該有很好的文檔記錄。通常在企業環境中，訪問源代碼可以代替文檔。

最後你揭露隱藏代碼的功能的方法取決於你的部署環境。例如，部署在服務器集羣上的Web應用程序可能會被分解爲Web服務。

來源

2009-09-12 14:38:56 idrosid

這正是我所掌握的，我似乎讓每個人都認爲我不相信任何人！我們沒有使用Java，但我確定可以使用類似的方法。我同意一個乾淨的API是答案，這就是我們正在努力的方向。我認爲限制代碼可能需要等到我們可以在API之上構建，而不是限制對核心API代碼部分的訪問。非常感謝！ – joelg 2009-09-12 14:46:20

我會說這是一個模塊化系統很差，需要開發者看到一切爲了做任何。

這個問題的一個非常類似的方面是學習曲線問題。如果你有一個大的系統，你想新員工能夠在系統的一些地區生產，而不必瞭解每一位的細節。

我工作的一個項目，我和我的搭檔劃分代碼到用戶界面和通信內部。（這個項目是一個設備集成模擬器，我們的代碼模擬了客戶端和設備。）他爲我的內部提供了一個模擬DLL，在我們整合這兩個之前，我寫了近95％的UI。我從來沒有看到他的任何代碼。

來源

2009-09-12 17:02:06 PaulMcG

嘿，讓我們不要太硬對貧困喬爾！我不喜歡比下一個人受到更多的阻礙，當我預計我會趕時間解決某些問題但沒有得到適當的授權時，我會遇到一些挫折。另一方面，「僱用你可以信任的人，然後你不必擔心內部安全」，說起來容易做起來難。你如何確保所有新員工都值得信賴？在面試中你打算怎麼做，問他們是不是小偷？你真的希望盜賊承認它嗎？這隻需要一個不誠實的人竊取幾百萬美元並消失摧毀一家公司。甚至有一個善意但無能的人擁有存儲備份的房間的鑰匙，以決定所有存放在未使用的壁櫥中的磁盤都應該被回收。我當然不希望我的銀行或持有我401k的人將授權分發給他們僱用的每個新人，以便能夠進入我的賬戶並無限制地操縱數據。

來源

2009-09-17 16:54:47 Jay

謝謝Jay！我認爲有些人錯過了這個觀點，也許這就是我說過的話。當然，說起來容易做起來難，但我肯定同意人們的看法，認爲公開會更有價值。我的解決方案將是開發一個API，它暴露了我希望開發人員使用的功能。 – joelg 2009-09-18 11:06:17

雖然我還沒有在公版的這個工作，我一直在一對夫婦那裏有圍繞着如何瓜分代碼爲不同的組件結構的工作環境。讓我來描述一些可能有所幫助的示例：

ASP/COM設置：在一家公司中，網頁上有ASP代碼的VBScript，用C++編寫的對象模型與Oracle後端對話。只有一些開發人員可以改變對象模型，這限制了我們可以做的一些事情，但也提供了一種方法來區分誰爲每個人做了什麼和不同的技能。前端開發人員有一些腳本來拉入二進制文件，除API之外通常不關心事情是如何完成的。

後端/前端設置：在另一家公司有後端平臺，有自己的名稱和一些開發商奏效。一些其他開發人員在前端工作，通過使用.Net遠程對象執行各種功能的API進行連接。這有好的和壞的時刻，因爲有些時候前端需要對後端進行新的調用，我們不得不等待這些調用的實施。

希望這在某種程度上是有用的。 A）

來源

2009-09-17 17:37:09

謝謝，這很有用！我認爲我的解決方案將更接近第二個例子 - 開發API並允許開發人員使用它。 – joelg 2009-09-18 11:07:52

你如何讓人們在不將項目暴露給整個代碼庫的情況下工作？

回答

相關問題