#Example Auction Software

#Models / terminology:

• Auction (also called a listing in the instructions) contains information and bids on a particular item being sold.
• AuctionHouse is a collection of auctions.
• Bid is how much a user is prepared to pay for an item in an auction.
• Money represents how much the bid or reservedPrices is and is a flawed attempt at avoiding floats. In reality we should use a proper third-party package for dealing with Money.
• AuctionOutput is an Auction with some extra computed fields (like "price paid"). It can be coerced into a string.
• Output is a collection of the AuctionOutputs

#Some notes and design decisions

• I was aiming for simplicity (eg. some big methods with a bit of duplication)
• Persistence: this is only persisted in memory. I wondered about creating a "store / retrieve bids" interface to allow us to use different backend persistance models... but then thought it'd be overkill.
• I've tried to unit- & integration-test decently. I don't have 100% coverage, but I think I've covered most of the important methods practically.
• Some of the spec was potentially ambigious (eg. how to order the results). I've make my best guess at the intention behind the instructions, but it may not be exactly as intended.
• I've only used one package (main). This is because I don't think the logic is sufficiently complex yet to warrant breaking the code in to multiple packages.
• I've broken the code into different files / areas of responsibility:
  • main contains the models & some basic IO & actually calls the main functions (NewAuctionHouseFromFile() & AuctionHouse#generateOutput())
  • parse.go knows how to read a file & generate the appropriate data model representation.
  • output.go knows how to generate the appropriate output from an AuctionHouse
  • bid.go deals with bidding (mainly bid verification)
• Because I've only used one package, most functions/methods are private. I've made some important functions/methods with a decent API public so that we can easily identify them in future.
• I've committed my progress with git if you want to have a look at that.
• This project uses go modules, so it may be sensible to set GO111MODULE env var to on (like in the Makefile)
• I've prioritised code simplicity over performance. There's a relatively inefficient validation method that recursively calls to see if previous bids are valid themselves. It'd be possible to store this data on the bid model, but it would increase complexity (and caching / state management is tricky)