跳轉至內容

ROSE 編譯器框架/工作流程

來自華夏公益教科書,開放的書籍,用於開放的世界

動機和目標

[編輯 | 編輯原始碼]

ROSE 工作流程的目標是擁有一個簡化、簡化和自動化的流程,以允許使用者和開發人員

  • 提高 ROSE 原始碼和文件的質量
  • 提高我們的生產力,使我們能夠以比平時更少的時間和資源來完成高質量的工作

開發指南

[編輯 | 編輯原始碼]

開發大型、複雜的專案會遇到很多挑戰。為了減輕其中一些挑戰,我們採用了一些最佳實踐:增量開發、程式碼審查和持續整合。

  • 迭代和增量軟體開發,用於早期結果、可控風險和更好地參與利益相關者
  • 程式碼審查,用於一致性、可維護性、可用性和質量
  • 持續整合,用於自動化測試、輕鬆釋出和可擴充套件的協作

增量開發

[編輯 | 編輯原始碼]

以小步驟開發新功能,其中每一步產生的程式碼都是對先前狀態的有用改進。與完全闡述整個功能形成對比,在此過程中沒有外部可用的點。

每個 ROSE 開發人員都應至少每三週將自己的工作提交一次。

增量開發的主要好處

  • 您可以在路徑上獲得中間結果。因此,您的贊助商可以睡得更香。
  • 您將盡早並經常獲得有關您是否朝著正確方向前進的反饋。
  • 您的工作將經常被測試併合併到主分支中,避免了合併衝突的風險。

檢視有關如何增量處理專案的更多提示

程式碼審查

[編輯 | 編輯原始碼]

請參閱ROSE 中的程式碼審查

持續整合

[編輯 | 編輯原始碼]

儘可能頻繁地將正在進行的工作中的更改合併到共享主線中,以便儘早識別不相容的更改和引入的錯誤。就係統其餘部分而言,整合更改不必是特定功能增量。

換句話說,增量開發是關於儘早使自己的工作有價值,以及可能關於更好地瞭解它應該採取的方向,而持續整合是關於減少由於多人在並行開發程式碼庫分歧而產生的風險。

是否對新程式碼進行條件化是一個有趣的問題。透過這樣做,一個人將持續整合的範圍縮小到只檢查合併更改程式碼時的表面不相容性。如果沒有實際針對現有測試執行新程式碼,那麼儘早檢測引入的錯誤就會丟失。作為交換,在程式碼庫的同一部分中工作的多個人不太可能互相踩腳,因為相關的程式碼更改會更快地傳播。

持續整合中瞭解更多資訊

高階工作流程

[編輯 | 編輯原始碼]

需求分析

[編輯 | 編輯原始碼]

外部

內部:需要 LC 帳戶才能訪問

  • 華夏公益教科書:基於社群的設計文件並激發討論
  • Powerpoint 幻燈片:關於設計的更正式的溝通
  • Confluence: https://lc.llnl.gov/confluence/
  • Redmine (http://hudson-rose-30:3000/): 基於里程碑和使用者輸入建立專案,建立和跟蹤任務
    • 特定於專案的任務
    • 私有問題跟蹤
    • 私有文件
      • 使用 Redmine 的維基
  • Github
    • 內部 (http://github.llnl.gov/): 僅用於程式碼審查,
    • 外部 (https://github.com/rose-compiler/rose): 公共託管程式碼,公共問題跟蹤,用於一般 ROSE 錯誤和功能。
    • “Rosebot” 自動化 Github 工作流程:初步測試、策略(git-hooks)、自動新增審閱者等。

建議工作流程更改

[編輯 | 編輯原始碼]

重大工作流改進和更改在部署之前應由工作人員徹底測試和審查,因為它們可能會對專案產生深遠影響。

如何提議工作流更改

  • 在 github.com 的 rose-public/rose 問題跟蹤器上提交一個工單。在工單中,提供以下資訊
    • 是什麼:解釋提議的更改是什麼
    • 為什麼要更改:對我們生產力和工作質量的長期益處
    • 更改的成本:學習曲線、可維護性、購買成本

審查工作流更改建議

[編輯 | 編輯原始碼]

審查標準

[編輯 | 編輯原始碼]
  • 最佳化
    • 最佳化我們的工作流程,使我們能夠以更高的質量完成更多工作,並減少時間和其他資源的消耗。
    • 解決拖慢我們的速度或分散我們注意力的因素。
    • 簡化日常生活。比較我們可以如何透過提議的工作流改進消除或自動化流程。
      • 透過在日常工作中新增更多環節/步驟/點選來改進工作流程是適得其反的。
  • 改進
    • 允許逐步提高工作質量。
    • 接受逐步改進比要求第一次就達到完美更現實。
    • 工作流程應允許快速的新貢獻和對現有貢獻的快速修訂。
  • 自動化
    • 工作流程的新增應儘可能自動化。
  • 保留
    • 它必須保留現有工作。
      • 不要從頭開始建立任何內容。
    • 它是否與現有工作流程很好地互動
    • 是否有將現有程式碼/文件轉換為新形式的方法
  • 簡單
    • 我們依賴的軟體工具越多,使用和維護我們的工作流程就越困難。同樣,我們強制執行的格式/標準越多,開發人員進行日常工作就越困難。
    • 在我們的工作流程中採用新的必需軟體元件和新的必需技術格式/標準應經過非常仔細的審查,以評估相關的**長期益處**和成本。長期是指 5 到 10 年的範圍,不與我們現在使用的臨時事物繫結。
  • 主要貢獻者的偏好:貢獻最多的人應該有更大的發言權。
  • 文件:我們要求重大更改在部署之前進行文件化和審查。寫下東西可以幫助我們澄清細節並徵求更廣泛的意見(而不是侷限於面對面的會議)。
華夏公益教科書