0
如果你的團隊來了一個新隊員，有一臺全新的機器，你們是否有一個文檔，只要設置了相應的權限，她就可以根據文檔，從頭開始搭建環境，
并成功地把最新、最穩定版本的軟件編譯出來，并運行必要的單元測試？（在這過程中，不需要和老隊員做任何交流）
答：我們團隊使用的是github進行源代碼管理，使用Android Studio進行開發，由于做的是App，只需要搭建起android開發環境，安裝并配置好
android studio即 可，我們有一個文件用于這方面的開展。
1
你的團隊的源代碼控制在哪里？用的是什么系統？如何處理文件的鎖定問題？
場景： 程序員果凍正在對幾個文件進行修改，實現一個大的功能， 這時候，程序員小飛也要改其中一個文件，快速修復一個問題。怎么辦？
一個代碼文件被簽出 (check out) 之后，另一個團隊成員可以簽出這個文件，并修改，然后簽入么？有幾種設計，各有什么優缺點？例如，
簽出文件后，此文件就加鎖，別人無法簽出； 或者， 所有人都可以自由簽出文件
答：我們使用git控制代碼，針對簽入和簽出代碼時的沖突其實對于我們組來說不是很大，因為前中期的工作分為客戶端以及服務器端，這兩
個部分分別由兩個同學分開完成，兩部分的代碼是在不同的倉庫中的，對于某一部分的代碼的修改可以由負責該部分的同學進行，不會出現沖突。
到了后期前后端對接時通過兩個人約定規范來保證代碼的準確簽入簽出。在簽出某個文件之后，另一個人就在此期間不能簽出該文件，并且修改
代碼時不要修改另一同學所寫的代碼，必要時與該同學聯系協商，畢竟只有兩個人，比較容易溝通。
2
如何看到這個文件和之前版本的差異？ 如何看到代碼修改和工作項 （work item），缺陷修復 （bug fix) 的關系。
場景： 程序員果凍看到某個文件被修改了，他怎么看到這個文件在最近的修改究竟改了哪些地方？
場景： 程序員果凍看到某個文件在最新版本被改動了100 多行， 那么和這100多行對應的其他修改在什么文件中呢？ 這個修改是為了解決哪些
問題而作的呢？ 那些問題有工作項 （work item，issue），或者bug 來跟蹤么？
答：我們的項目分工比較獨立，文件中代碼的修改基本上是由某個人獨立負責的，因此追究起修改原因，修改位置等情況也比較方便。
3
如果某個文件在你簽出之后已經被別人修改，并且簽入了，那么你在簽入你的修改的時候， 如何合并不同的修改（merge)? 你用了什么工具來
幫助你？
答：這樣的情況一般來說是不會發生的，首先之前已經說過了，大部分情況下，兩位編碼同學負責完全不同的模塊，很少去使用或者修改相同的
代碼文件，在后面前后端對接時可以由兩個人合作完成，十分方便，即使是手工合并也不麻煩，可以到達結對編程的效果。
4
你有20個文件都是關于同一個功能的修改，你要如何保證這些文件都同時簽入成功（修改的原子性），或者同時簽入不成功？
場景： 程序員果凍要簽入 20 個文件，他一個一個地簽入， 在簽入完5 個 .h 文件之后， 他發現一些 .cpp 文件和最新的版本有沖突，他正在
花時間琢磨如何合并... 這時候， 程序員小飛從客戶端同步了所有最新代碼， 開始編譯， 但是編譯不成功 - 因為有不同步的 .h 文件和 .cpp
文件！ 這時候， 別的程序員也來抱怨同樣的問題，果凍應該怎么辦？
答：git中，所有在本地倉庫中修改的文件都要統一經過commit為新的本地版本后，再push至遠程分支。保障了本地修改提交的原子性，同時git服
務器遠程提供的修改操作也具有原子性。這樣就保障了整體修改的原子性。
5
你的PC 上有關于三個功能的修改，但是都沒有完成，有很多文件處于半完工的狀態，這時你要緊急修改一個新的 bug，如何把本地修改放一邊，
保證在干凈的環境中修改這個 bug, 并成功地簽入你的修改 --- changelist management。
答：針對這個問題，我們的做法是先克隆工程到本地，修改工作在另一倉庫進行。
6
如何給你的源代碼建立分支？
場景：你們需要做一個演示，所以在演示版本的分支中對各處的代碼做了一個臨時的修改， 同時，主要的分支還保持原來的計劃開發。 你們怎
么做到的？ 在演示之后，演示版本的有些修改應該合并到主分支中，有些則不用，你們是怎么做到的？
場景： 你們的軟件發布了，有很多用戶，一天，一個用戶報告了一個問題，但是他們是用某個老版本，而且沒有條件更新到最新版本。 這時候，
你如何在本地構建一個老版本的軟件，并試圖重現那個問題？
答：演示時會為演示的版本創建一個分支，演示時所做的代碼修改只會push到那個分支中去，master分支的代碼不受影響，而修改部分則是手動
加入master分支。場景二目前沒有解決方案。
7
一個源文件，如何知道它的每一行都是什么時候簽入的，為了什么目的簽入的 （解決了哪個任務，或者哪個bug）？
場景： 一個重要的軟件忽然出現崩潰的情況， 程序員果凍經過各種debug手段，發現問題是在某一個文件中有一行代碼似乎顯然出了問題，但是
這個模塊被很多其他模塊調用，這行代碼是什么時候，為了什么目的，經過誰簽入的呢？如果貿然修改，會不會導致其他問題呢？ 怎么辦？
答：對于我們來說，相關代碼的簽入以及簽入目的完全可以明確到個人給出結果，應該可以很快的確定問題代碼的位置及調用情況。
8
如何給一個系統的所有源文件都打上標簽，這樣別人可以同步所有有這個標簽的文件版本？
代碼每天都在變， 有時質量變好，有時變差，我們需要一個 Last Known Good （最后穩定的好版本） 版本， 這樣新員工就可以同步這個版本，
我們如果需要發布，也是從這個版本開始。那么如何標記這個 Last Known Good 版本呢？
答：很抱歉，目前沒有相關的標簽標記。
9
你的項目的源代碼和測試這些代碼的單元測試，以及其他測試腳本都是放在一起的么？ 修改源代碼會確保相應的測試也更新么？你的團隊是否能
部署自動構建的任務？
在簽入之前，程序員能否自動在自己的機器上運行自動測試，以保證本地修改不會影響整個軟件的質量？
在程序員提交簽入之后，服務器上是否有自動測試程序，完成編譯，測試，如果成功，就簽入，否則，就取消簽入？
團隊是否配置了服務器，它自動同步所有文件，自動構建，自動運行相關的單元測試，碰到錯誤能自動發郵件給團隊
答：沒有配置服務器進行自動測試，測試由團隊成員手動完成，進行代碼push時保證修改后的代碼可以編譯成功并順利運行。
文章列表
留言列表
