Introduction to PV168

Course Information

1) Seminars 2) Project 3) Lectures 4) Workshops

Seminars

• Attendance is mandatory!
• Methods of experiential learning
  • Try to do stuff by yourself
  • Reflect on your experience
  • Then learn how to do it properly
• Pair programming
  • Useful also for projects

Project

• Teams of 4 members with one being a team lead
• Assigned by an external Product Manager (PM)
• Teacher in the role of a Technical Lead
  • Guarantees the quality
  • Solves unpleasant situations
• Details at courses pages

Project Schedule

1) Initial GUI 2) The basics of the business logic 3) The persistence

• Business logic completion 4) Non-blocking GUI
• Finish & retrospection 5) Final presentation (Colloquium event)

Team Lead

• Communicates with both PM and Tech lead
• Organizes the cooperation in the team
  • Does less programming
  • Organization takes time
• Attends a few extra workshops

Workshops for Team Leads

1) After the first milestone

• Lead’s responsibilities
• Options & Decisions
• Ways of leading 2) After the second milestone
• Sharing lessons learned with others

Lectures

• Reflection of experience at seminars
• Explanation of related concepts
• Place for discussions
• Optional but recommended

Recommended Reading

• There is a section on PV168 pages:
• Literature
  • Code Smells
  • Design Patterns
  • Effective Java
  • Refactoring

Effective Java

Joshua Bloch

Effective Java (Third Edition)

Addison-Wesley Professional, 2017

https://www.amazon.com/dp/0134685997

Effective Java

• Book not only about Java
  • Almost half of the book is about OOP in general
  • Present since 2001 (the first edition)
  • With code examples specifically in Java
• Items are heavily cross-referenced
  • Start reading anywhere you like

Git Culture

Git Commits

• Commits should be descriptive
• Commits should deal with single change
• Every commit must always pass the tests

Git Commits

Feature Branches

• Work according to Gitlab Flow
• main branch is ready for release
• Work in feature branches
  • Utilize Merge Requests
  • Test every commit

Merge Requests & Code Reviews

• Nothing goes directly into main
• Don’t review more than a few hundred lines of code
• Have at least 2 team members approve the MR
• Have a discussion if anything is not crystal clear