Course code: WEB-35
  • Years with company: 1/2
  • Years programming: 3
  • Primary programming language: C
  • Other programming languages: C++, Python
  • Unit test harnesses: No unit test harness used in the past. Rudimental steps with CPPUTEST done.
  • Something else: I have a background of mechantronics and electrical engineering, but during studies always focused on the "hardware/software interface". I don't have much experience of nice greenfield SW development (e.g. creating a SW Module from scratch). But I consider myself to have good debugging skills, as I worked in a very late stage project in the atuomotive area, where had a lot of bugs and little knowledge about the ideas behind different implementations.
  • Test practice now: We are at the moment in the setup phase of our project. We plan to use Google Test for Unit tests. And we want to have automated integration tests by using Robot Framework. In my past projects testing was mainly done directly after implementation, but for my feeling mainly rudimental tests. There was a seperate System Test deparment.
  • Target system: Embedded platform for ethernet fieldbuses. The plan is to use C++ where possible.
  • Dev tools: Static Code Analysis Azure DevOps
  • Build time: 31-60 seconds
  • Coding standard: Plan ist to apply naming conventions according to "Clean Code" for example. Technically we want to conform to MISRA C and AUTOSAR C++ Guidelines
  • Function too long: It doesnt fit on the screen anymore.
  • Code reviews: Currently in setup phase of the project and no fixed process is implemented so far.
  • Code time: 40
  • Test time: 20
  • Debug time: 40
  • Favorite thing about dev: The whole workflow from simple requirements to functional products. I also like the complexity of the whole topic. From build environments over source control to actual coding.
  • Least favorite thing about dev: It is hard to tell if a the way we choose to do things will be considered as a good decision in the future. SW modules always seem to be fine in the beginning as long as they are small and the person who created is available.
  • Tdd knowledge: That it is a really different approach of development, where you have to get used to it. It is one of our best shots to create maintainable software
  • Why are you attending: It is part of the companies strategy to allign the development approach, therefore it is mandatory for every new developer. I'm glad about that, as it is hard to convince a non-software aware manager of the importance of such a training :)