做项目不可避免会用到工具，对于个人开发者而言，用得顺手是最重要的。
在大企业的大团队做事，信息共享很重要，故而一些很简单的工具，都要平台化。
但是未必有那么好用。
开发人员用IDE，用得顺手是最重要。
有时候大团队会要求合并代码需要满足一些约定的代码规范，工具包集成到IDE中。
不必纠结用什么IDE
其次我们用什么CI 系统，开发者一般不关心，只要流程顺畅即可。但是有时候CI 系统出现的没那么快，项目做了一年多，CI 才过来，甚至要开发人员自己搭建。
怎么选择？
网上很多攻略，但仍然是顺手为主，很多工具的差别，已经微乎其微
使用 gitlab代码托管，gitlab已经提供了很多CI 工具链，熟悉它使用它
如果喜欢 jenkins ，搭建一套也无妨。不过 Jenkins 慢慢已经不那么受到欢迎了。例如我会倾向用 gitlab的CI工具链，能够完美替代 Jenkins 。
理由是，我无需去维护一个第三方平台。
Jenkins的界面其实不是很好看。
插件太多，管不来
慢。
一般需要搭几套环境，置几个slave。当然用gitlab依然要用 slave 来构建特定系统的包，但是一切在于 gitlab的配置文件 yml当中。
用什么框架些什么程序？
例如写GUI客户端，用 Qt还是 wxPython PyQt5 Windows系列？
iOS系统用swift 还是 OC
我观察到，大多数选型初期都是选择自己最顺手的语言，框架。
只有到很细微——通常需要项目特别深入的时候才能感知到框架和语言的差别，到时候当项目赚到了钱，再投入资源去重构也不迟。我的体会是，在 0-1的时候用最顺手最熟悉的东西来做。如果都不顺手，那么使用最流行的那种，或者最顺眼，感情上最倾向的那种。
编程的动力来自于激情，而不是理性，扫除一切浇灭激情的障碍
测试工具
测试人员普遍有一种技术自恋，尤其在他们从纯粹的功能测试人员像自动化测试人员转变的时候，发现写一些短代码似乎并不是很难的时候。他们会花很多时间去摆弄各种测试框架和工具。
测试工具的目的都是为了发掘软件的缺陷，因而不在于什么工具
就我而言，我基本上什么工具都会用一下。
至于自动化框架，按照编程的原则去选择即可。
接口自动化，实际上 postman能胜任多数项目和场景
jenkins要做也可以
ok，robotframework pytest 太多
还有国产的 httprunner
我见过很多人选型，秉持一个业务分析和框架优缺点分析最终选择谁的叙事，但我想说的是，流行的 pytest robotframework 能胜任99.9%的软件自动化任务，如果你觉得有缺点好像无法克服，大多数情况是你对这些框架没有足够的了解。
我见过有人觉得 robotframework 不够好，要重新做一个关键字驱动的测试框架的团队，当然这种一般是在大公司，他们总是要找事做，要升职，但是仔细看他们的动力，实际上不成立的。
自动化最重要的问题通常不是框架，而是用例的文档。在黑盒集成领域，需要花很长时间和它斗争。
正如写软件多数情况不是框架不好，而是业务复杂多变。
我们花很长的时间和业务变化角力。自动化亦然。
所以大多数写一个新框架的动机都不太成立，应该制止。
事实上框架比业务更容易，前提是你了解框架的一些写作套路。
当然我们写一个别开生面的框架，需要一些创造性。创造性不是堆砌时间和人数的。
网友评论