如何跟踪项目的无关怪癖
这个问题的答案可能只是标准的错误跟踪软件，如 jira 或fogbugz，但我希望有人知道我所描述的更好的系统。
我最近的项目需要大量的设置怪异才能进入我可以真正开始编码部分的位置。例如：
- 在我启动 SSH 之前需要执行一系列复杂的公司内部命令。
- 确保进行外部调用的任何第三方类都具有公司内部代理选项设置 - 同时还确保在生产环境中安装时不会设置这些设置
- 确保在尝试安装 pear 软件包之前设置代理。
- 其他类似的事情，主要涉及内部 IT 安全并使其与模块和包一起工作。
就个人而言，这些事情都没什么大不了的，我已经给自己写了关于我所做的确切命令和附加内容的大量注释，但它们目前位于通用文本文档中，很难准确记住它们在哪里我需要的是很远的线。我们还有几名新员工即将加入，我宁愿让他们更轻松地设置编程环境。
正如我所说，它们并不完全是“编程怪癖”，而只是在认真开始编程之前不断出现的摆弄。对于为了我自己和后代的理智而记录这些事情的最佳方式有什么想法吗？
It's possible that the answer to this question may just be standard bug tracking software like jira or fogbugz, but I'm kind of hoping someone out there knows a better system for what I'm describing.
My most current project is requiring a lot of setup quirkiness to get into a position where I can actually start a coding section. For example:
- A series of convoluted internal company commands before I can insitgate an SSH.
- Making sure any third party classes that make external calls have internal company proxy options setup - while also making sure these setting wont be set up when installed on a production environment
- Making sure the proxy is set before trying to install pear packages.
- Other similar things, mostly involving internal IT security and getting it to work with modules and packages.
Individually none of these things is a huge deal, and I've written extensive notes to myself regarding exact commands and aditions I've made, but they're currently in a general text document and it's going to be hard to remember exactly where what I need is far down the line. We also have several new staff starting soon and I' rather give them an easier time of setting up their programming environments.
Like I said, they aren't 'programming quirks' exactly, but just the constant fiddling that comes about before programming starts in earnest. Any thoughts on the best way to documents these things for my own and future generations sanity?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我们使用 wiki 来托管这样的说明。让每个人都知道访问信息的共同位置，并在步骤发生变化时保持最新状态。
如果有可以自动化的部分，这是一个好主意，但如果需要非标准设置，那么我们总是为开发环境设置创建一个页面，而有人必须重复。
We use a wiki to host instructions like this. Makes it easy to have everyone know a common place to access the information and keep it up to date if things change in the steps.
If there are parts that can be automated that is a good idea but we always create a page for the development environment setup if it requires non standard setup that someone will have to repeat.
将每个任务封装到某种类型的脚本中（bash、python、applescript、autohotkey，任何适合该任务的脚本）。
然后创建各种元脚本来调用它们。例如“set_up_everything.bash”。
本质上：与其花时间写下您需要做的所有事情，不如花时间编写一个可以完成您需要做的所有事情的脚本/程序。
如果脚本编写得干净利落，它们也会成为文档的最终形式（就像任何程序一样）。
编辑：
重读您的问题，这也强烈地解决了您关于协助新团队成员掌握最新情况的观点：让他们运行脚本，然后砰！如果脚本不起作用（由于环境差异等），它们仍然提供了一个很好的分步说明，准确说明了需要执行的操作和命令。
Encapsulate each of these tasks into a script of some sort (bash, python, applescript, autohotkey, whatever is appropriate for the task).
Then create various meta-scripts to call them. E.g. "set_up_everything.bash".
In essence: Rather than spending time writing down everything you need to do, spend time writing a script/program that does everything you need to do.
If the scripts are written cleanly, they also become an ultimate form of documentation (just like any program).
Edit:
Rereading your question, this also strongly addresses your point about assisting new team members with getting up-to-speed: Have them run the scripts, and bam! And if the scripts don't work (due to differences in environment, etc.) they still provide a nice step-by-step of exactly the actions and commands that need to be made.
编写脚本来自动执行此操作。花在这件事上的时间会一次又一次地得到回报——您将节省日常时间，并节省引入新开发人员的时间。
您可能需要一个与这些工具的代码库分开的单独的“bin”项目。从更简单的任务开始，逐步完成所有部分。可以使用正确的令牌对安全地编写 SSH 脚本。像 capistrano 或 Chef 这样的工具非常流行。该方法是一次处理一小部分，而目标（也许您无法实现）是完全自动化。
几年前，这听起来像是疯狂的言论。但现在我们的每一个项目都可以毫不费力地检查和运行。 （副作用是持续集成的设置很简单。）甚至可以使用单个按钮来从 AWS 配置服务器、安装和操作系统、所有需要的工具、从 github 检查我们的应用程序并部署它。前几天刚做的！有信心！
Write scripts to automate this. Time spent doing this will pay for itself over and over-- you'll save time day-to-day and save time bringing new developers into the fold.
You may need a separate "bin" project separate from the codebase for these tools. Start out with the easier tasks, and progress to fill in all pieces. SSH can be scripted securely with the right token pairs. Tools like capistrano or chef are quite popular. The approach is to one small piece at a time, and the goal-- perhaps you won't attain it-- is full automation.
A couple years back this would have sounded like crazy talk. But these days every one of our projects can be checked out and run with no twiddling. (A side effect is the continuous integration is trivial to set up.) It's even possible to have single button that provisions a server from AWS, installs and OS, all needed tools, checks out our app from github and deploys it. Just did it the other day! Have faith!
A 计划：通过设置您可以控制的适当测试环境来消除对外部系统的依赖。这可能涉及设置虚拟数据库、模拟 SOAP 服务器（SoapUI Mockservices）等。您应该尝试将所有外部视为黑匣子，您可以使用这些模拟/虚拟/存根服务来控制它们，只需最少的重新配置（例如交换 .ini 文件）。
理想情况下，它将是一个嵌入式环境“设备”，例如包含所需数据库、可执行文件等的目录 zip 文件。也许在闪存驱动器上。
不，我也没有在这样一个乌托邦的环境中生活和工作！但正如我所设想的那样，这就是应该如何完成的。
B 计划：假设您无法执行上述操作，那么您将不得不针对外部（例如“实时”网络和服务器）进行测试。即您的数据库查询针对其他人的测试数据库服务器运行，并且您希望其中包含与上次测试时相同的数据。因此，您需要有一组可以运行的最小测试，以确保外部环境与上次相同。可能是昨天、上个月、去年。假设您需要从 HR 测试数据库中检索员工记录。好的，所以有一个测试应用程序，确保它可以连接、登录、查询记录，并将结果集与“最后一次已知的正确”结果集进行比较。现在你可以走了。如果您没有做到这一点，请先完成它（修复您的登录、端点、主机名、代理、设置帐户、升级驱动程序等...），然后再担心其余部分的编码/测试/演示系统。这将节省大量时间，并且应该防止新开发人员在 3 天后因为没有任何效果而放弃和退出。
更新：无论你做什么，都将其签入版本控制，以便你可以返回、比较等。
Plan A: Eliminate the dependence on external systems by setting up a proper test environment that you can control. This may involve setting up dummy databases, mock SOAP servers (SoapUI Mockservices), etc. You should try to get to a point where you can treat all of the externals as black boxes, which you can control with these mock/dummy/stub services, with minimal re-configuration (like swapping .ini files, for example).
Ideally, it would be a drop-in environment "appliance", such as a directory zip file containing whatever databases, executables, etc., are needed. Perhaps on a flash drive.
No, I do not live and work in such a utopian environment either! But this is, as I envision it, how it should be done.
Plan B: Assuming that you can't do the above, you're stuck with testing against externals such as "live" networks and servers. i.e. your database query runs against somebody else's test database server, and you hope it's got the same data in it that it did the last time you tested. So you need to have a minimum set of tests that can be run to ensure that the external envionment is the same as it was last time. Could be yesterday, last month, last year. Suppose you need to retrieve employee records from the HR test database. Ok, so have a test app that ensures that it can connect, login, query the records, and compare the result set against the "last known good" result set. Now you're good to go. If you don't get that far, work through it (fix your login, endpoints, hostnames, proxy, set up an account, upgrade drivers, etc..) BEFORE you worry about coding/testing/demo'ing the rest of the system. This will save lots of time, and should prvent attrition of new devs that give up and quit after 3 days because nothign works.
Update: And whatever you do, check it into version control so you can go back, compare, etc..