※ 引述《willy69wu31 (小小吴)》之铭言：
: 以往都是用 Eclipse 随便搞搞了事
: 不过开始有越来越多的需求，尤其是程式码管理，所以想寻找一整套整合的方案
: 不然每次一有新专案，就会有很多事项必须手动自己搞出来，有些麻烦
: 希望有:
: 1. 版本控制 (Eclipse 的 workspace 好像囊括了杂七杂八不适合直接塞 git 的档案)
: 2. 自动编译/打包/发行成 jar (还是，各位发行公开的 java 程式时都怎么做?)
1, 2, 5 项要合在一起看。
=================================================================
1. 版本控制系统的强项在管“纯文字”的东西，
塞 binary data 不是不行，只是享受不到版本控制系统的大部分优点。
加上即使用了 git 这样分布式的版本控制系统，
因为需要协作的原因，还是会架设一些管理 repos 的服务器
（别因为自己离 server 近就送一大堆 binary，
总有一天也会因为离得远而历经漫长等待，山水有相逄）
2. 为了尽可能发挥版本控制系统的优点与有效率取得专案完整内容，
使用相依性管理工具是建议的做法。
例如：
Maven, Gradle 或 Ant IVY
或各种方法（每间公司也可能有自己的神奇配方）
配合相依性管理的效果就是让函式库由 binary data 转换成 字串。
这是什么意思？也就是透过“宣告使用的函式库与版本”取代
在专案内持有“实体的 binary data”
所以，最终进版本控系统的是一些宣告字串，
而非函式库 binary data
因为历史的因素，嫌 Ant 太 free-style 又无法做相依管理的开发者
建立了 Maven。Maven 骨子里是个巨大的 Template Method，
流程都定好的，要扩充就只能在各种 phase 上挂上 plugin。
要扩充得弄清楚蛮多细节的，
主要是这个 maven 指令(phase) 走下去会执行哪些 goal
而你打算在特定的 phase 里挂上你想要的功能，或覆蓋一些参数。
由于 Maven 的学习成本较高又因为 Scripting On JVM 的兴起，
各类的 DSL for build tool 兴起，Gradle 是其中的一支。
学习起来相对 Maven 来说是较为简单，但取其许多设计概念与
Maven Repo 基础设施，现在各大以 Java based 的社群渐渐转向。
: 3. 自动建立单元测试
: 4. 程式码自动格式化、变量大小写自动检查之类
: 5. 相依性管理，最好可以自动下载缺少的 jar 等
: 前阵子搜寻了一下，Maven 好像是一个还不错的方案，搭配某些工具之后可以几乎自动化
: 不过有关 Maven 的讨论好少 orz (莫非有专板?)
: 不晓得各位通常都怎么做? 有什么建议的方案或观念吗?
3, 4 二样问题的重点其实不在于工具。
而是人员的心态，是被逼着做，或迫于社会压力而做。
先鼓励大家养成习惯不时写 unit test。
先不论写 code 的品质，与 test coverage。
至少先有能力写出一些关键部位的 unit test，再来渐渐朝习惯养成走。
何谓关键部位！？
1. 出错会死得很惨的地方
2. 自己没有信心写对的地方
3. 人工测试很没效率的地方（例如：启动 web server 要等很久）
重点概念要重于物件的独立性，可相互隔离测试。
起手时常因为所有东西都“黏”在一起而无法测试，
在还没有学会切割责任范围前，其实写不出什么有意义的测试
拥有这几个简单的观念后，才可能对于更正规的学习材料更有 fu。
（那些书看不太懂，即为对 OO 的本质不够贴近）
内功心法渐渐提升是必然的，但有些副作用是意外收获：
1. 因为会写测试，可以不用再依赖 System.out.println 或 Logger
用眼睛在茫茫的讯息中找到资料在脑中查核。
2. 因为有写了测试，有新的问题时可以先补测试，
人工步骤的 debugger 追踪执行期系统状态机会可以少一些
（使用 debugger 仍是个重要的技能）
3. 少了人眼追踪与手动测试，减少视力与手腕肌键的伤害。
先把良好的气氛与工作循环养成，才能开始来推行自动化的内容。
===========================================================
另外，有一些件是不太需要养成观念就能自动化的。
因为这是避免人做蠢事，特别是在做系统上线或程式部署。
（DevOps 内的一部分）
回想起刚进公司时，MIS 单位要负责协助系统上线。
编译好的 Code 由 RD 提供的，上线是怎么搞的呢？
1. RD 将 Dev Server 经 QA 认证的版本打包成 WAR 交给 MIS
2. Server Admin (以下简称 SA) 将 WAR 推到 s1 (第 1 台部署 Server)
3. 由 s1 开始做最后的 check list 检查
(至少会对版本对不对，上错版的杯具不是没发生过)
4. SA 用 rsync 开始同步 s1 至其他台，
每一台都需操作 application server 的 web 接口进行 context update
5. 重复 4. 至每一台 Server 完成
由于 s1 -> 其他台 server 有不同的部分最佳速度，加上 s1 频宽有限
由 sN -> sM 都是 SA 手工依经验上的最短路径 deploy 完成的。
这手工的作业历经了 3 个 SA
（确实很苦逼，上错版，或发现有 bug 都要重做一回）
为何我那么清楚呢？
不知道是不是巧合，每回 SA 离职都是由我代理的 囧rz
第 2 回代理的时间很长，那时就觉得这手工的东西是个大坑。
Application Server 那么高档的东西，一定会有神奇的部署方法才是。
查了查果真有 API 可以用，所以我们趁机会完成了 1 个指令部署
这只是一个针对于自动化 OO 议题的一点小经验，
能减轻人工负担的自动化要早点做，
会增加生手心理负担的自动化要先养兵再来推动。