Setting up a new Java development shop

前端 未结 12 582
心在旅途
心在旅途 2021-02-02 04:36

I\'m setting up a Java development shop, currently just for myself as the only developer, but with hopes of needing to hire others as the business grows. Obviously I\'m hoping

12条回答
  •  一个人的身影
    2021-02-02 04:59

    Distributed source code/revision control (Subversion?)

    • Subversion is good enough unless you want to use this as an opportunity to learn Git or Mercurial.

    Bug tracking (does Trac do this?)

    • Trac works fine if you don't mind CamelCaseTurningIntoWikiWords. JIRA is fancier but (as noted) not free, and I find its data-ink ratio annoyingly low. Good once you learn which parts of the UI to ignore, though.

    documentation (both internal and customer facing)

    • Internally, I would prefer communication over documentation unless you're really willing to commit to spending time keeping internal documentation updated. Javadoc your integration points (internal/external APIs), but try to keep your code and build scripts as self-documenting as you can.

    • That said, requirements docs are useful. I'd suggest using one tracking system for bugs and requirements. JIRA lets you create hierarchical issues, but I wouldn't bother with that till you need it.

    • Trac includes a Wiki, which can be handy although too much content will get stale.

    • Customer-facing docs are all over the map -- depends a lot on what you're doing. If you need big fat manuals (either printed or HTML or on-line help) FrameMaker + the DITA Open Toolkit is a nice combo, but a FrameMaker license is going to set you back $1000.

    • At a certain point this shades into corporate communications (marcom and PR), which are kind of a different animal.

    team communication

    • Google Talk (or the instant messaging framework of your choice), email, and the occasional Skype teleconference are probably all you need.

    • An internal wiki and/or internal blogs might be nice but you probably don't need them right away, even once you've added a few more developers. Trac includes a wiki.

    frequent automated building

    • Switching from CruiseControl to Hudson has made everyone here much happier -- two teams made the same decision independently and both are pleased with it. Hudson's flexible, easy to configure, and shiny.

    • I have yet to be convinced by Maven. I suspect its value depends on how much you want automated downloads of the latest versions of all your open-source libraries.

      • Edited (Feb. 2010) to add: Several months of Maven 2 experience now and I'm still not convinced. I think (like many frameworks, e.g. Rails) it may work well if you're starting from scratch and structuring your project according to its conventions, but if you already have your own structure in place it's a lot less advantageous.

    maybe something to make sure automatic tests pass as part of the check-in process?

    • I'd advise against it. Most of the time the tests will be passing (or should be, anyway) As long as continuous integration notifies you quickly of failures, and you also have stable automated builds (a couple of days' worth of nightly builds, tagged iteration builds, etc.), you want more and faster checkins, not fewer and slower.

提交回复
热议问题