Typische Aufgaben eines Java-Entwicklers an einem Projekt

Was sind die typischen Aufgaben eines Java-Entwicklers? Schließlich müssen Sie verstehen, was Sie vorhaben und was Sie am Ende tun werden, oder? Heute möchte ich über die zehn Hauptaufgaben sprechen, die ein Java-Entwickler ausführt. Aber machen wir uns zunächst mit einem Tool wie Jira vertraut. Oder lassen Sie uns unser Gedächtnis auffrischen, wenn es Ihnen bereits bekannt ist. Jira ist ein Benutzerinteraktionstool, wird aber teilweise auch für das Projektmanagement eingesetzt. Mit anderen Worten: Die Projektentwicklung wird in kleine Aufgaben zerlegt, die in diesem Tool beschrieben werden. Diese Aufgaben werden Entwicklern zugewiesen (zugewiesen), die für deren Umsetzung verantwortlich sind. Mit Aufgaben meinen wir beispielsweise das Hinzufügen einiger Funktionen. Während der Fortschritt voranschreitet, fügen Entwickler und andere Spezialisten Kommentare dazu hinzu, wer was getan hat und wie viel Zeit sie aufgewendet haben – sie erfassen die Zeit. Dies geschieht, um die aufgewendete Zeit zu verfolgen: Wie viel wurde ausgegeben und wofür. Idealerweise geschieht dies einmal am Tag: Am Abend vor der Abreise notieren Sie Ihre 8 Stunden den Aufgaben, für die Sie sie aufgewendet haben. Die Funktionalität von Jira ist deutlich umfassender als oben beschrieben, für ein erstes Verständnis reicht dies jedoch aus. Welche Aufgaben hat ein Java-Entwickler?

1. Entwicklung neuer Lösungen

Bevor Sie etwas erstellen und implementieren, müssen Sie es sich erst einmal ausdenken, oder? Wie gesagt, es könnte sich einfach um eine Jira- Aufgabe handeln , die Ihnen zugewiesen wird, und Sie werden an der Entwicklung einer neuen Lösung arbeiten und in Jira notieren, wie viel Zeit Sie wofür aufgewendet haben. Dies könnte auch eine Diskussion im Rahmen eines Gruppenanrufs sein: Jeder kann seine Meinung äußern und den Ansatz vorschlagen, der ihm am besten erscheint. Und hier möchte ich einige Punkte anmerken. Erstens ist der Entwicklerberuf ein sehr kreatives Feld, da Sie einzigartige Wege finden müssen, um Probleme mithilfe von Standardtools zu lösen. Oft kann ein Problem viele verschiedene Lösungen haben: Dementsprechend hängt alles vom „kreativen Geist“ des Entwicklers, der gesammelten Wissensbasis und Erfahrung ab. Hier können Sie Ihre ganze Kreativität und Genialität zeigen, aber die Hauptsache ist, es nicht zu übertreiben: In diesem Fall wird der Code zu komplex und unleserlich und infolgedessen wird nach dem Verlassen niemand mehr vollständig verstehen, was es ist und was es ist wie es funktioniert. Und Sie müssen alles von Grund auf neu schreiben. Und vielleicht erinnern sie sich an dich. Und mehr als einmal. Und es ist unwahrscheinlich, dass es warme, freundliche Worte sind. Brauchst du es? Zweitens muss der Entwickler in dem Sinne flexibel sein, dass er nicht in einer Lösung stecken bleiben und sich anderen gegenüber verschließen darf. Sie müssen nur diesen Weg und nichts anderes tun. Dies kann aus verschiedenen Gründen passieren: Sie möchten zum Beispiel Ihren Standpunkt beweisen oder Sie haben Ihre Lösung bereits entwickelt und implementiert, an der Sie ziemlich hängen und natürlich nicht zugeben möchten, dass dies nicht der Fall ist am besten. Das kann Sie ziemlich blind machen. Tatsächlich müssen Sie in der Lage sein, Ihre Fehler zuzugeben und immer offen für Neues zu sein („open-minded“), auch wenn Sie Funktionen entfernen müssen, an denen Sie viele Wochen lang geschrieben haben und auf die Sie sehr stolz sind. Ich erinnere mich, wie einmal die Stimmung des ganzen Tages durch die Zeiterfassung einer Person in Jira mit dem Kommentar erzeugt wurde: „Ich habe meine totgeborene Funktionalität gelöscht.“ Ich weinte"

2. Neue Funktionalität schreiben

Dies ist ein logischer Schritt nach dem vorherigen – der Implementierung neuer Funktionen. Die gesamte Arbeit am Projekt ist in einem Jira in Aufgaben unterteilt, die die Entwickler während ihrer Arbeit erhalten. Es gibt verschiedene Ansätze für dieses Problem – „Methoden“, mehr darüber können Sie in diesem Artikel auf JavaRush lesen . In der Regel gibt es für Aufgaben eine „Schätzung“ – die voraussichtliche Zeit, die bis zur Erledigung aufgewendet wird. Sie wird entweder von Ihnen selbst bei der Übernahme der Aufgabe oder vom Teamleiter festgelegt oder bei der Planung gemeinsam mit den Entwicklern geschätzt. Dieser Zeitpunkt lässt sich nur sehr selten genau schätzen, da viele verschiedene Faktoren die Entwicklung beeinflussen. Ist der Programmierer beispielsweise mit dieser Technologie vertraut oder nicht vertraut, wie ist seine allgemeine Erfahrung, welche Fallstricke können bereits während der Entwicklung sichtbar werden usw. Wenn Sie diese Frist bei der Entwicklung der Funktionalität nicht einhalten, wird daher nichts Schlimmes passieren. Dabei handelt es sich lediglich um allgemeine Schätzungen. Aber auch hier gibt es nicht für alle Projekte Aufgabenschätzungen, und für mich ist es viel einfacher, ohne sie zu leben, insbesondere wenn der PM Sie nicht ein paar Mal am Tag mit der Frage in die Seite stößt: „Wo sind die Schätzungen?“ ” Dementsprechend nehmen Sie eine Aufgabe an, entwickeln die erforderliche Funktionalität, laden sie in einen gemeinsamen Zweig in GIT hoch und ändern in Jira den Status der Aufgabe in „Bereit zur Überprüfung“ , d. h. bereit zum Anzeigen (Überprüfen) und beten dafür Es wird nicht mit Kommentaren zur Überarbeitung an Sie zurückgesendet.

3. Schreiben von Funktionstests

Der Person, die Ihren Code überprüft – dem Prüfer – gefielen die von Ihnen entwickelten Funktionen, aber er hat eine Frage: Wo sind die Tests dafür? Und er sendet Ihnen die Aufgabe zur Überarbeitung zurück. Tests sind ein wichtiger Bestandteil jeder Java-Anwendung. Indem Sie sie ausführen, können Sie sofort erkennen, wo die Anwendung nicht richtig funktioniert. Beispielsweise hat ein Entwickler einige Änderungen in einem Teil des Systems vorgenommen, die zu Verhaltensänderungen in einem anderen Teil führten, und dies während der Entwicklung nicht bemerkt. Durch die Durchführung der Tests kann er die fehlgeschlagenen Tests (die nicht ordnungsgemäß funktionierten) sehen. Dies wird ihm sagen, dass in einem anderen Teil des Systems etwas kaputt ist. Daher wird er keine Breaking Changes auf den Server hochladen, sondern seine Lösung weiter verfeinern. Ja, natürlich lieben nur wenige Entwickler Tests, aber die Vorteile, die sie für die Anwendung mit sich bringen, lassen sich nicht leugnen. Oft legen Kunden selbst fest, welcher Grad der Testabdeckung eingehalten werden soll (z. B. 80 %). Daher müssen Sie verschiedene Arten von Tests kennen und diese schreiben können. Java-Entwickler schreiben hauptsächlich Unit-Tests und Integrationstests, während sich AQA (Automatisierungstester) mit umfangreicheren (End-to-End-)Tests befassen. Mehr über sie und andere Vertreter der IT-Berufe können Sie in meiner Rezension lesen .

4. Den Fehler finden und beheben

Dies ist auch eine sehr häufige und häufige Aufgabe für einen Java-Entwickler. Die Hauptaufgabe von QA und AQA besteht darin, Fehler zu erkennen. Das heißt, sie suchen nach Stellen, an denen sich das Programm falsch verhält, verursachen Probleme in Jira und geben jemandem die Schuld. Zum Beispiel ein Teamleiter, der wiederum je nach Auslastung und Vertrautheit mit diesem Teil des Systems entscheidet, welchem ​​Entwickler er dies zuweist. Danach sucht der Entwickler nach dem Fehler, verbringt Stunden im Debugger und wiederholt anhand der Problembeschreibung durch QA-Spezialisten die Situation, in der der Fehler aufgetreten ist. Als nächstes findet der Entwickler einen Fehler, behebt ihn und sendet ihn zur Überprüfung. Nun, es ist möglich, dass der Entwickler den Fehler nicht reproduzieren konnte und die Aufgabe mit einem Kommentar dazu an den QA-Spezialisten zurücksendet. Es scheint, als würde es nicht so lange dauern, den Fehler zu finden und zu beheben, aber es gibt einige Nuancen. Alles hängt in erster Linie von der Vertrautheit des Entwicklers mit diesem Codeabschnitt, seiner Erfahrung und seinem Wissen über theoretische Fragen ab. Manchmal kann ein Fehler in 20 Minuten gefunden und behoben werden, manchmal kann es drei Tage dauern. Dementsprechend ist es besonders schwierig, diese Art von Aufgabe im Voraus zu bewerten, es sei denn, der Entwickler versteht nach dem Lesen der Beschreibung sofort, was, wo und womit schief gelaufen ist. In diesem Fall kann er die Uhrzeit mehr oder weniger genau schätzen.

5. Codeüberprüfung

Wie oben erwähnt, muss eine Aufgabe, sobald Sie sie abgeschlossen haben, zur Überprüfung gesendet werden. Wenn sie bestanden wird, wird sie in den allgemeinen Thread verschoben. Wenn nicht, wird sie mit Kommentaren zu den zu erledigenden Aufgaben an den Entwickler zurückgesendet korrigiert. Es ist klar, dass dies alles nicht von einigen höheren Mächten, sondern von anderen Entwicklern überprüft wird. Aber nicht alle Entwickler dürfen Reviewer werden, sondern nur die erfahrensten, die Erfahrung im Rücken haben und schlechten Code von gutem unterscheiden können. Die Codeüberprüfung erfolgt normalerweise mit einem Hilfstool, zum Beispiel Crucible . Prüfer überprüfen den Code und hinterlassen bei Bedarf Kommentare unter einigen Zeilen. Kommentare können auch unterschiedlicher Art sein. Zum Beispiel kritische Kommentare, ohne deren Korrektur der Prüfer den Code nicht weitergibt, und andere sind eher nur Kommentare zum gewählten Ansatz, die der Entwickler anhören, zur Kenntnis nehmen oder ignorieren kann. Das Team kann sein eigenes Verfahren und seine eigenen Regeln für die Durchführung von Überprüfungen erstellen, sich darauf einigen, worauf es wert ist, beachtet zu werden und was nicht, in welchem ​​Zeitrahmen die Codeüberprüfung durchgeführt werden soll usw. Um eine Überprüfung durchzuführen, reicht Erfahrung allein nicht aus: Sie müssen sich noch viel in technischer Richtung weiterentwickeln und verschiedene Bücher lesen (z. B. „Clean Code“ ). Wenn Sie sich für die Feinheiten einer Codeüberprüfung gemäß Google interessieren, empfehle ich Ihnen, diesen Artikel zu lesen .

6. Code-Analyse

Da das Projekt gleichzeitig von mehreren Personen geschrieben wird, die unterschiedlich denken, unterscheiden sich ihr Code und ihre Ansätze. Und mit der Zeit wird alles allmählich zu Brei. Um den Code zu verbessern, erstellen Sie manchmal Aufgaben zur Analyse, vielleicht eines bestimmten Moduls oder der gesamten Anwendung, um Fehler zu finden und zu kennzeichnen, und erstellen später auf der Grundlage dieser Kommentare eine Refactoring-Aufgabe. Die Analyse hilft auch in Situationen, in denen einige einfachere Verknüpfungen zu Beginn der Entwicklung nicht sichtbar waren, jetzt aber sichtbar sind. Beispielsweise wird dieselbe Logik in einigen Methoden häufig wiederholt und kann dementsprechend in eine separate Methode verschoben und viele Male wiederverwendet werden. Nun, entweder ist eine Klasse schmerzhaft aufgebläht, oder ein Code ist schwer zu warten oder veraltet, oder ... Analyseaufgaben tragen dazu bei, die Qualität des Codes und der Anwendung zu verbessern. Allerdings kann die Analyse einer großen Codemenge meiner Meinung nach eine langweilige Aufgabe sein.

7. Code-Refactoring

Der nächste Teil der Analyse ist das Code-Refactoring. Möglicherweise ist es veraltet, wird nicht mehr benötigt, ist schlecht geschrieben, schwer lesbar usw. Sie sollten immer nach Perfektion streben (auch wenn sie nicht existiert) und nach aktuellem Code, indem Sie alles Unnötige entfernen, da dies nur verwirrt und Sie daran hindert, das Wesentliche der Funktionalität zu erkennen. Es versteht sich von selbst, dass Sie diese Aufgaben wahrscheinlich nicht zu Beginn des Projekts sehen werden: Sie fallen erst in späteren Phasen der Entwicklung an, wenn die Anwendung ausgefeilt und zur Perfektion gebracht wird. Hier kann es angebracht sein, sich mit Kollegen darüber zu beraten, wie sie vorgehen würden und welche Fallstricke sie sehen. Der Kern solcher Aufgaben ähnelt der Entwicklung neuer Funktionen. Beispielsweise erhalten Sie die Aufgabe, einige Funktionen zu bearbeiten, ohne deren Verhalten zu ändern. Dazu löscht man das alte, schreibt ein eigenes und überprüft die Tests. Wenn Sie alles richtig gemacht haben, ohne Änderungen an den Tests vorzunehmen, sollten diese wie zuvor funktionieren. Nachdem alles im Code geklärt ist, senden wir ihn zur Überprüfung und gehen Kaffee trinken))

8. Dokumentation schreiben

Stellen Sie sich vor, Sie sind ein neuer Entwickler an einem Projekt, das sich schon lange in der Entwicklung befindet. Sie müssen sich damit vertraut machen oder eine bestimmte Aufgabe ausführen, beispielsweise einen Fehler erkennen. Wie werden Sie durch das Projekt navigieren? Ziehen Sie Ihre Teammitglieder alle fünf Minuten ab? Und wenn sie beschäftigt sind oder am Wochenende sind, was dann? Aus diesem Grund gibt es eine Dokumentation, damit eine Person, die mit der Funktionalität nicht vertraut ist, hineingehen, die richtige Seite finden und schnell verstehen kann, was der Teil der Anwendung tut, der sie interessiert. Aber jemand muss auch die Dokumentation ausfüllen ^^ Wenn das Projekt über Dokumentation verfügt, die die Entwickler unterstützen müssen, beschreiben sie diese bei der Implementierung neuer Funktionen und aktualisieren die Dokumentation bei verschiedenen Änderungen und Refactorings. Es sind auch Situationen möglich, in denen ein separater Spezialist, ein technischer Redakteur, mit der Erstellung, Unterstützung und Kontrolle der Dokumentation beauftragt wird. Wenn es einen solchen Spezialisten gibt, erleichtert das das Leben normaler Entwickler ein wenig.

9. Teilnahme an verschiedenen Kundgebungen

Entwickler verbringen viel Zeit mit verschiedenen Besprechungen, Verhandlungen und Planungen. Das einfachste Beispiel sind „tägliche Besprechungen“ (tägliche Besprechungen), bei denen Sie sagen müssen, was Sie gestern getan haben und was Sie heute tun werden. Darüber hinaus müssen Sie ein persönliches Gespräch führen, beispielsweise mit einem QA-Spezialisten, damit dieser die Nuancen der Reproduktion des Fehlers zeigen/erläutern oder die Nuancen und Anforderungen mit einem Geschäftsanalysten oder einer Organisation besprechen kann Probleme mit einer PN. Daher muss ein Entwickler, auch wenn er introvertiert ist und die Einsamkeit bevorzugt, dennoch in der Lage sein, mit anderen Menschen eine gemeinsame Sprache zu finden (zumindest ein wenig). Je höher der Rang eines Entwicklers ist, desto mehr Zeit muss er für die Kommunikation aufwenden und desto weniger Zeit muss er für das Schreiben von Code aufwenden. Ein Entwicklerteamleiter kann sogar die Hälfte oder sogar mehr seiner Arbeitszeit mit Gesprächen und Besprechungen verbringen und seltener Code schreiben (dies kann dazu führen, dass er ein wenig den Überblick verliert). Aber wenn Sie auch jemand sind, der gerne redet, können Sie sich leicht von der Position des Teamleiters in die Führungsposition entwickeln und den Code völlig vergessen, indem Sie den ganzen Tag mit verschiedenen Teams, Kunden und anderen Managern kommunizieren.

10. Führen/Bestehen eines Vorstellungsgesprächs

Wenn Sie für ein Outsourcing- oder Outstaffing-Unternehmen arbeiten, müssen Sie häufig externe Vorstellungsgespräche führen, wenn Sie an den Kunden „verkauft“ werden müssen (dann können Sie von einer Person auf Kundenseite interviewt werden), und interne Vorstellungsgespräche führen Steigern Sie Ihren Rang innerhalb des Unternehmens. Ich würde das als einen guten Entwicklungsfaktor bezeichnen, da Ihr Wissen durch häufige Vorstellungsgespräche immer auf dem neuesten Stand sein sollte: Sie werden nicht einrosten und sich entspannen, denn wenn Sie sich in der IT entspannen, können Sie völlig aus dem Feld fliegen. Wenn Sie ein erfahrenerer Entwickler werden, können Sie die andere Seite besuchen: nicht bestehen, sondern Interviews führen. Glauben Sie mir, Sie werden sehr überrascht sein, wenn Sie es aus dieser Perspektive betrachten, denn das Führen von Vorstellungsgesprächen kann beängstigender sein als das Bestehen. Sie müssen über eine eigene Interviewstrategie und einen Fragenkatalog verfügen und Zeit haben, in einer Stunde Fragen zu allen erforderlichen Themen zu stellen. Und danach sind Sie für das Feedback verantwortlich, denn wenn Sie sich darauf verlassen, kann eine Person ein so lang erwartetes Angebot oder eine solche Beförderung erhalten oder auch nicht. Nun, und umgekehrt: Sie können einen ehrlich gesagt schwachen Kandidaten für eine Position übersehen, für die er nicht korrespondiert, und dann werden Sie möglicherweise gefragt: Wie haben Sie ihn mit einem solchen Wissensstand überhaupt vermisst? Denken Sie daher bei einem Vorstellungsgespräch daran, dass es Ihrem Gegenüber ebenfalls schwerfällt und er unter Umständen auch unter Stress steht. Jedes Vorstellungsgespräch ist sowohl für den Kandidaten als auch für den Interviewer stressig. Vielleicht enden wir hier. Vielen Dank an alle, die zu Ende gelesen haben: Java mögen und lernen ^^