-
Notifications
You must be signed in to change notification settings - Fork 2
Our Journey
Niklas Köhnecke edited this page Jun 23, 2018
·
13 revisions
- acceptance tests: morphs which actually use our lib. Automatically tested and still available for easy review.
- coding standards: set them at the beginning and refined when encountering inaccuracies. Works quite well.
- spike solution (tinkering around with legacy code and writing a few tests). Helps to estimate how much effort some features take without even having to write them on your own. It doesn't matter that implementation is a bit different from ours, as long as it's roughly the same idea, it's enough to estimate.
- pair programming. didn't work very well (for some). Did it too late, not that much of a productivity increase. Often wasn't able to help the driver. For others it worked out better. It is true, that you are not as productive using pair programming as when programming on your own but you make fewer stupid mistakes(typos, forget something and other things which costs you time when debugging). Also it provides the possibility to directly discuss about a possible solution which in fact encourages you to implement things directly. When programming alone you often would have to discuss to the group about the bigger decisions (so it also supports the XP value of courage a bit). In addition it makes collective code ownership a bit easier and last but not least also it often is a bit more fun than programming on your own.
- test-first: Arthur and Tobias did this, felt very weird for me. Too extreme since we wanted to declare the interfaces first. And our project is very much about usability, therefore we want to make sure our solution makes sense to Swa students first, not test that it works properly.
- maybe also simple design: We develop a library for Swa-students so our code has to be easy understandable. In addition to the things we learned in Swa we also tried to implement our user stories as simple and straight forward and only using a more elaborated, flexible but also complicated patterns when necessary.
- Resources, Scope, Quality, Time: review statistics
- sustainable development, i want to sleep :D. For real, we could give it a try.
- Style Guide
- Clean-Up
- Keyboard-Input
- image manager
- sound manager
- simple collision
- collision for circle morphs
- music manager
- a lot of travis stuff
- more travis stuff, resource loading
- spike legacy code
- rotated rect collision
- incorporate feedback
- refactoring
- documentation
- unix key fix
- prototype collision acceptance test
- create Demo-Game (doubling as tutorial)
- unix key fix - still not done -
- create resource locator
- add resource Manager loadall without filenames
- rework pheno acceptance test: compile methods with description
- complete Demo Game
- fix key bug
- create performance test
- store sound&image in methods
- Register for Key events
- Keyhandler acceptance test
- Questions for Patrick
- Presentation