Morgen: Nicht nur Kaffee, sondern das tägliche Stand-up
Stellen Sie sich vor: 9:00 Uhr morgens. Sie öffnen Ihren Laptop, starten IntelliJ IDEA und sehen 48 ungelesene Nachrichten in Slack. Kommt Ihnen bekannt vor? Der Tag eines Java-Entwicklers beginnt nicht mit dem Schreiben von Code, sondern mit der Synchronisation mit dem Team. Das ist keine Routine, sondern ein Ritual, das den Takt für den ganzen Tag vorgibt.
Um 9:15 – das tägliche Stand-up (Daily Stand-up). Per Zoom oder im Büro versammelt sich das gesamte Team: Teamleiter, Backend-Entwickler, Tester. Jeder beantwortet drei Fragen:
- Was habe ich gestern gemacht?
- Was werde ich heute tun?
- Welche Hindernisse gibt es?
Hier kommen Agile und Scrum ins Spiel – Methodiken, auf die in der modernen Java-Entwicklung selten verzichtet wird. Wenn Sie neu sind, seien Sie vorbereitet: Im Stand-up muss man kurz, präzise und ohne überflüssige Details sprechen. Java-Programmierer schätzen Prägnanz – sowohl im Code als auch in der Sprache.
Nach dem Stand-up – E-Mail- und Jira-Check. Sie schauen auf Ihr Aufgabenboard: Was ist "In Progress", was ist "Code Review" und was ist bereits "Done". Ein typischer Arbeitstag eines Java-Entwicklers beginnt oft mit der Priorisierung: "Erst Bugs, dann Features".
Erster Code des Tages: Das morgendliche "Aufwärmen"
Angenommen, Sie arbeiten heute an einem Microservice mit Spring Boot. Die Aufgabe ist es, einen neuen Endpunkt zum Abrufen von Benutzerdaten hinzuzufügen. Sie öffnen den Controller, den Service, das Repository. So könnte ein einfacher, aber funktionierender Code aussehen:
@RestController@RequestMapping("/api/users")public class UserController {
private final UserService userService;
public UserController(UserService userService) { this.userService = userService; }
@GetMapping("/{id}") public ResponseEntity<UserDto> getUserById(@PathVariable Long id) { UserDto user = userService.findById(id); return ResponseEntity.ok(user); }}Dieser Code ist ein typischer Vertreter einer REST-API in Java. Beachten Sie: Wir verwenden Dependency Injection über den Konstruktor, nicht @Autowired. Das ist der moderne Standard, der den Code testbar und sauber macht. In der Welt der Java-Entwicklung entscheiden solche Details oft über vieles.
Mittag: Code-Review und Meetups
Gegen 11:00 Uhr haben Sie bereits einige Klassen geschrieben, Tests gestartet (JUnit + Mockito, natürlich) und einen Pull-Request gesendet. Jetzt ist Zeit für das Code-Review. Das ist nicht nur eine Überprüfung, sondern eine ganze Kunst. Ein erfahrener Java-Entwickler wird Ihren Code ansehen und sagen:
- "Warum wird hier nicht Optional verwendet?"
- "Diese Methode verletzt das Single Responsibility Principle."
- "Lass uns magische Zahlen in Konstanten auslagern."
Code-Review ist keine Kritik, sondern Lernen. In einem guten Team wird jeder Commit reviewed. Das reduziert die Anzahl der Bugs und erhöht die Codequalität. Java-Entwickler wissen: Sauberer Code ist kein Luxus, sondern eine Notwendigkeit, besonders in großen Projekten.
Beispiel aus dem Leben: Code-Review in Aktion
Stellen Sie sich vor, ein Kollege hat diesen Code geschickt:
public List<String> getNames(List<User> users) { List<String> names = new ArrayList<>(); for (User user : users) { if (user.getAge() > 18) { names.add(user.getName()); } } return names;}Sie schlagen ein Refactoring mit dem Stream API vor:
public List<String> getNames(List<User> users) { return users.stream() .filter(user -> user.getAge() > 18) .map(User::getName) .collect(Collectors.toList());}Dieser Code ist kürzer, lesbarer und leichter zu testen. Das ist die Evolution eines Java-Entwicklers: von Schleifen hin zu einem funktionalen Stil.
Nach dem Code-Review – Meetup oder technisches Treffen. In manchen Unternehmen heißt das "Tech Talk" oder "Guild Meeting". Hier werden neue Technologien, Architektur diskutiert oder einfach Erfahrungen ausgetauscht.