在昨日有提到負責後端的研習生的第一個功課是確定開發的框架，而在評估了一個月之後的考量對象包含了Python的Django、C#的.NET Core與.NET Framework，在初步的工具評估之後也有請前端的同學了解一下，雖然說有分前端與後端的開發定位，但是還是會希望研習生們可以知道其他的組員使用的技術或者是目前評估的工具有哪些。
而最後選擇使用.NET Core的原因有幾點，首先語言上的考量由於後端的研習生擅長的語言是Python，但在網站開發的經驗相對較少，並且若使用Django開發相對個人在技術上的支援會較侷限，所以建議使用C#語言為主。除此之外從現況來看目前研習生們過去也有使用過Visual Studio的工具，但他們的作業系統除了window外也有macOS，這幾個條件下研習生們最後決定使用.NET Core的跨平台開發框架。
確定了使用的語言以及開發框架後，接著確認小組開發的分工模式適合應用於哪一個設計模式，由於已經確定有網站畫面的開發(View)、後台的功能管理(Model)以及使用者的操作邏輯定義(controllrt)。因此選擇使用MVC的開發模式讓研習生能夠練習開發模式，同時在技術的支援上能夠更快的反應(因為近期的專案有使用.Net Core的MVC開發)。
在資料表的設計工具考量部分，負責後端的研習生是Mac OS的系統所以MSSQL在該環境無法安裝，所以選擇了MySQL做為資料庫設計的工具。後續想了一下其實也可以使用MSSQL架設在虛擬主機上，並且請研習生使用Azure Data Studio的工具直接連線，接著就可以設計資料表架構以及多個表格的關聯性。(畢竟個人還是覺得MSSQL開發上比較習慣)
提到資料表也需要留意多個資料表之間的關聯，以及避免後續維護上的成本，因此也提醒研習生至少做到第二個正規化，並且可以參考ER-Model的設計概念。
在小組分工開發的情況下若沒有一個管理程式碼的工具，會造成分工的組員開發一個段落後無法順利地整合在一起，也因此在這個情況下尋找協作的工具。在尋找的關鍵字使用分散式管理找了幾個工具如GitLab、GitHub、bitbucket，然後在考量的包含工具的使用人數、社群的支援度以及研習生目前有接觸的版本控制工具。
接著在討論多人協作開發工作流，依照目前版本控制可以分為標題的三大類，其中針對最後選擇的Github workflow，首先是這個flow相較其他的流程相對簡單，新增新的工作等同於新增一個branch，而當功能開發完成之後就會將該branch合併回原本的workflow。也因此在專案的建立時就將直接做版本控制，但對於研習生而言需要去適應多人開發的時，分支的建立時機以及合併時的優先順序。
光是要學習flow就花研習生蠻多的時間，因此也協助提供幾個常見的UI形式的版本控制工具，對他們而言能夠更加掌握專案開發的版本紀錄，以及在推進度或者是更新進度不需要特別記Git的指令(但還是會半強迫請他們直接用Git指令做依次版本更新的紀錄)。
除了使用指定平台做版本控制之外也可以使用桌面版本的Github做版本控制，個人使用過後的心得是操作起來還蠻順手，並且當檔案有異動時更新的速度也很即時。
除了上述提到的工具外也可以透過vscode的第三方套件以及Visual Studio的內建套件執行版本控制的指令，好處就是開發環境跟版本控制套件都在同一個視窗內，不需要額外安裝應用程式直接透過內建功能完成版本控制的操作。(備註 : 如果是VsCode要版本控制的話可以參考新鮮人擴充套件篇)
最後這個是工具是之前研習的時候業師推薦的，實際使用下來的好處是可以快速了解其他成員目前開發的狀況，以及Branch的各節點進度的視覺化流程圖，在視覺呈現而言算是還蠻吸引人去使用的(先前使用的時候有連結Github的學生身份可以享有一年的專業版)。
總結這兩天的研習計畫文章大概是7月和8月初的狀況，大多數的時間在熟悉工具以及上公司的內訓課程，所以相對在開發上都並沒有遇到太多的困難。而在8月中開始依序請研習生去實作一些功能，隨然寫出來的東西距離上線還有一段距離，但能夠引導他們主動開發以及開始採坑算是一個好的開始。
iThome鐵人賽
看影片追技術