​

 

 

Ein ungewisses Jahr 2023 in Bezug auf die Entwicklung des IT-Markteshttps://cleverlance.com/de/blog/Seiten/uncertain-development-2023.aspxEin ungewisses Jahr 2023 in Bezug auf die Entwicklung des IT-Marktes<p>​​Die wirtschaftliche Lage in Europa und in der Welt ist derzeit in der Tat unsicher. Die Globalisierung der gesamten IT-Branche schreitet voran, wo immer es die Sprachbarriere zulässt, aber sie sich jetzt mit geopolitischen Risiken konfrontiert. Die Entwicklung kundenspezifischer IT-Software steht jedoch nach wie vor auf einer stabilen Grundlage, und die Branche ist nicht von einer größeren Rezession bedroht.</p><h3>Wirtschaftliche Unsicherheit</h3><p>Viele Wirtschaftsexperten sagen eine deutliche Abkühlung oder gar eine Krise der tschechischen, europäischen und globalen Wirtschaft voraus. Allerdings ist die tatsächliche Situation aus meiner Sicht nicht so schwarz, wie viele sie malen. Bislang beobachte ich mehr Unsicherheit im Verhalten des Marktes als die Anzeichen einer echten Krise. Erfreulicherweise scheint die Inflation in den wichtigsten Märkten ihren Höhepunkt überschritten zu haben und beginnt sich zu verlangsamen. Außerdem befindet sich die Arbeitslosigkeit sowohl in Europa als auch in den USA immer noch auf einem Rekordtief. Der Markt steht also weltweit nicht still, und die Unternehmen entlassen ihre Mitarbeiter nicht. Speziell im IT-Bereich begrenzen oder stornieren die Kunden keine Großaufträge, sondern planen für kürzere Zeiträume mit vierteljährlichen oder sogar monatlichen Budgets. <strong>Die Situation begünstigt eindeutig flexible Akteure, die ihren Kunden zuhören und in der Lage sind, proaktiv und flexibel auf ihre Bedürfnisse zu reagieren.​</strong><br></p><p><strong><img src="/de/blog/PublishingImages/Articles/CreateIt/inflation_trends_caloun_de.png" data-themekey="#" class="ms-rteImage-1" alt="" style="margin:5px;width:680px;height:420px;" /><br></strong></p><h3>Konsolidierung und Stärkung der Position</h3><p>Die Stabilität des IT-Sektors zeigt sich insbesondere in der regen Akquisitionstätigkeit. Die großen Unternehmen der IT-Branche werden immer stärker und der Markt konsolidiert sich weiter. Die Kundenpräferenzen entsprechen dieser Situation. Für die meisten von ihnen rücken IT und Software immer mehr in den Mittelpunkt ihres Geschäfts und ihrer Interessen. Was die Risiken angeht, so müssen sie ihre Aufträge stabilen Unternehmen anvertrauen und können sich eine risikoreichere Zusammenarbeit mit kleineren Anbietern immer weniger leisten. Die Kunden sind natürlich auch an der Qualität und Breite des Angebots interessiert. Dies verschafft Anbietern mit einem breiten Portfolio an Dienstleistungen und Kompetenzen einen Vorteil gegenüber kleineren, spezialisierten Unternehmen. <strong>Das Interesse an Unternehmen des IT-Sektors ist generell groß, und das Modell der Konsolidierung zu größeren Einheiten wird von Investoren auf globaler Ebene unterstützt.​</strong><br></p><p><strong><img src="/de/blog/PublishingImages/Articles/CreateIt/unemployment_EU_caloun_de.png" data-themekey="#" class="ms-rteImage-1" alt="" style="margin:5px;width:680px;height:421px;" /><br></strong></p><h3>Globalisierung versus Geopolitik<br></h3><p>Die Globalisierung ist kein neuer Trend unter den IT-Trends. Das Interesse der Kunden an Near- oder Offshore-Lieferungen nimmt seit vielen Jahren zu. In diesem Jahr hat jedoch vor allem die Geopolitik eine wichtige Rolle bei diesem Trend gespielt. Während die Covid-19-Pandemie die globalen Lieferketten entscheidend lahmlegte und viele Hersteller darüber nachdachten, ihre globalen Aktivitäten wieder näher an ihre Heimatmärkte zu verlagern, ging die Globalisierung in der IT-Welt insgesamt reibungslos weiter. Der russische Einmarsch in der Ukraine hat jedoch die Grenzen der Globalisierung auch für die IT-Welt deutlich aufgezeigt. Sie hat das Konzept des Friend-Shoring gestärkt, das ebenfalls die Globalisierung nutzt, sich aber nur auf zuverlässige und befreundete Länder konzentriert. Damit steht Russland außerhalb der Weltwirtschaft, ebenso wie (zunehmend) China und möglicherweise andere Staaten, die keine eindeutigen politischen Verbündeten der euro-atlantischen Gemeinschaft sind. Daher rechne ich 2023 mit einer weiteren Globalisierung der IT-Dienstleistungen, sofern die Sprachbarrieren dies zulassen, allerdings nur in politisch befreundeten Ländern. <strong>Unternehmen, die über Sprachexperten und ein globales Vertriebsnetz verfügen, werden weiterhin einen klaren Vorteil haben, und ihr Potenzial, interessante Kunden vom Silicon Valley bis nach Singapur zu erreichen, wird weiter wachsen.​</strong>​<br></p>
Fünf aktuelle UX-Trendshttps://cleverlance.com/de/blog/Seiten/UX-trends.aspxFünf aktuelle UX-Trends<p>​<br></p><br><p>Als wir 2009 den ersten Almanach Benutzerfreundliche Schnittstellen in der Tschechischen Republik veröffentlichten, hatten wir etwa zwanzig Experten, die sich mit diesem Phänomen beschäftigten. Laut Glassdoor, einem weltweit führenden Anbieter von Jobinformationen und Beschäftigungstrends, gehört der UX-Designer heute zu den 25 weltweit am meisten gefragten Berufen. Googles Einstieg in die Welt der Bildung hat zu mehr als einer halben Million Zertifizierungen im Bereich UX geführt. Der Bereich entwickelt sich weiter, ebenso wie die Anforderungen und Ergebnisse dieser kreativen Tätigkeit. Schauen wir uns an, welche wir derzeit für die interessantesten halten.</p><h3>1. Benutzeroberflächen sind Markenträger</h3><p>Je mehr wir durch die Forschung über die Benutzer wissen, desto mehr Zeit und Ressourcen haben die Entwicklungsteams, um sich auf die Form und Konsistenz der Benutzeroberfläche zu konzentrieren. Für ein optimales Nutzererlebnis müssen alle Ausgaben ähnlich aussehen, Unternehmen können es sich nicht leisten, jedes Mal eine andere Sprache mit dem Kunden zu sprechen. Gleichzeitig befassen sich viele Unternehmen heute mit der Kontrolle und dem Erscheinungsbild der Anwendung allenfalls auf der Ebene der Unternehmensfarben. Aber der Markenkern, der über die Benutzeroberfläche transportiert wird, ist eine wichtige Dimension der Kommunikation nicht nur gegenüber den Kunden, sondern auch innerhalb der Unternehmen selbst. Das Beispiel von Nike zeigt dies, dessen Benutzeroberflächen immer auf den ersten Blick erkennen lassen, dass es sich um diese Marke handelt.</p><h3>2. Designsystem als Teil der UX-Lieferung</h3><p>Damit eine Marke ihre Einzigartigkeit bewahren kann, darf das Erscheinungsbild der einzelnen Technologielösungen nicht allein vom Anbieter oder der Plattform abhängen. Design System Management (DSM), eine Reihe von Standards für das Design Management in großem Maßstab, entwickelt sich zum Standard. Dank der in diesem Bereich entwickelten Tools ist es möglich, auch für Dritte einen ständigen Zugriff auf das aktuelle Entwurfshandbuch zu haben. Das Ergebnis ist eine visuelle Konsistenz über verschiedene Schnittstellen oder digitale Kanäle hinweg.</p><h3>3. Aufbau von Glaubwürdigkeit durch Nutzererfahrung</h3><p>Wie zuvor kauft der Nutzer ein Produkt, nur diesmal in einer digitalen Umgebung. Die Tatsache, dass ein einheitliches Erscheinungsbild für die Nutzer in ihrer Beziehung zu einer Marke von wesentlicher Bedeutung ist, wird durch zahlreiche Studien bestätigt. Laut dem Adobe Trust Report (The digital economy is personal, 2022) geben 57 % der Verbraucher an, dass sie einem Unternehmen, das ihr Vertrauen missbraucht hat, keine weitere Chance geben werden. 70 % der Verbraucher sagen, dass eine ungenaue Personalisierung ihr Vertrauen in eine Marke verringert. Dies hängt auch mit dem Umgang mit Kundendaten zusammen. Auch hier gilt: Je transparenter der Umgang mit den verarbeiteten Daten des Kunden im digitalen Umfeld ist, desto eher ist der Kunde bereit, seine Daten einem Unternehmen seines Vertrauens zur Verfügung zu stellen.</p><h3>4. Typografie - ein kleines Detail mit fataler Wirkung</h3><p>Ein kleines, aber wichtiges Detail des Brandings ist die Typografie. Je mehr Text auf digitale Geräte übertragen wird, desto höher sind die Qualitätsanforderungen an das Schriftbild. Ein UX-Designer muss sich darüber im Klaren sein, dass Text heute in den verschiedensten Situationen und an den unterschiedlichsten Orten verwendet wird: ein Autofahrer, der auf das Armaturenbrett schaut, ein Läufer, der in seiner App das Tempo vorgibt, das morgendliche Lesen von Nachrichten auf dem Handy auf dem Weg zur Arbeit, ein Lagerarbeiter, der Daten von einem Lesegerät abruft, ein Bediener, der in einer Produktionsanlage ein Gerät einrichtet... All diese Situationen haben eines gemeinsam: Der Benutzer hält das Gerät oft in der Hand und liest von einem wackeligen Display ab. Dies stellt natürlich viel höhere Anforderungen an die Schrift als bei der Verwendung auf einem stabilen Untergrund. Auf Wunsch unserer Kunden arbeiten wir bei Cleverlance mit Typographen zusammen, um neue Schriften zu entwickeln, die die Lesbarkeit von Text unter schwierigen Bedingungen verbessern.</p><h3>5. Grenzen der internen UX-Teams</h3><p>Der Wunsch vieler Unternehmen, von UX-Beratern wegzugehen und eigene UX-Teams aufzubauen, stößt an seine Grenzen. Die Erwartung, dass ein interner UX-Experte alle UX-Fähigkeiten abdeckt, erweist sich oft als unrealistisch. Teilbereiche der UX wie Forschung, Copywriting oder Design haben sich so spezialisiert, dass ein einzelner Experte sie nicht mehr auf dem erforderlichen Niveau beherrschen kann. Aus diesem Grund bilden Unternehmen nach und nach immer mehr UX-Teams, während es gleichzeitig immer schwieriger wird, auf dem Arbeitsmarkt Spezialisten mit dem erwarteten Wissens- und Kompetenzniveau zu finden. Infolgedessen konzentriert sich das interne Team nur auf einen Bereich der UX, z. B. auf die Forschung. Ohne einen guten Designer bringt sie jedoch nur theoretische Ergebnisse. Ein großes Handicap dieser Teams ist auch die übermäßige (wenn auch verständliche) Konzentration auf das Produkt eines bestimmten Unternehmens. Designern und Forschern fehlt es an Vergleichen mit anderen Branchen, an Erkenntnissen und bewährten Verfahren. Damit kommen Technologieunternehmen wieder ins Spiel, die dank der Vielfalt ihrer Aufträge Unternehmen mit neuen Ansätzen bereichern und interne UX-Teams sinnvoll ergänzen können.​<br></p>
Die automatische Testingmaschinehttps://cleverlance.com/de/blog/Seiten/Automatic-Testing.aspxDie automatische Testingmaschine<p>​​​​​​​<br>Es gibt kein universelles Testprogramm für automatisierte Tests. Jedes Projekt braucht sein eigenes, einzigartiges Skript, das auf der Grundlage einer umfassenden Expertenbewertung erstellt wird. Vor jedem neuen Projekt muss genau berechnet werden, welche Art des Testens optimal, effektiv und ökonomisch ist. Erst dann kommen das automatisierte Testen und ein Testroboter ins Spiel.</p><p> "Generell beschleunigt die Testautomatisierung den Prozess, das ist klar. Und dank der Automatisierung können mehrere verschiedene Szenarien getestet werden, der Umfang der Tests kann erweitert werden, und jedes von ihnen kann identisch durchgeführt werden, da die Roboter die Szenarien jedes Mal auf absolut gleiche Weise ausführen", sagt Tomáš Mertin, ein Entwickler von automatisierten Testsystemen bei Cleverlance. Das hat zur Folge, dass das Testen und das Schreiben des Codes im Wesentlichen gleichzeitig erfolgen, und die Entwickler können etwaige Fehler oder Ungenauigkeiten innerhalb von kurzer Zeit beheben.</p><p> "In den letzten Monaten haben wir ein zunehmendes Interesse an automatisierten Tests beobachtet, das ist ein Trend, aber jeder erwartet, dass dadurch die Zahl der an der Entwicklung beteiligten Personen verringert wird. Ich glaube nicht, dass dies der Fall sein wird", sagt Mertin. "Automatisierte Tests werden die Entwicklung definitiv beschleunigen. Außerdem erhalten wir dadurch eine bessere Kenntnis über den Zustand der Anwendung zu einem bestimmten Zeitpunkt. Aber Tests, Bereitstellung, Betrieb - all das muss immer noch von jemandem gepflegt werden. Die menschliche Dimension wird bleiben", erklärt Mertin und fügt hinzu, dass automatisierte Tests seiner Meinung nach den Menschen nicht vollständig ersetzen werden. "Allerdings werden sie Zeit sparen, die sie dann für die eigentliche Entwicklung verwenden können."<br></p><p> Automatisierte Test-Frameworks haben sich in Bereichen bewährt, in denen die Entwicklung ständig im Gange ist. Zum Beispiel im Bankensektor. "Wir haben ein großes Projekt, bei dem wir praktisch das gesamte digitale Banking aufbauen. Eine Phase muss genau mit der nächsten verzahnt werden. Heutzutage wird bei Projekten dieser Größe agiles Management eingesetzt, was das Ganze möglich macht", sagt Jan Vajsejtl, der bei der Komerční banka​​​​, einer der größten Banken in der Tschechischen Republik, für das Testen zuständig ist.</p><p> In der Vergangenheit haben große Unternehmen wie Banken Wasserfalltests durchgeführt. Die Tester erhielten fertige Abschnitte, während die Entwicklungsarbeit stillstand, weil die Entwickler darauf warteten, zu erfahren, was sie beheben mussten. Wenn ein größerer Eingriff erforderlich war, folgte eine weitere Testphase, was die Arbeit verlängerte. </p><p> In den letzten zwei Jahren wurden die herkömmlichen, bewährten und effizienten Testmethoden durch automatisierte Tests ergänzt. Es hat sich überall dort bewährt, wo die Entwicklung praktisch ununterbrochen läuft. Die Erfahrungen damit sind außerordentlich gut, sagt Jan Vajsejtl von der Komerční banka.  </p><p> Dies sind Fälle, in denen automatisierte Tests einen wesentlichen Unterschied machen. "Unsere Erfahrungen sind außerordentlich gut. Das automatisierte System, das meine Kollegen und ich auf unsere Bedürfnisse abgestimmt haben, ermöglicht es uns, praktisch alle Geräte und Umgebungen, Mobiltelefone, Websites und mehr zu testen", sagt Vajsejtl.</p><p> Obwohl das Innere des Systems kompliziert ist, ist seine Anwendung in der Praxis überraschend einfach. "Ich denke, der Hauptvorteil ist, dass es im Grunde sehr einfach geschrieben ist. Eine kurze, halbtägige Schulung reicht also aus, um es zu benutzen. Man muss definitiv nicht programmieren können oder ein tiefes technisches Wissen haben." </p><p>​ "Für mich ist es ein Testerfolg. Wir haben das Testframework in der Praxis eingesetzt und ausprobiert; meine Kollegen von Cleverlance und ich haben es auf die Bedürfnisse der Komerční banka zugeschnitten und um zusätzliche Funktionen erweitert. Angesichts des Umfangs unserer Entwicklung ist das eine wirklich effiziente Sache", so Vajsejtl. ​<br><br></p>
Wenn man Analytiker sagt, bedeutet das ...https://cleverlance.com/de/blog/Seiten/analytiker.aspxWenn man Analytiker sagt, bedeutet das ...<p>​​Aus der IT-Perspektive bedeutet die Tätigkeit eines Analytikers mehrere verschiedene Aufgaben mit unterschiedlichen Arbeitsbereichen Dazu gehört die Rolle des IT-Analytikers, der auch als Systemanalytiker, Business-Analytiker, Datenanalytiker oder Testanalytiker bezeichnet wird. Aber was tut der Mensch auf der betreffenden Arbeitsposition eigentlich und wofür ist er verantwortlich? Schauen wir uns die Rollen chronologisch an, so wie sie in den Verlauf des IT-Projekts eintreten.</p><h3>Business-Analytiker</h3><p>Die erste analytische Position, die in das Projekt eintritt, ist der Business-Analytiker. Seine Aufgabe ist, sehr vereinfacht ausgedrückt, mit dem Kunden, mit den Business-Vertretern vor Ort, zu kommunizieren. Das Ziel seiner Arbeit ist, die Bedürfnisse des Kunden zu sammeln, diese in Anforderungen umzuwandeln und sie nach ihrer Wichtigkeit zu ordnen. Anschließend entwickelt der Analytiker einen Lösungsentwurf, d. h. er baut die Software de facto aus der Sicht des Benutzers auf. Seinen Entwurf verzeichnet er in die Business-Analyse, d. h. es werden Prozessdiagramme, Use-Case-Modelle oder User-Stories, Aktivitätsdiagramme, Beschreibungen von Benutzerrollen, Wireframes von Bildschirmen usw. erstellt, also alles, was zeigt, wie das System aus Sicht des Benutzers funktionieren soll.​​<br></p><h3>IT-Analytiker</h3><p>Der IT-Analytiker, der auch als Systemanalytiker bezeichnet wird, tritt früh oder zusammen mit dem Business-Analytiker in den Projektprozess ein. Seine Aufgabe ist, die technische Lösung des Systems zu entwerfen. Bei seiner Arbeit kommuniziert er intensiv sowohl mit dem IT-Architekten, der für das Konzept der Entwicklung der Applikation zuständig ist, als auch mit dem Business-Analytiker, der ihm die Funktionsanforderungen und die Beschreibung der Lösung aus Unternehmenssicht vorlegt. Der IT-Analytiker entwirft und beschreibt dann die Details der technischen Lösung, einzelne Systemmodule, Daten- und Objektstrukturen einschließlich ihrer Verknüpfungen, definiert Schnittstellen, modelliert Sequenzdiagramme usw. Die Ergebnisse des IT-Analytikers bilden zusammen mit den Ergebnissen des Business-Analytikers die Spezifikationen, nach denen die Entwickler das gewünschte System programmieren. Deshalb ist es eine Standardanforderung für IT-Analytiker, Kenntnisse in Programmiersprachen wie Java, .NET, SQL oder XML zu haben. Erwartet wird auch die Kenntnis von Methodiken wie RUP und ITIL oder des kürzlich erweiterten <a href="https://www.create-it.cz/Blog/Stranky/DevOps.aspx">DevOps</a> Ansatzes für die Softwareentwicklung.</p><h3>Testanalytiker</h3><p>Der Testanalytiker bearbeitet die Testanalyse. Er studiert die Eingaben des Business- und IT-Analytikers, geht mit ihnen die Prozesse und die Logik der gesamten erwarteten Lösung durch, um zu verstehen, wie das System letztendlich funktionieren soll. Daraus geht hervor, dass er in das Projekt entweder erst nach der Verarbeitung der Business- und der IT-Analyse oder bevor sie abgeschlossen ist, eintritt. Nachdem er sich mit den analytischen Dokumenten vertraut gemacht hat, entwickelt er Testszenarien (Test Case), Testsuiten (logische Gruppierung von Tests, die miteinander in Beziehung stehen) und Testskripte. Es kann auch vorkommen, dass er bei der Erstellung von Testszenarien auf einen Mangel in der Business- oder IT-Analyse stößt. In diesem Fall wird der Business- oder IT-Analytiker auf diese Tatsache hinweisen, damit der festgestellte Mangel in der Analyse nachgearbeitet werden kann. Bei der Erstellung von Testszenarien definiert der Testanalytiker auch die notwendigen Testdaten zum Testen der Software. Im Finale ist er in der Lage, einen Testplan, d.h. die Reihenfolge der Tests für einzelne Testszenarien, vorzuschlagen. Manchmal ist er auch derjenige, der die Testdaten vorbereitet oder an den Softwaretests selbst beteiligt ist.</p><h3>Datenanalytiker</h3><p>Ein Datenanalytiker arbeitet, wie der Name schon besagt, mit Daten. Jedes System enthält Tausende, manchmal Millionen von Datensätzen, aus denen sich eine Fülle interessanter Informationen für Geschäftszwecke extrahieren lässt. Dabei handelt es sich um numerische Werte, aber auch um Daten mit Textcharakter. Der Datenanalytiker arbeitet sowohl mit primären Datenquellen, d.h. Daten aus dem Hauptsystem, als auch mit sekundären Daten, z.B. Daten aus Systemen, die sich mit weniger wichtigen, d.h. unterstützenden Prozessen beschäftigen. Der Analytiker sortiert, bereinigt und analysiert die Daten mit statistischen Standardinstrumenten. Er erstellt verschiedene Arten von Berichten und Visualisierungen für Geschäftszwecke oder das Management. Entwirft und erstellt Relationsdatenbanken, definiert Korrelationen und Formeln in komplexen Datensätzen. Zu den wichtigsten Fähigkeiten eines Datenanalytikers gehören Gestaltung von Datenbanken, Orientierung in Datenspeichern und BI-Plattformen, SQL, Data Mining und die Fähigkeit, die resultierenden Daten zu visualisieren und die ermittelten Ergebnisse zu präsentieren. Aber auch die Kenntnis von statistischen Techniken, mathematische Kenntnisse und Orientierung im Finanzbereich. Eigentlich kann ein Datenanalytiker in das Projekt jederzeit einsteigen. Er kann fast von Anfang an Teil des Teams sein, zum Beispiel, wenn es um die Migration von Daten aus dem ursprünglichen System in das neue System geht. Oder er kann sich dem Projekt anschließen, nachdem das System in Produktion gegangen ist, um die ersten Ergebnisse für das Unternehmen oder das Management des Kunden zu extrahieren und zu verarbeiten, indem er diese Arbeit fortsetzt und kontinuierlich verschiedene Berichte und Visualisierungen erstellt.</p><p>Wie aus der obigen Beschreibung ersichtlich ist, sind mehrere Analytiker an der Erstellung des Systementwurfs beteiligt, wobei ihre Arbeit aufeinander aufbaut. Deshalb ist eine kontinuierliche, mehr oder weniger intensive Kommunikation für alle wichtig. Eigentlich könnte man das Design der neuen Software als Symphonieorchester bezeichnen, in dem die Violine von Flöte oder Oboe, gelegentlich auch von Horn oder Pauke begleitet wird. Wenn alle Instrumente aufeinander abgestimmt sind, erklingt eine schöne Melodie, und wenn nicht, halten sich alle in der Umgebung die Ohren zu. Im Falle von Software würde ein "falsches Spiel" zu einer untauglichen Lösung führen, die den Bedürfnissen des Kunden nicht gerecht wird und darüber hinaus wahrscheinlich nicht benutzbar ist.​<br></p>
Unerwartete schlechte Praktikenhttps://cleverlance.com/de/blog/Seiten/unexpected-bad-practices.aspxUnerwartete schlechte Praktiken<p>​​​Einige Programmierpraktiken sind uns so vertraut, dass wir sie automatisch und ohne großes Nachdenken anwenden. Manchmal sind diese Techniken veraltet, manchmal werden sie im falschen Kontext angewendet. Das Ansprechen solch schlecht eingespielter Gewohnheiten stößt oft auf Ablehnung. Vor allem von denjenigen, die sie nutzen und das Thema als nützlich empfinden, also lasst uns genau das tun!</p><h3>Marks<br></h3><p>Programmier-IDEs erkennen oft bestimmte Arten von Kommentaren, um die Navigation in der Codebasis zu erleichtern. Die <em>FIXME</em>-Funktion von Xcode lässt andere Entwickler wissen, dass ein Teil des Codes mehr Aufmerksamkeit verdient. <em>TODO</em> ist hilfreich, wenn etwas, nun ja, erledigt werden soll. <em>MARK</em> unterscheidet sich von den vorherigen Fällen; es dient der Dokumentation. Die gleiche Funktion wird in IntelliJ IDEA/Android Studio als Region bezeichnet.</p><p>Markierungen unterteilen den Quellcode in mehrere Teile, indem sie Überschriften verwenden. Das kann dazu führen, dass der Code in logische Einheiten unterteilt erscheint. Wenn Sie ein Leser sind, der mit der früheren Objective-C-Ära der iOS-Entwicklung vertraut ist, wissen Sie, dass dies nur eine aktualisierte <em>#pragma mark</em>-Anweisung ist.</p><p>Typisch ist die Verwendung in Dateien mit einer großen Anzahl von Zeilen. Zeichen schaffen die Illusion von Klarheit, indem sie in vermeintlich zusammengehörende Teile zerlegt werden.</p><p>Die Verwendung von Zeichen in solchen Fällen ist eine schlechte Praxis. Entwickler missbrauchen sie oft, um eine zu große Datei zu rechtfertigen. Man sollte sich nicht auf Xcode verlassen, um den Code verständlich und lesbar zu machen. Kleine und gut komponierte Klassen sind ohne IDE-Funktionen einfacher zu verstehen und zu navigieren. Vor allem für die Überprüfer von Pull-Anfragen, die die Weboberfläche benutzen, wo diese Funktionen nicht vorhanden sind.</p><h3>Erweiterungen</h3><p>Moderne Programmiersprachen wie Kotlin oder Swift ermöglichen die Erweiterung von Klassen, Schnittstellen/Protokollen, Structs oder Enums, um eine zusätzliche Implementierung bereitzustellen. Sie können Ihren Code in mehrere Teile aufteilen, indem Sie Erweiterungen verwenden, um festzulegen, was näher zusammengehört. Eine andere Möglichkeit besteht darin, eine Erweiterung für einen anderen Typ zu erstellen, den Sie vielleicht nicht einmal besitzen, um seine Verwendung intuitiver zu gestalten. Die Möglichkeiten sind nahezu grenzenlos. Das ist nicht immer eine gute Sache, aber zunächst ein Blick in die Geschichte. </p><p>Erweiterungen gab es auch schon in Objective-C. Wenn Sie keine Erfahrung mit der Programmierung in einer solchen Sprache haben und den Namen für Erweiterungen erraten müssten, würden Sie wahrscheinlich überrascht sein. Es sind Kategorien! Eine weitere Überraschung ist, dass es auch in Objective-C Erweiterungen gibt, die jedoch anderen Zwecken dienen. Interessant ist der Unterschied zwischen den beiden Sprachen. Kategorien in Objective-C zwangen den Entwickler, sich den Namen auszudenken. Aus diesem Grund werden Dateien mit dem Namen Class+CategoryName.swift oft auch für Swift-Erweiterungen verwendet. Und noch wichtiger: Um Kategorien zu verwenden, mussten sie explizit importiert werden.</p><p>Erweiterungen in Swift sind ein unbenannter Teil des Codes. Ein solcher Code kann für den Leser komplizierter zu verstehen sein. Wenn es mehrere Erweiterungen desselben Typs gibt, kann das Hinzufügen eines Namens zum Code und die Einbettung in einen Typ die Lesbarkeit erheblich verbessern.</p><p>Die unsachgemäße Erweiterung von weit verbreiteten Typen führt zu einer Verschmutzung des Namensraums. Es ist wichtig, sich vor der Erstellung von Erweiterungen zu fragen, ob alle Instanzen des Typs eine solche Fähigkeit haben sollen. Sollten alle UIViews Zugang zu einer Blinkmethode haben? Macht eine bestimmte Unterklasse von UIView mehr Sinn?</p><p>Einige Entwickler verwenden Erweiterungen, um die Implementierung mehrerer Protokolle aufzuschlüsseln, was ebenfalls ein Warnzeichen sein kann. Wenn eine Klasse viele Protokolle implementiert, ist es vielleicht an der Zeit, sie in kleinere Klassen aufzuteilen.</p><p>Für Trolle da draußen: Sie können Ihre Kollegen wütend machen, indem Sie <em>UIView</em> mit <em>translatesAutoresizingMasksIntoConstraints</em> erweitern und beobachten, wie sie es mit <em>translatesAutoresizingMaskIntoConstraints vergleichen.</em></p><p>Aber tun Sie es nicht.</p><h3>Kommentare</h3><p>Die Möglichkeit, Kommentare zu schreiben, könnte undisziplinierte Programmierer dazu verleiten, einen Code von schlechter Qualität zu erstellen. Leider ist es einfacher, eine Variable nicht zu benennen und mit einem komplizierten, aber nicht so klaren Kommentar zu beschreiben, was in meinem Kopf vor sich geht. Leichtigkeit sollte nicht unser Ziel sein. Knappheit und Klarheit sollten es sein.</p><p>Ein guter Kommentar für einen schlecht geschriebenen Code ist immer noch ein Codegeruch. Nehmen Sie nicht nur mich beim Wort. Robert Martin erklärt: „Ein Kommentar ist ein Versäumnis, sich in einem Code auszudrücken. Wenn Sie scheitern, dann schreiben Sie einen Kommentar; aber versuchen Sie nicht zu scheitern.“</p><p>Ein weiterer Grund ist, dass sich das Verhalten des Codes ändern kann, wenn er im Repository lebt, geändert und überarbeitet wird, und dass sein Name dies überall, wo er aufgerufen wird, zum Ausdruck bringen kann. Der Kommentar wird jedoch selten aktualisiert und kann mehr verwirren als helfen.</p><p>Dokumentationskommentare erfüllen ihren Zweck sehr gut, wenn Sie eine API entwerfen, die andere verwenden sollen. Denken Sie daran, dass die API für sich selbst stehen muss, und dass Klarheit Vorrang hat. Benutzen Sie die Kommentare in der Dokumentation nicht als Entschuldigung für ein miserables Design.</p><h3>Struktur</h3><p>Die Struktur eines Projekts ist eines der ersten Dinge, die man sieht, wenn man sich eine Codebasis ansieht, und sie sollte auf den ersten Blick den Zweck der Anwendung umreißen. Es ist jedoch keine Ausnahme, dass einige Projekte Ordnerstrukturen haben, die von den Schichten der Architektur inspiriert sind, z. B. View, ViewModel, Model.</p><p>Eine Projektstruktur auf der Grundlage von Architekturschichten ist eine schlechte Praxis. Dies macht die Wiederverwendbarkeit praktisch unmöglich. Die Navigation durch eine solche Struktur ist unnötig kompliziert und wird mit zunehmendem Umfang immer schwieriger zu pflegen. Sie ist nicht skalierbar. Von der Architektur inspirierte Ordner könnten ihren Platz haben, nicht nur auf der obersten Ebene. Es sollte nicht das erste sein, was Sie sehen.<br></p><p><img src="/de/blog/PublishingImages/Articles/MobileIt/unexpected-bad-practices-01-01.png" data-themekey="#" alt="" style="margin:5px;" /><br></p><p>Überzeugen Sie sich selbst, welche Struktur Ihnen mehr über die Anwendung verrät</p><h3>Abhängigkeiten</h3><p>Open Source bietet viele Bibliotheken, die das Leben vereinfachen, von UI-Komponenten über Netzwerke bis hin zu Lösungen für die Injektion von Abhängigkeiten. Dies kann oft viel Zeit und Mühe sparen. Andererseits birgt dies verschiedene Gefahren und Einschränkungen; die Verwendung von Bibliotheken Dritter erfordert Disziplin, Ordnung und Ausgewogenheit.</p><p>Zufällig verstreute Abhängigkeiten von Dritten verringern die Robustheit erheblich. Die Abschirmung des Kerns der Anwendung und die Verwendung der Bibliotheken von den äußeren Teilen der Architektur helfen, das Risiko zu mindern. Die Abstraktion erleichtert den Prozess des Ersetzens einer Bibliothek durch eine andere.</p><p>Es ist in Ordnung, Abhängigkeiten von Drittanbietern zu verwenden, aber mit Vorsicht. Fragen Sie sich selbst: Wie viel Zeit werde ich dadurch sparen? Wie hoch ist der Aufwand für den Ersatz? Kann ich genügend Schutzmechanismen installieren, um die Anwendung zu schützen? </p><p>Der Königsweg zum Schutz Ihrer Anwendung, auch wenn dies manchmal schwierig oder unpraktisch ist, besteht darin, die Abhängigkeit nur an einer Stelle zu importieren.</p><p>Wir hatten bereits das Vergnügen, mehrere Anwendungen zu übernehmen, die aufgrund dieses Problems nicht mehr zu warten waren. Ohne Abstraktion, nicht mehr unterstützte (oder Closed-Source-) Bibliotheken haben die Codebase zersetzt. Externe Abhängigkeiten sollten Ihr Produkt niemals als Geisel halten.</p><h3>Tests</h3><p>Testgetriebene Entwicklung ist die gute Kinderstube eines Programmierers, eine Disziplin mit vielen Vorteilen. Die technischen Auswirkungen sind ein eigener Blogbeitrag, wenn nicht sogar eine ganze Serie. Nicht-technische Auswirkungen wie etwa die einfache Einarbeitung neuer Teammitglieder und eine ausführbare Dokumentation, die nicht veralten kann, sprechen für sich.</p><p>Dennoch werden sie oft vernachlässigt. Das völlige Fehlen von Tests ist der offensichtlich erste und häufigste Verstoß, gefolgt vom Schreiben von Tests nach dem Produktionscode, was alle Vorteile abschwächt und andere Hindernisse mit sich bringt.</p><p>Sie müssen zuerst Unit-Tests schreiben - vor dem Produktionscode. Wenn Sie zuerst testen, verhindern Sie, dass Sie einen zu komplexen Code erstellen. Er führt Sie durch den Bau von Bauteilen in der richtigen Größe. Die großen Klassen sind schwierig zu testen, und die Tests werden Sie anweisen, sie in kleinere Klassen zu zerlegen.</p><p>Tests, die nach dem Produktionscode geschrieben werden, sind von Natur aus von geringerer Qualität und können sogar irreführend sein. Solange Sie den Produktionscode nicht als Beweis für den ersten fehlgeschlagenen Test schreiben, ist es unmöglich zu sagen, ob die Tests das behaupten, was sie deklarieren. Es ist dann fraglich, wie gut solche Tests das zu prüfende System schützen.</p><p>Wenn Sie Tests erst nach der Implementierung schreiben, kann es sein, dass eine Komponente schwierig zu testen ist, was bei einem Test-first-Ansatz unmöglich ist. Sie können keinen untestbaren Code erstellen!</p><h3>Der Teufel steckt im Detail</h3><p>Selbst das Alltägliche kann schädlich sein, wenn wir etwas zu automatisch und mit weniger Aufmerksamkeit tun. Stellen Sie das Gewöhnliche in Frage und suchen Sie nach schlechten Praktiken, die Sie nicht erwarten würden.​​<br></p>
Mai im Namen des Designshttps://cleverlance.com/de/blog/Seiten/graphics-for-children-II.aspxMai im Namen des Designs<p>​Alle Mittwoche im Mai und den ersten Mittwoch im Juni haben wir dem Thema Grafik und Design gewidmet. Die Kreativabteilung von QUB hat einen fünfteiligen Kurs zur Druckgrafik für Kinder vorbereitet. Wir haben den Unterricht in fünf einstündigen Online-Sitzungen abgehalten und waren begeistert von dem, was die 11 kleinen Designer im Alter von 7-12 Jahren während des Kurses geleistet haben. Übrigens haben <a href="/de/blog/Seiten/graphics-for-children.aspx" target="_blank">Sie vielleicht den Artikel der zwölfjährigen Vika gelesen</a>.<br></p><p>Wir gingen von den Grundlagen aus - wir erklärten die Grundlagen der Farbtheorie, gingen auf die interessanten Fakten der Pigmenterzeugung ein und schlossen die erste Lektion mit der Erstellung einer Farbpalette ab, die für den Beginn eines jeden Designprojekts unerlässlich ist.</p><p>Während des zweiten Treffens haben wir uns kurz mit der Geschichte beschäftigt. Von Piktogrammen, Hieroglyphen und Höhlenmalereien gelangten wir zur Einteilung der Typografie in expressiv und funktional und die Kinder lernten unter anderem, zwischen Serifeschrift und serifeloser Schrift zu unterscheiden. Seien Sie darauf gefasst, dass Sie die kleinen Designer zu Hause mit interessanten Fakten über den Aufbau von Schriften verblüffen und richtig behaupten werden, dass einige Zeichen Bäuche, Schwänze und Augen haben und dass der Kegel nicht nur beim Bowling vorkommt! Zum Abschluss der Stunde haben wir die richtige Spationierung (Festlegung der Abstände) der Schrift geübt.</p><p>Beim dritten Treffen entdeckten wir gemeinsam, dass der Stil der Comic-Helden mit schwarzen Umrissen seinen Ursprung im traditionellen japanischen Holzschnitt und in Jugendstilplakaten hat. Wir gaben Tipps, wie man eine Geschichte dynamisch gestalten und mit Sprechblasen arbeiten kann, und machten deutlich, dass eine Comic-Geschichte einen Helden, eine Handlung, einen Schauplatz und einen einheitlichen grafischen Stil haben sollte. Gemeinsam haben wir einen kurzen Strip zum Thema "Überraschung" erstellt.</p><p>In der vierten Lektion beschäftigten wir uns mit dem Verpackungsdesign, übten die erworbenen Kenntnisse über Farben und Typografie und stellten die kleinen Designer vor eine schwierige Aufgabe - die Gestaltung der Verpackung einer Bonbontüte. Auch hier gingen wir wie gewohnt vor, indem wir mit der Recherche begannen und Details und Unterschiede zwischen z. B. Frucht- und Schokoladenbonbons festhielten. Die Kinder waren sehr kreativ und haben nicht nur die Verpackungen gestaltet, sondern auch Ideen für die Namen der neuen Bonbons entwickelt: Würden Sie zum Beispiel Hühnerschnäbel interessant finden?</p><p>In den ersten vier Lektionen haben wir bewusst den Computer gemieden und mit Entwürfen auf Papier gearbeitet (wieder wie in der Designpraxis). In der fünften und letzten Lektion versuchten wir, in den Grafikeditor einzusteigen und stellten den Kindern <a href="https://www.figma.com/" target="_blank">Figmu</a> vor. Wir haben versucht, unser Bonbontüten-Design in einen Computer zu übertragen. Die Kinder haben auch diese letzte (beinahe) Feuerprobe bestanden und wir sammeln derzeit alle ihre Kreationen ein.<br></p><p><em>Für </em><a href="https://qub.digital/en/our-work" target="_blank"><em>QUB Digital​</em></a><em> Ivana Stránská, Michal Hořava und Jan Čermák</em><br></p>
Grafiken für Kinder mit den Augen von Vikyhttps://cleverlance.com/de/blog/Seiten/graphics-for-children.aspxGrafiken für Kinder mit den Augen von Viky<p>​​Die zwölfjährige Viky hat eine tolle, authentische Reportage über einen von Cleverlance organisierten Grafikkurs für Kinder geschrieben, die unbearbeitet veröffentlicht wurde.</p><h3>1. Lektion</h3><p>Gleich zu Beginn der 1. Lektion stellten wir uns den übrigen Teilnehmern vor, wie wir es in anderen Kursen auch tun, aber wir sagten noch dazu, was wir lernen möchten. Nach der Vorstellung konnte die Lektion beginnen. Zuerst wurde uns die Farbe des Jahres vorgestellt (die Very Peri heißt) und wie wichtig sie für den Designer ist. Der Designer verwendet die Farbe des Jahres eigentlich fast überall. Wir haben auch über den Farbkreis gesprochen, an dem man den Kontrast von Farben wunderschön erkennen kann. Anschließend wurde uns die Geschichte der Farben präsentiert. Es ist sehr interessant, dass man schon in prähistorischen Zeiten weiße Farbe verwende, denn Weiß ist schwierig und nur mit Hilfe gewisser Chemikalien zu gewinnen. Und die Römer mochten zum Beispiel verschiedene Brauntöne, also einen gewissen romantischen Stil. Ein weiteres Thema war das Pigment. Je nachdem, welches Bindemittel man dem Pigment beimischt, entstehen unterschiedliche Farben. In der Vergangenheit wurden Honig, Öl oder Ei als Bindemittel verwendet. Wenn man z. B. Honig als Bindemittel in dem Pigment beimischt, erhält man Aquarellfarben, und wenn man das Gleiche mit Ei macht, entstehen Temperafarben. Das letzte Thema war, welche verschiedenen Steine zur Herstellung verschiedener Farben verwendet werden. Gelb wird zum Beispiel aus Vulkangestein hergestellt, und Weiß wird interessanterweise aus schwarzem Gestein hergestellt, auch wenn es chemisch behandelt wird, aber das tut nichts zur Sache. Am Ende der Stunde bekamen wir die "Hausaufgabe", uns eine eigene Farbpalette für die nächste Woche auszudenken. Es hat mir sehr viel Spaß gemacht und ich freue mich auf weitere Grafiklektionen.​<br></p><p><img src="/de/blog/PublishingImages/Articles/CreateIt/viki1.jpg" data-themekey="#" alt="" style="margin:5px;" /><br></p><h3>2. Lektion</h3><p>In der 3. Lektion haben wir uns über die Typografie unterhalten. Zunächst haben wir über die Geschichte der Schrift gesprochen. Die allererste Schrift war die in Ägypten erfundene Hieroglyphenschrift, die sehr zeitaufwändig war. Stellen Sie sich vor, Sie müssten wegen einem einzigen Wort eine Ente zeichnen. Eine andere Schrift wurde von den Phöniziern erfunden, die erste Silbenschrift, aus der sich die heutige lateinische Schrift entwickelte. Eines der vorletzten Themen war, dass wir uns erklärten, was Serifeschrift und serifelose Schrift ist. Im Moment benutze ich serifelose Schrift. Weiter was Versalbuchstaben und Kleinbuchstaben sind. Und das vorletzte Thema war die Erklärung, was Plakatschrift und Zeitungsschrift ist. Plakatschrift soll ins Auge fallen und Eindruck machen, aber manchmal ist sie fast unlesbar. Andererseits muss die Zeitungsschrift gut zu lesen sein. Als Letztes hat man uns einen Link zur Website an den Chatroom geschickt. Dort konnten wir üben, wie man Buchstaben in Überschriften setzt und so weiter. Wie beim letzten Mal bekamen wir "Hausaufgaben", aber dieses Mal mussten wir unseren Namen zeichnen oder malen (siehe Bild in der Kopfzeile des Artikels). Wie beim letzten Mal hat es mir wieder sehr gut gefallen und ich freue mich schon auf das nächste Mal.</p><h3>3. Lektion</h3><p>In der 3. Lektion haben wir uns mit Comics beschäftigt. Das allererste Thema, das wir besprachen, waren die Fenster, und wir haben darüber gesprochen, dass die Fenster auf verschiedene Weise angeordnet sein können, um die Aufmerksamkeit des Lesers zu erregen. Dann solche Schattierungen in einem Schwarz-Weiß-Comic, dass z.B. das 1. Fenster grau ist, das 2. und 3. Fenster weiß und so weiter. Mitten der Lektion haben wir versucht, unser eigenes Comic zu zeichnen, aber nur einen Strip. Das ist ein Comic mit zwei oder drei Fenstern. Sobald wir unseren "Comic" beendet hatten, war die Stunde vorbei. Ich habe es sehr genossen und freue mich auf das nächste Mal.<br></p><p><img src="/de/blog/PublishingImages/Articles/CreateIt/viki2.jpg" data-themekey="#" alt="" style="margin:5px;" /><br></p><h3>4. Lektion</h3><p>In der 4. Lektion haben wir unsere eigene Bonbontüte gemalt und erfunden. Zuerst mussten wir uns einen Namen erfinden, und mir fiel der Name Japans ein. Es folgte die Schriftart, und als wir eine Bleistiftskizze fertig hatten, haben wir eine Farbpalette erfunden. Nachdem wir den Namen gefärbt hatten, gestalteten wir das Design des Geschmacksbilds: Wassermelone, Marshmallows usw. Ringsherum Blätter oder etwas anderes. Wir mussten auch das Gewicht und den Geschmack (nur sicherheitshalber) anführen. Dabei erzählten uns Michal und Ivana von Kontrasten und dem Goldenen Schnitt. Am Ende der Unterrichtsstunde haben wir ihnen unsere Bonbontüte vorgeführt. Sie machten uns Komplimente und forderten uns auf, einen interessanten Hintergrund zu gestalten und für sie ein Foto davon zu machen. Wie jede Grafiklektion hat es mir Spaß gemacht, und wir konnten die Typografie und die Auswahl von Farben üben, die zueinander passen.</p><h3>5. Lektion </h3><p>Bei der 5. Lektion haben wir mit Figma gearbeitet. Wir haben die Bonbontüte vom letzten Mal in den Computer übertragen und neu bearbeitet. Zuerst stellten wir das Papierformat und die Farbe ein. Dann haben wir die Überschrift erstellt und sie bearbeitet. Wir haben auch verschiedene Formen eingegeben und haben auf einer Website verschiedene Vektorbilder gefunden. Wir sollten die Aufgabe bis nächste Woche fertig machen und schicken. Und derjenige mit dem schönsten Entwurf bekommt eine Tüte Bonbons. Alle Grafiklektionen waren super und die 3. Lektion hat mir wahrscheinlich am meisten Spaß gemacht. An weiteren Lektionen würde ich auf jeden Fall teilnehmen.<br></p><p>Bleiben Sie dran, und wir werden Ihnen bald die Kreationen der übrigen Kursteilnehmer vorstellen - denn wer würde nicht gerne die schönste Tüte mit Bonbons sehen!​<br></p>

​