开发框架

在昨日有提到负责後端的研习生的第一个功课是确定开发的框架，而在评估了一个月之後的考量对象包含了Python的Django、C#的.NET Core与.NET Framework，在初步的工具评估之後也有请前端的同学了解一下，虽然说有分前端与後端的开发定位，但是还是会希望研习生们可以知道其他的组员使用的技术或者是目前评估的工具有哪些。

.NET Core

而最後选择使用.NET Core的原因有几点，首先语言上的考量由於後端的研习生擅长的语言是Python，但在网站开发的经验相对较少，并且若使用Django开发相对个人在技术上的支援会较局限，所以建议使用C#语言为主。除此之外从现况来看目前研习生们过去也有使用过Visual Studio的工具，但他们的作业系统除了window外也有macOS，这几个条件下研习生们最後决定使用.NET Core的跨平台开发框架。

Design pattern

确定了使用的语言以及开发框架後，接着确认小组开发的分工模式适合应用於哪一个设计模式，由於已经确定有网站画面的开发(View)、後台的功能管理(Model)以及使用者的操作逻辑定义(controllrt)。因此选择使用MVC的开发模式让研习生能够练习开发模式，同时在技术的支援上能够更快的反应(因为近期的专案有使用.Net Core的MVC开发)。

MySQL

在资料表的设计工具考量部分，负责後端的研习生是Mac OS的系统所以MSSQL在该环境无法安装，所以选择了MySQL做为资料库设计的工具。後续想了一下其实也可以使用MSSQL架设在虚拟主机上，并且请研习生使用Azure Data Studio的工具直接连线，接着就可以设计资料表架构以及多个表格的关联性。(毕竟个人还是觉得MSSQL开发上比较习惯)

正规化

提到资料表也需要留意多个资料表之间的关联，以及避免後续维护上的成本，因此也提醒研习生至少做到第二个正规化，并且可以参考ER-Model的设计概念。

参考资料

开发模式与辅助工具评估

在小组分工开发的情况下若没有一个管理程序码的工具，会造成分工的组员开发一个段落後无法顺利地整合在一起，也因此在这个情况下寻找协作的工具。在寻找的关键字使用分散式管理找了几个工具如GitLab、GitHub、bitbucket，然後在考量的包含工具的使用人数、社群的支援度以及研习生目前有接触的版本控制工具。

Git Flow、GitLab Flow、GitHub Flow?

接着在讨论多人协作开发工作流，依照目前版本控制可以分为标题的三大类，其中针对最後选择的Github workflow，首先是这个flow相较其他的流程相对简单，新增新的工作等同於新增一个branch，而当功能开发完成之後就会将该branch合并回原本的workflow。也因此在专案的建立时就将直接做版本控制，但对於研习生而言需要去适应多人开发的时，分支的建立时机以及合并时的优先顺序。

版本控制的UI工具

光是要学习flow就花研习生蛮多的时间，因此也协助提供几个常见的UI形式的版本控制工具，对他们而言能够更加掌握专案开发的版本纪录，以及在推进度或者是更新进度不需要特别记Git的指令(但还是会半强迫请他们直接用Git指令做依次版本更新的纪录)。

Github Desktop

除了使用指定平台做版本控制之外也可以使用桌面版本的Github做版本控制，个人使用过後的心得是操作起来还蛮顺手，并且当档案有异动时更新的速度也很即时。

开发工具的内建以及第三方套件工具

除了上述提到的工具外也可以透过vscode的第三方套件以及Visual Studio的内建套件执行版本控制的指令，好处就是开发环境跟版本控制套件都在同一个视窗内，不需要额外安装应用程序直接透过内建功能完成版本控制的操作。(备注 : 如果是VsCode要版本控制的话可以参考新鲜人扩充套件篇)

Gitkraken

最後这个是工具是之前研习的时候业师推荐的，实际使用下来的好处是可以快速了解其他成员目前开发的状况，以及Branch的各节点进度的视觉化流程图，在视觉呈现而言算是还蛮吸引人去使用的(先前使用的时候有连结Github的学生身份可以享有一年的专业版)。

采坑与痛苦的开始

总结这两天的研习计画文章大概是7月和8月初的状况，大多数的时间在熟悉工具以及上公司的内训课程，所以相对在开发上都并没有遇到太多的困难。而在8月中开始依序请研习生去实作一些功能，随然写出来的东西距离上线还有一段距离，但能够引导他们主动开发以及开始采坑算是一个好的开始。