Sie sind hier
E-Book

Clean Coder

Verhaltensregeln für professionelle Programmierer

AutorRobert C. Martin
Verlagmitp Verlags GmbH & Co. KG
Erscheinungsjahr2014
Seitenanzahl216 Seiten
ISBN9783826632075
FormatePUB/PDF
Kopierschutzkein Kopierschutz/DRM
GerätePC/MAC/eReader/Tablet
Preis34,99 EUR
Erfolgreiche Programmierer haben eines gemeinsam: Die Praxis der Software-Entwicklung ist ihnen eine Herzensangelegenheit. Auch wenn sie unter einem nicht nachlassenden Druck arbeiten, setzen sie sich engagiert ein. Software-Entwicklung ist für sie eine Handwerkskunst. In Clean Coder stellt der legendäre Software-Experte Robert C. Martin die Disziplinen, Techniken, Tools und Methoden vor, die Programmierer zu Profis machen. Dieses Buch steckt voller praktischer Ratschläge und behandelt alle wichtigen Themen vom professionellen Verhalten und Zeitmanagement über die Aufwandsschätzung bis zum Refactoring und Testen. Hier geht es um mehr als nur um Technik: Es geht um die innere Haltung. Martin zeigt, wie Sie sich als Software-Entwickler professionell verhalten, gut und sauber arbeiten und verlässlich kommunizieren und planen. Er beschreibt, wie Sie sich schwierigen Entscheidungen stellen und zeigt, dass das eigene Wissen zu verantwortungsvollem Handeln verpflichtet. Großartige Software ist etwas Bewundernswertes: Sie ist leistungsfähig, elegant, funktional und erfreut bei der Arbeit sowohl den Entwickler als auch den Anwender. Hervorragende Software wird nicht von Maschinen geschrieben, sondern von Profis, die sich dieser Handwerkskunst unerschütterlich verschrieben haben. Clean Coder hilft Ihnen, zu diesem Kreis zu gehören. Robert C. 'Uncle Bob' Martin ist seit 1970 Programmierer und bei Konferenzen in aller Welt ein begehrter Redner. Zu seinen Büchern gehören Clean Code - Refactoring, Patterns, Testen und Techniken für sauberen Code und Agile Software Development: Principles, Patterns, and Practices. Als überaus produktiver Autor hat 'Uncle Bob' Hunderte von Artikeln, Abhandlungen und Blogbeiträgen verfasst. Er war Chefredakteur bei The C++ Report und der erste Vorsitzende der Agile Alliance. Martin gründete und leitet die Firma Object Mentor, Inc., die sich darauf spezialisiert hat, Unternehmen bei der Vollendung ihrer Projekte behilflich zu sein. In diesem Buch lernen Sie: Was es bedeutet, sich als echter Profi zu verhalten Wie Sie mit Konflikten, knappen Zeitplänen und unvernünftigen Managern umgehen Wie Sie beim Programmieren im Fluss bleiben und Schreibblockaden überwinden Wie Sie mit unerbittlichem Druck umgehen und Burnout vermeiden Wie Sie Ihr Zeitmanagement optimieren Wie Sie für Umgebungen sorgen, in denen Programmierer und Teams wachsen und sich wohlfühlen Wann Sie 'Nein' sagen sollten - und wie Sie das anstellen Wann Sie 'Ja' sagen sollten - und was ein Ja wirklich bedeutet Aus dem Inhalt: Verantwortung übernehmen Feindliche Rollen Ein Teamplayer sein Verbindliche Sprache Der Flow-Zustand Schreibblockaden Test Driven Development Das Coding Dojo Akzeptanztests Teststrategien Zeitmanagement Aufwandsschätzungen Umgang mit Druck Mentoring, Lehrzeiten und die Handwerkskunst Werkzeuge und Hilfsmittel

Robert C. »Uncle Bob« Martin entwickelt seit 1970 professionell Software. Seit 1990 arbeitet er international als Software-Berater. Er ist Gründer und Vorsitzender von Object Mentor, Inc., einem Team erfahrener Berater, die Kunden auf der ganzen Welt bei der Programmierung in und mit C++, Java, C#, Ruby, OO, Design Patterns, UML sowie Agilen Methoden und eXtreme Programming helfen.

Kaufen Sie hier:

Horizontale Tabs

Leseprobe

Vorwort


Sie haben sich für dieses Buch entschieden, also darf ich davon ausgehen, dass Sie ein Software-Profi sind. Das ist gut, das bin ich nämlich auch. Und da ich nun schon Ihre Aufmerksamkeit habe, will ich Ihnen berichten, warum ich mir dieses Buch vorgenommen habe.

Alles begann vor nicht allzu langer Zeit an einem gar nicht so weit entfernten Ort. Vorhang auf, Licht und Kamera an, Ton ab ...

Vor einigen Jahren arbeitete ich bei einer mittelgroßen Firma, die Produkte mit besonders strengen behördlichen Auflagen verkaufte. Das ist Ihnen sicherlich geläufig: Wir saßen in einem Großraumbüro in einem dreistöckigen Gebäude. Geschäftsführer und die höheren Ränge hatten eigene Büros, und es dauerte ungefähr eine Woche, um alle relevanten Personen für ein Meeting in den gleichen Raum zu bekommen.

Wir operierten in einem hart umkämpften Marktsegment, als die Regierung ein neues Produkt freigab.

Plötzlich hatten wir eine völlig neue Zielgruppe potenzieller Kunden. Wir brauchten nur dafür zu sorgen, dass sie unser Produkt kauften. Das hieß, wir mussten unsere Unterlagen bis zu einem bestimmten Datum bei der Behörde einreichen, zu einem anderen Termin ein Assessment Audit bestehen und zu einem dritten Termin auf den Markt gehen.

Immer wieder betonte unser Management nachdrücklich, wie wichtig diese Termine seien. Ein kleiner Fehler, und die Regierung würde uns für ein ganzes Jahr vom Markt sperren, und wenn die Kunden sich nicht gleich vom ersten Tag an bei uns anmelden konnten, dann würden sie sich bei anderen Anbietern registrieren, und wir wären aus dem Rennen.

Es war die Art von Umgebung, über die sich manche Leute beschweren und andere betonen, dass hier »der Druck herrscht, der aus Kohle Diamanten formt«.

Ich war der technische Projektmanager, aus der Entwicklungsabteilung heraus dazu ernannt. Meine Verantwortung bestand darin, die Website an besagtem Tag online zu bringen, damit sich die potenziellen Kunden Informationen und vor allem Registrierungsformulare herunterladen konnten. Mein Partner bei diesem Vorhaben war der fürs Business zuständige Projektmanager, den ich hier mal Joe nennen möchte. Joes Rolle war, auf der »anderen« Seite zu arbeiten, also mit der Verkaufs- und Marketingabteilung und den nicht-technischen Anforderungen. Er war auch der Typ, von dem der Kommentar über den Druck, »der aus Kohle Diamanten formt«, stammte.

Wenn Sie sich mit der unternehmerischen Welt Amerikas auskennen und darin gearbeitet haben, dann kennen Sie wahrscheinlich all die Schuldzuweisungen, die anderen die Verantwortung zuschieben, und den Widerwillen gegen Arbeit – alles völlig normal. Unsere Firma hatte für das Problem mit Joe und mir eine interessante Lösung parat.

Es war ein bisschen wie mit Batman und Robin, wie wir unsere Sachen erledigen sollten. In einer bestimmten Büroecke traf ich mich täglich mit dem technischen Team. Wir erstellten jeden Tag den Fahrplan neu, erarbeiteten den kritischen Pfad und räumten anschließend jedes mögliche Hindernis auf diesem kritischen Pfad weg. Wenn jemand bestimmte Software brauchte, besorgten wir sie. Wenn jemand »liebend gerne« die Firewall konfigurieren wollte, aber »ach du meine Güte, es ist ja schon wieder Zeit für die Mittagspause«, dann ließen wir ihm sein Mittagessen anliefern. Wenn jemand an unserem Configuration Ticket arbeiten wollte, aber andere Prioritäten aufgetragen bekommen hatte, dann wandten wir uns an seinen Vorgesetzten.

Dann den Manager.

Dann den Geschäftsführer.

Wir sorgten dafür, dass alles fluppte.

Es wäre etwas übertrieben zu sagen, dass wir Stühle umwarfen, brüllten und tobten, aber wir setzten aus unserer Werkzeugkiste jedes einzelne Instrument ein, um alles auf die Reihe zu bekommen. Wir erfanden nebenher ein paar neue Instrumente und Techniken und machten das auf eine ethische Weise, auf die ich noch heute stolz bin.

Ich betrachtete mich selbst als Teammitglied, das sich keinen Zacken aus der Krone bricht, im Notfall auf die Schnelle auch mal eine SQL-Anweisung zu schreiben oder mit Kollegen zu zweit zu programmieren, damit der Code ablieferbar wird. Zu jener Zeit dachte ich über Joe auch auf diese Weise: Ich betrachtete ihn als Mitglied des Teams und nicht drüberstehend.

Schließlich musste ich erkennen, dass Joe diese Meinung nicht teilte. Das war für mich ein sehr trauriger Tag.

Es war Freitag, ein Uhr nachts. Die Website sollte planmäßig sehr früh am folgenden Montag live gehen.

Wir waren fertig. *FERTIG*. Alle Systeme schnurrten wie Kätzchen, wir waren bereit. Ich ließ das gesamte Tech-Team für das finale Scrum-Meeting zusammenkommen, und nun musste nur noch der sprichwörtliche Schalter umgelegt werden. Mehr als einfach bloß das technische Team hatten wir außerdem auch die Leute aus der Marketing-Abteilung, also die Product Owner, bei uns.

Wir waren stolz. Es war ein toller Moment.

Dann kam Joe vorbei.

Er sagte etwas wie: »Schlechte Nachrichten. Die Rechtsabteilung hat die Registrierungsformulare noch nicht fertig. Also können wir noch nicht live gehen.«

Das war kein sonderlich großes Problem. Die ganze Projektlaufzeit schon waren wir immer wieder mal von der einen oder anderen Sache aufgehalten worden und zogen die Batman-und-Robin-Masche aus dem Effeff durch. Ich war bereit, und meine Antwort lautete im Wesentlichen: »Okay, Partner, machen wir uns noch mal an die Arbeit. Die Rechtsabteilung ist im zweiten Stock, nicht wahr?«

Dann wurde die Geschichte merkwürdig.

Anstatt mir zuzustimmen, fragte Joe: »Wovon redest du da, Matt?«

Ich entgegnete: »Ach, du weißt schon. Unser üblicher Auftritt. Wir reden hier über vier PDFs, oder? Die sind doch schon fertig, und die Rechtsfritzen müssen sie nur abnicken, oder? Komm, wir hängen ein bisschen an ihren Schreibtischen rum, schauen sie ein wenig böse an, und bringen das Ding hier endlich in trockene Tücher!«

Joe stimmte meiner Einschätzung nicht zu, sondern antwortete: »Wir gehen einfach erst Ende nächster Woche live. Keine große Sache.«

Sie können sich wahrscheinlich ausmalen, wie die restliche Unterhaltung weiterging. Sie verlief etwa wie folgt:

Matt:
»Aber warum denn? Die kriegen das doch in ein paar Stunden hin.«

Joe:
»Vielleicht dauert das aber auch länger.«

Matt:
»Aber die haben doch noch das ganze Wochenende! Das ist doch eine Menge Zeit. Komm, wir ziehen das durch!«

Joe:
»Matt, das sind Profis. Wir können sie nicht einfach mit bösen Blicken dazu zwingen, dass sie ihr Privatleben für unser kleines Projekt opfern.«

Matt:
(holt Luft) »Joe ..., was haben wir denn deiner Meinung nach in den vergangenen vier Monaten mit dem Entwicklerteam gemacht?«

Joe:
»Sicher, aber die sind eben Profis.«

Pause.

Tief Luft holen.

Was. Hat. Joe. Gerade. Gesagt?

Zu jener Zeit war ich der Ansicht, dass das technische Team aus Profis besteht, und zwar im besten Sinne des Wortes.

Wenn ich es mir im Nachhinein noch einmal überlege, bin ich mir da nicht mehr so sicher.

Schauen wir uns diese Batman-und-Robin-Masche noch einmal an, und zwar aus einer anderen Perspektive. Ich dachte, dass ich das Team durch Ermahnungen zu Höchstleistungen anspornte, aber ich hege den Verdacht, dass Joe ein Spiel spielte mit der impliziten Annahme, das technische Personal stelle seinen Gegner dar. Denken Sie mal drüber nach: Warum war es nötig, herumzurennen, gegen Stühle zu treten und Kollegen zu bearbeiten?

Hätten wir nicht eher das Team fragen sollen, wann es fertig ist, um eine zuverlässige Aussage zu bekommen? Dieser Antwort hätten wir dann Glauben geschenkt und uns bei diesem Glauben nicht die Finger verbrannt.

Sicher sollten wir als Profis das so machen ... und gleichzeitig auch wiederum nicht. Joe vertraute unseren Antworten nicht und fühlte sich beim Mikromanagement des Teams unwohl. Gleichzeitig vertraute er dem Team der Rechtsabteilung und war nicht gewillt, das Mikromanagement auf sie auszudehnen.

Worum geht es hier eigentlich?

Auf irgendeine Weise hat das Team der Rechtsabteilung einen Professionalismus auf eine Weise demonstriert, wie es das technische Team nicht vermocht hatte.

Irgendwie hatte eine andere Gruppe es geschafft, Joe davon zu überzeugen, dass sie keinen Babysitter brauchte, dass sie keine Spielchen spielte und erwartete, dass sie auf Augenhöhe zu behandeln sei und als Gleichberechtigte respektiert werden wollten.

Nein, ich glaube nicht, dass das etwas mit ein paar schicken Zertifikaten an der Wand zu tun hat oder ein paar Extraseminaren am College, obwohl diese zusätzlichen Jahre am College einem vielleicht implizit ein soziales Training ermöglicht, wie man sich zu verhalten hat.

Seit jenem Tag vor vielen Jahren habe ich mich gefragt, wie der technische Berufsstand sich ändern müsste, damit er als Profis betrachtet wird.

Oh, ich habe so meine paar Ideen. Ich habe ein bisschen gebloggt, viel gelesen, es geschafft, meine eigene Arbeits- und Lebenssituation zu verbessern, und ein paar anderen geholfen. Und doch kannte ich kein Buch, in dem man einen ganzen Plan vorgestellt bekommt und das einem die ganze Sache explizit erläutert.

Dann bekam ich eines Tages aus heiterem Himmel die Anfrage, den frühen Entwurf eines Buches zu prüfen – und zwar genau jenes, das...

Blick ins Buch
Inhaltsverzeichnis
Cover1
Titel5
Impressum6
Inhaltsverzeichnis9
Vorwort15
Einführung21
Danksagungen25
Über den Autor29
Auf dem Titelbild31
Kapitel 1: Professionalität39
1.1 Seien Sie vorsichtig, wonach Ihnen verlangt39
1.2 Verantwortung übernehmen40
1.3 Erstens: Richte keinen Schaden an42
1.3.1 Beschädige nicht die Funktion42
1.3.2 Beschädige nicht die Struktur45
1.4 Arbeitsethik47
1.4.1 Sie sollten sich in Ihrem Bereich auskennen48
1.4.2 Lebenslanges Lernen49
1.4.3 Praxis50
1.4.4 Teamwork51
1.4.5 Mentorenarbeit51
1.4.6 Sie sollten sich in Ihrem Arbeitsgebiet auskennen51
1.4.7 Identifizieren Sie sich mit Ihrem Arbeitgeber bzw. Kunden52
1.4.8 Bescheidenheit52
1.5 Bibliografie52
Kapitel 2: Nein sagen53
2.1 Feindliche Rollen55
2.1.1 Was ist mit dem Warum?58
2.2 Hoher Einsatz58
2.3 Ein »Teamplayer« sein60
2.3.1 Versuchen62
2.3.2 Passive Aggression64
2.4 Die Kosten eines Ja65
2.5 Code unmöglich72
Kapitel 3: Ja sagen75
3.1 Verbindliche Sprache76
3.1.1 So erkennt man mangelnde Selbstverpflichtung77
3.1.2 Wie echte Selbstverpflichtung klingt78
3.1.3 Zusammenfassung80
3.2 Lernen, wie man »Ja« sagt81
3.2.1 Die Kehrseite von »Ich versuch’s mal«81
3.2.2 Der Disziplin verpflichtet82
3.3 Schlussfolgerung84
Kapitel 4: Programmieren85
4.1 Bereit sein86
4.1.1 Code um drei Uhr früh87
4.1.2 Sorgencode88
4.2 Der Flow-Zustand89
4.2.1 Musik90
4.2.2 Unterbrechungen91
4.3 Schreibblockaden92
4.3.1 Kreativer Input92
4.4 Debugging93
4.4.1 Zeit zum Debuggen96
4.5 Die eigene Energie einteilen96
4.5.1 Wann man den Stift weglegen muss97
4.5.2 Die Heimfahrt97
4.5.3 Die Dusche97
4.6 In Verzug sein98
4.6.1 Hoffnung98
4.6.2 Sich beeilen98
4.6.3 Überstunden99
4.6.4 Unlautere Ablieferung99
4.6.5 Definieren Sie »fertig und erledigt«100
4.7 Hilfe100
4.7.1 Anderen helfen101
4.7.2 Hilfe annehmen101
4.7.3 Mentorenarbeit102
4.8 Bibliografie102
Kapitel 5: Test Driven Development103
5.1 The Jury is in104
5.2 Die drei Gesetze des TDD105
5.2.1 Die Litanei der Vorteile105
5.2.2 Die professionelle Option108
5.3 Was TDD nicht ist109
5.4 Bibliografie109
Kapitel 6: Praktizieren und Üben111
6.1 Etwas Hintergrund übers Üben111
6.1.1 22 Nullen112
6.1.2 Durchlaufzeiten113
6.2 Das Coding Dojo114
6.2.1 Kata115
6.2.2 Waza116
6.2.3 Randori117
6.3 Die eigene Erfahrung ausbauen117
6.3.1 Open Source118
6.3.2 Ethisch handeln118
6.4 Schlussfolgerung118
6.5 Bibliografie118
Kapitel 7: Akzeptanztests119
7.1 Anforderungen kommunizieren119
7.1.1 Verfrühte Präzisierung121
7.2 Akzeptanztests124
7.2.1 Die »Definition of Done«124
7.2.2 Kommunikation127
7.2.3 Automatisierung127
7.2.4 Zusätzliche Arbeit128
7.2.5 Wer schreibt die Akzeptanztests und wann?128
7.2.6 Die Rolle des Entwicklers129
7.2.7 Verhandlungen über die Tests und passive Aggression130
7.2.8 Akzeptanz- und Unit-Tests132
7.2.9 GUIs und andere Komplikationen132
7.2.10 Andauernde Integration134
7.3 Schlussfolgerung134
Kapitel 8: Teststrategien135
8.1 Für die Qualitätssicherung sollte nichts übrig bleiben135
8.1.1 Die Qualitätssicherung gehört zum Team135
8.2 Die Pyramide der Testautomatisierung136
8.2.1 Unit-Tests136
8.2.2 Komponententests137
8.2.3 Integrationstests138
8.2.4 Systemtests139
8.2.5 Manuelle explorative Tests139
8.3 Schlussfolgerung140
8.4 Bibliografie140
Kapitel 9: Zeitmanagement141
9.1 Meetings142
9.1.1 Absagen142
9.1.2 Sich ausklinken143
9.1.3 Tagesordnung und Ziel143
9.1.4 Stand-up-Meetings144
9.1.5 Planungstreffen zur Iteration144
9.1.6 Retrospektive und Demo der Iteration145
9.1.7 Auseinandersetzungen und Meinungsverschiedenheiten145
9.2 Fokus-Manna146
9.2.1 Schlaf147
9.2.2 Koffein147
9.2.3 Die Akkus aufladen147
9.2.4 Muskelfokus147
9.2.5 Input vs. Output148
9.3 Zeitfenster und Tomaten148
9.4 Vermeidung149
9.4.1 Umkehrung der Prioritäten149
9.5 Sackgassen150
9.6 Morast, Moore, Sümpfe und andere Schlamassel150
9.7 Schlussfolgerung151
Kapitel 10: Aufwandsschätzungen153
10.1 Was eine Aufwandsschätzung ist155
10.1.1 Ein Commitment155
10.1.2 Eine Aufwandsschätzung155
10.1.3 Implizierte Commitments157
10.2 PERT158
10.3 Aufgaben schätzen161
10.3.1 Wideband Delphi161
10.4 Das Gesetz der großen Zahlen163
10.5 Schlussfolgerung164
10.6 Bibliografie164
Kapitel 11: Äußerer Druck165
11.1 Druck vermeiden167
11.1.1 Commitments167
11.1.2 Sauber arbeiten167
11.1.3 Verhalten in der Krise168
11.2 Umgang mit Druck168
11.2.1 Keine Panik168
11.2.2 Kommunizieren Sie169
11.2.3 Verlassen Sie sich auf Ihre Disziplinen169
11.2.4 Hilfe holen169
11.3 Schlussfolgerung170
Kapitel 12: Teamwork171
12.1 Programmierer kontra Menschen172
12.1.1 Programmierer kontra Arbeitgeber173
12.1.2 Programmierer kontra Programmierer175
12.2 Kleinhirne177
12.3 Schlussfolgerung178
Kapitel 13: Teams und Projekte179
13.1 Harmoniert es?179
13.1.1 Das zusammengeschweißte Team179
13.1.2 Aber wie managt man so etwas?181
13.1.3 Das Dilemma des Product Owner181
13.2 Schlussfolgerung182
13.3 Bibliografie182
Kapitel 14: Mentoring, Lehrzeiten und die Handwerkskunst183
14.1 Der Grad des Versagens183
14.2 Mentoring184
14.2.1 Digi-Comp I – Mein erster Computer184
14.2.2 Die ECP-18 in der Highschool185
14.2.3 Unkonventionelles Mentoring188
14.2.4 Schicksalsschläge189
14.3 Die Lehrzeit189
14.3.1 Die Lehrzeit bei der Software191
14.3.2 Die Realität192
14.4 Die Handwerkskunst193
14.4.1 Menschen überzeugen193
14.5 Schlussfolgerung193
Anhang A: Werkzeuge und Hilfsmittel195
A.1 Tools196
A.2 Quellcodekontrolle197
A.2.1 Ein »Enterprise«-System der Quellcodekontrolle197
A.2.2 Pessimistisches kontra optimistisches Locking197
A.2.3 CVS/SVN198
A.2.4 git198
A.3 IDE/Editor201
A.3.1 vi201
A.3.2 Emacs201
A.3.3 Eclipse/IntelliJ201
A.3.4 TextMate202
A.4 Issue-Tracking-Systeme202
A.4.1 Bug-Zähler203
A.5 Continuous Build203
A.6 Tools für Unit-Tests204
A.7 Tools für Komponententests205
A.7.1 Die »Definition of Done«205
A.7.2 FitNesse205
A.7.3 Andere Tools206
A.8 Tools für Integrationstests206
A.9 UML/MDA207
A.9.1 Die Details207
A.9.2 Keine Hoffnung, keine Änderung209
A.10 Schlussfolgerung209
Stichwortverzeichnis210

Weitere E-Books zum Thema: Programmiersprachen - Softwareentwicklung

ASP.NET Shortcut

E-Book ASP.NET Shortcut
Format: PDF

Shortcut-Tipps für ASP.NET-Profis Die neue .NET-Version der Active Server Pages stellt eine Umgebung zur Entwicklung von Web-Applikationen im .NET-Framework bereit. Viele aus der Desktop-…

ASP.NET Shortcut

E-Book ASP.NET Shortcut
Format: PDF

Shortcut-Tipps für ASP.NET-Profis Die neue .NET-Version der Active Server Pages stellt eine Umgebung zur Entwicklung von Web-Applikationen im .NET-Framework bereit. Viele aus der Desktop-…

ASP.NET Shortcut

E-Book ASP.NET Shortcut
Format: PDF

Shortcut-Tipps für ASP.NET-Profis Die neue .NET-Version der Active Server Pages stellt eine Umgebung zur Entwicklung von Web-Applikationen im .NET-Framework bereit. Viele aus der Desktop-…

Programmieren lernen in PHP 5

E-Book Programmieren lernen in PHP 5
Format: PDF

Mit der Version 5 erreicht PHP einen bemerkenswerten Reifegrad, der PHP zu einer festen Größe in der Welt der Webprogrammierung macht. Gerade die leichte Erlernbarkeit macht PHP zur idealen…

Mathematik für Informatiker

E-Book Mathematik für Informatiker
Format: PDF

Die Informatik entwickelt sich in einer unglaublichen Geschwindigkeit. Häufig ist die Mathematik Grundlage von Neuerungen. Deshalb ist sie unverzichtbares Werkzeug jedes Informatikers und Pflichtfach…

Mathematik für Informatiker

E-Book Mathematik für Informatiker
Format: PDF

Die Informatik entwickelt sich in einer unglaublichen Geschwindigkeit. Häufig ist die Mathematik Grundlage von Neuerungen. Deshalb ist sie unverzichtbares Werkzeug jedes Informatikers und Pflichtfach…

Mathematik für Informatiker

E-Book Mathematik für Informatiker
Format: PDF

Die Informatik entwickelt sich in einer unglaublichen Geschwindigkeit. Häufig ist die Mathematik Grundlage von Neuerungen. Deshalb ist sie unverzichtbares Werkzeug jedes Informatikers und Pflichtfach…

Weitere Zeitschriften

ARCH+.

ARCH+.

ARCH+ ist eine unabhängige, konzeptuelle Zeitschrift für Architektur und Urbanismus. Der Name ist zugleich Programm: mehr als Architektur. Jedes vierteljährlich erscheinende Heft beleuchtet ...

Archiv und Wirtschaft

Archiv und Wirtschaft

"Archiv und Wirtschaft" ist die viermal jährlich erscheinende Verbandszeitschrift der Vereinigung der Wirtschaftsarchivarinnen und Wirtschaftsarchivare e. V. (VdW), in der seit 1967 rund 2.500 ...

CE-Markt

CE-Markt

CE-Markt ist Pflichtlektüre in der Unterhaltungselektronik-Branche. Die Vermarktung von Home und Mobile Electronics mit den besten Verkaufsargumenten und Verkaufsstrategien gehören ebenso zum ...

crescendo

crescendo

Die Zeitschrift für Blas- und Spielleutemusik in NRW - Informationen aus dem Volksmusikerbund NRW - Berichte aus 23 Kreisverbänden mit über 1000 Blasorchestern, Spielmanns- und Fanfarenzügen - ...

Deutsche Hockey Zeitung

Deutsche Hockey Zeitung

Informiert über das nationale und internationale Hockey. Die Deutsche Hockeyzeitung ist Ihr kompetenter Partner für Ihren Auftritt im Hockeymarkt. Sie ist die einzige bundesweite Hockeyzeitung ...

IT-BUSINESS

IT-BUSINESS

IT-BUSINESS ist seit mehr als 25 Jahren die Fachzeitschrift für den IT-Markt Sie liefert 2-wöchentlich fundiert recherchierte Themen, praxisbezogene Fallstudien, aktuelle Hintergrundberichte aus ...