In den Jahren 2017-2019 gab es einen signifikanten Anstieg von TypeScript. Dies geschah aus offensichtlichen Gründen. In dieser Sprache steckt viel Gutes. Fast die Hälfte
der Befragten
des JavaScript- Status 2018 hat TypeScript bereits ausprobiert und plant, in Zukunft darüber zu schreiben. TypeScript ist sehr beliebt, aber lohnt es sich, es in großen Softwareprojekten zu verwenden?
In diesem Material wird ziemlich streng versucht, basierend auf den numerischen Indikatoren und der praktischen Erfahrung des Autors, die Auswirkungen der Verwendung von TypeScript bei der Entwicklung großer Projekte zu analysieren.
Informationen zum TypeScript-Wachstum
TypeScript ist eine der am schnellsten wachsenden Sprachen. Derzeit ist es die führende Sprache der in JavaScript kompilierten Sprachen. Hier sind die TypeScript-Daten von Google Trends.
2014-2019 Google Trends-Daten zur TypeScript-BeliebtheitsdynamikDas Folgende sind
Informationen von GitHub, die das Interesse der Programmierer an der Arbeit an der Entwicklung verschiedener Programmiersprachen widerspiegeln.
GitHub-Daten zum Wachstum der Programmiersprachen in Bezug auf die Anzahl der MitwirkendenDie oben genannten Indikatoren sind sehr beeindruckend und weisen auf die wachsende Popularität von TypeScript hin, die nicht zu unterschätzen ist. Es sollte jedoch beachtet werden, dass TS noch lange nicht als die führende Sprache des JavaScript-Ökosystems anerkannt ist. Wenn das JavaScript-Ökosystem mit dem Ozean verglichen wird, wird TypeScript eine große Welle in diesem Ozean sein. Hier ist ein Vergleich von JavaScript (rote Linie) und TypeScript (blaue Linie) gemäß Google Trends.
2014-2018 Google Trends-Daten zur Dynamik der Popularität von JavaScript und TypeScriptUnd hier finden Sie
Informationen von GitHub zu den führenden Programmiersprachen, mit denen 2008-2018 Repositorys erstellt wurden.
GitHub-Daten zur Anzahl der mit verschiedenen Programmiersprachen erstellten RepositorysAn der Anzahl der Repositorys können Sie erkennen, dass TypeScript nicht zu den fünf wichtigsten Sprachen gehört.
Es sollte beachtet werden, dass es 2018 einen Wendepunkt in der Geschichte von TypeScript gab, und 2019 wird diese Sprache in vielen realen Projekten verwendet. Wenn Sie ein JavaScript-Entwickler sind, haben Sie unter solchen Bedingungen einfach keine Wahl. Die Entscheidung, TypeScript in einem Projekt zu verwenden, an dem Sie arbeiten müssen, wird bereits getroffen, ohne Ihre Meinung zu berücksichtigen. Sie müssen keine Angst haben, TypeScript zu lernen und zu verwenden.
Wenn Sie jedoch entscheiden, welche Sprache in einem Projekt verwendet werden soll, müssen Sie die Stärken und Schwächen von TypeScript realistisch verstehen. Wenn Sie Entscheidungen treffen, müssen Sie verstehen, ob sich die Wahl von TypeScript gut oder schlecht auf das Projekt auswirkt.
Meine Erfahrung zeigt, dass TypeScript Vor- und Nachteile hat, aber es kann nicht gesagt werden, dass sich seine Verwendung im Allgemeinen positiv auf Projekte auswirkt. TypeScript hat viele Entwickler angesprochen, und viele Dinge hängen mit dieser Sprache zusammen, die ich, die ich sie in der Praxis getestet habe, wirklich mag. Aber du musst für alles bezahlen.
Hintergrund
Ich bin aus der Welt der statisch typisierten Sprachen wie C / C ++ und Java zu JavaScript gekommen. Anfangs fiel es mir schwer, mich an die dynamische Typisierung in JavaScript anzupassen, aber sobald ich mich daran gewöhnt hatte, fühlte ich mich wie eine Person, die den Ausgang eines langen dunklen Tunnels erreichte und das Licht sah. Statische Typisierung hat viele positive Eigenschaften, aber das Gleiche gilt für die dynamische Typisierung.
In den letzten Jahren habe ich mich regelmäßig kopfüber in die TypeScript-Entwicklung gestürzt. Infolgedessen habe ich über ein Jahr TypeScript-Übung gewonnen. Ich leitete mehrere große Teams, die TypeScript als Hauptsprache verwendeten. Dadurch konnte ich die Auswirkungen von TypeScript auf die Entwicklung großer Projekte bewerten und ähnliche Projekte mit ähnlichen Projekten vergleichen, die reguläres JavaScript verwendeten.
Im Jahr 2018 könnten dezentrale Anwendungen
starten . Die meisten dieser Anwendungen verwendeten intelligente Verträge und Open Source-Lösungen. Bei der Entwicklung von Anwendungen für das Internet of Value können Fehler in Programmen Benutzer Geld kosten. Es ist heute wichtiger denn je, zuverlässigen Code zu schreiben. Da solche Projekte normalerweise Open Source sind, fand ich, dass das, was wir bei der Entwicklung von TypeScript verwenden, gut ist, da dies anderen TypeScript-Teams die Arbeit mit unseren Lösungen erleichtert und gleichzeitig die Kompatibilität gewährleistet unser Code mit Projekten, die JavaScript verwenden.
Während des praktischen Gebrauchs von TypeScript begann ich, die Vor- und Nachteile dieser Sprache besser zu verstehen. Mir wurde auch klar, welche Art von Auswahl TypeScript für ein Softwareprojekt haben könnte. Ich muss leider sagen, dass die Erfahrung mit TypeScript nicht so erfolgreich war, wie ich wollte. Wenn TypeScript nicht wesentlich verbessert wird, werde ich diese Sprache nicht für ein anderes Großprojekt auswählen.
TypeScript-Stärken
Auf lange Sicht scheint mir TypeScript immer noch eine positive Entwicklung zu sein. Ich möchte diese Sprache lieben und ich mag definitiv einige ihrer Funktionen. Ich hoffe, dass TypeScript-Entwickler und ihre Befürworter konstruktive Kritik in diesem Material sehen und keine grundlosen Angriffe auf diese Sprache. TypeScript-Entwickler können einige ihrer Mängel beheben. In diesem Fall kann ich meine Analyse der Wirksamkeit dieser Sprache wiederholen und unterschiedliche Ergebnisse erzielen.
Statische Typisierung kann sehr nützlich sein, da sie dazu beiträgt, Funktionen zu dokumentieren, den Code verständlicher zu machen und die kognitive Überlastung des Programmierers zu verringern. Zum Beispiel finde ich normalerweise, dass das System vom Typ Haskell funktioniert, ohne zu viel Zeit und Mühe zu benötigen, bequem und unauffällig. Aber manchmal erschweren sogar das flexible Haskell-Typsystem und seine höherwertigen Typen die Arbeit. Versuchen Sie beispielsweise, einen Schallkopf mit Haskell oder TypeScript einzugeben. Dies ist nicht einfach, und möglicherweise ist das Ergebnis etwas schlechter als das untypisierte Äquivalent.
Ich mag die Tatsache, dass TypeScript-Annotationen optional sein können, wenn sie stören. Ich mag die Tatsache, dass TypeScript strukturelle Typisierung verwendet und dass Typinferenz unterstützt wird (obwohl es in diesem Bereich viele Verbesserungsmöglichkeiten gibt).
TypeScript unterstützt Schnittstellen, die wiederverwendbar sind (im Gegensatz zu integrierten Typdeklarationen). Schnittstellen können auf verschiedene Arten zum Kommentieren von APIs und Funktionssignaturen verwendet werden. Eine einzelne Schnittstelle kann viele Implementierungen haben. Schnittstellen sind eine der besten Funktionen von TypeScript, und ich möchte, dass etwas Ähnliches in normalem JavaScript angezeigt wird.
Eine der Stärken von TypeScript ist das Toolkit. Die Verwendung eines geeigneten Editors (wie Atom oder Visual Studio Code), für den hochwertige TS-Plug-Ins erstellt werden, stellt dem Entwickler beispielsweise die besten Tools im JavaScript-Ökosystem zur Verfügung. Entwickler anderer Plug-Ins sollten TS-Plugins studieren und darüber nachdenken, wie sie mit den darin enthaltenen Ideen ihre Entwicklung verbessern können.
TypeScript-Leistungsanalyse
Jetzt werde ich TypeScript für mehrere Indikatoren bewerten und Noten im Bereich von -10 bis 10 festlegen. Auf diese Weise können Sie besser verstehen, wie gut (oder schlecht) TypeScript auf große Projekte wirken kann.
Wenn die Punktzahl auf dem Indikator 0 überschreitet, zeigt dies die positiven Auswirkungen von TypeScript auf das Projekt an. Wenn die Punktzahl kleiner als 0 ist, weist dies auf eine negative Auswirkung hin. Ein Bewertungswert von 3-5 Punkten zeigt einen ziemlich starken Effekt an. 2 Punkte geben die durchschnittliche Exposition an. 1 Punkt ist ein relativ schwacher Effekt.
Die Zahlen, mit denen ich weiterarbeiten werde, sind schwer genau zu messen. In meinen Einschätzungen werde ich bis zu einem gewissen Grad subjektiv sein. Ich habe jedoch versucht, diese Schätzungen so vorzunehmen, dass sie die Vor- und Nachteile der Verwendung von TypeScript in realen Projekten so realistisch wie möglich aufzeigen.
Alle von mir analysierten Projekte mit Noten enthielten mehr als 50.000 Codezeilen. Sie waren das Ergebnis der mehrmonatigen Arbeit mehrerer Programmierer. Eines dieser Projekte basiert auf Angular 2 und verwendet TypeScript. Es wurde mit einem ähnlichen Projekt verglichen, das mit Angular 1 und regulärem JavaScript geschrieben wurde. Alle anderen Projekte basieren auf React und Node mit TypeScript. Sie wurden mit ähnlichen Projekten verglichen, die einfaches JavaScript verwendeten. Einige Indikatoren, wie z. B. die Fehlerdichte, wurden nur annähernd geschätzt. Alle Teams, die an Projekten arbeiteten, bestanden aus erfahrenen und unerfahrenen TypeScript-Entwicklern. Alle Mitglieder solcher Teams hatten die Möglichkeit, mit erfahreneren Mentoren zu interagieren, die ihnen bei der Anpassung im Bereich der TypeScript-Entwicklung halfen.
Aufgrund der geringen Stichprobengröße sind die objektiven Daten, die ich habe, zu heterogen, es gibt zu viel Rauschen in ihnen, daher ist es aufgrund dieser Daten unmöglich, bestimmte objektive Beurteilungen vorzunehmen, die auf der Grundlage ausreichend genauer Zahlen und ohne zu viel Risiko getroffen werden könnten einen großen Fehler machen. Ein JavaScript-Projekt wies eine Fehlerdichte in der Produktion auf, die 41% unter der eines vergleichbaren TypeScript-Projekts lag. In einem anderen Vergleich zeigte ein TypeScript-Projekt eine um 4% geringere Fehlerdichte als ein vergleichbares JavaScript-Projekt. In diesem Fall ist es offensichtlich, dass die Anzahl der Fehler, die die Produkteinführungsphase erreicht haben, nicht durch die Verwendung von TypeScript im Projekt, sondern durch das Vorhandensein oder Fehlen anderer Maßnahmen zur Sicherstellung der Qualität des Codes wesentlich stärker beeinflusst wird. Dies verzerrt die Indikatoren so stark, dass es unmöglich wird, sie zu verwenden.
Eine solch breite Palette objektiver Indikatoren führte dazu, dass ich mich entschied, sie nicht zu verwenden, wobei ich mich auf das Tempo der Umsetzung der Projektfähigkeiten und auf Beobachtungen konzentrierte, die auf die Bereiche des Projektlebenszyklus hinweisen, in denen die meiste Zeit verbracht wurde. Im Folgenden werden wir bei der Analyse der Indikatoren ausführlicher darauf eingehen.
Da meine Analyse eine starke subjektive Komponente aufweist, müssen Sie die Möglichkeit von Ungenauigkeiten bei der Interpretation von Indikatoren berücksichtigen (dies spiegelt sich im Diagramm wider). Die allgemeinen Schlussfolgerungen dieser Analyse können jedoch ein realistisches Bild davon liefern, was Sie von der Verwendung eines TypeScript-Projekts erwarten können.
TypeScript-LeistungsanalyseIch kann bereits die Einwände bezüglich der niedrigen Bewertungen der TypeScript-Vorteile hören, und ehrlich gesagt kann ich diese Einwände nicht vollständig zurückweisen. TypeScript bietet dem Programmierer tatsächlich einige sehr nützliche und leistungsstarke Funktionen. Daran kann kein Zweifel bestehen.
Um den Grund für die vergleichsweise niedrigen und seltenen positiven Bewertungen in meiner Analyse zu verstehen, sollten Sie gut verstehen, womit ich TypeScript vergleiche. Dies ist nicht „nur JavaScript“, sondern JavaScript und Tools, die für eine effektive Entwicklung in dieser Sprache entwickelt wurden.
Betrachten Sie die im Diagramm gezeigten Indikatoren.
▍ Entwicklertooling
Toolkit ist meine Lieblings-TypeScript-Funktion, was wahrscheinlich der größte praktische Vorteil der Verwendung dieser Sprache ist. Dank hochwertiger Tools wird die kognitive Belastung des Entwicklers reduziert. Ihm stehen Tipps zu den Arten von Schnittstellen zur Verfügung, dabei werden in Echtzeit potenzielle Fehler abgefangen. Wenn bei der Entwicklung in einfachem JavaScript mit guten Plugins nichts dergleichen passiert wäre, würde ich TypeScript eine höhere positive Bewertung geben. In unserem Fall können Sie jedoch bereits 0 Punkte verwenden, wenn Sie in JavaScript programmieren. Das heißt, mit dem wir TypeScript vergleichen, ist es bereits auf einem ziemlich hohen Niveau.
Die meisten Befürworter von TypeScript scheinen nicht sehr gut zu verstehen, womit TypeScript konkurriert. Der Punkt ist, dass die Auswahl der Werkzeuge keine Entscheidung darüber ist, ob TypeScript oder JavaScript ohne Hilfswerkzeuge verwendet werden soll. Es geht darum, zwischen TypeScript und dem gesamten umfassenden Ökosystem an JavaScript-Entwicklungstools zu wählen. Tools zur Code-Vervollständigung und Fehlererkennung für gängiges JavaScript bieten 80-90% der typischen TypeScript-Stärken. Dies ist beispielsweise der
Fall , wenn Tools zur Code-
Vervollständigung , Tools zur
Ausgabe von Typen und
Linters verwendet werden . Bei Verwendung des Typinferenzsystems und bei Anwendung der in ES6 angezeigten Standardfunktionsparameter stehen dem Entwickler Tipps zur Verfügung, die denen sehr ähnlich sind, die bei der Arbeit an TypeScript-Code mit Typanmerkungen verfügbar sind.
Ein Beispiel für die automatische Vervollständigung von regulärem JS-Code mit TypinferenzWenn Sie die Standardeinstellungen verwenden, um Typhinweise bereitzustellen, müssen Sie den TypeScript-Code unbedingt nicht mit Anmerkungen versehen. Dies ist eine hervorragende Technik, um die Anzahl der Hilfssyntaxkonstrukte zu reduzieren, die einer der Nachteile von TypeScript sind.
Die Tools zum Schreiben von TypeScript-Code sind vielleicht etwas besser, sie sehen ganzheitlicher aus, aber all dies reicht nicht aus, um TypeScript eine viel höhere Bewertung zu geben und die Mängel dieser Sprache zu decken.
▍ API-Dokumentation
Ein weiterer großer Vorteil von TypeScript ist die bessere API-Dokumentation. Tatsächlich können wir sagen, dass die Dokumentation für die API immer dem Status des Quellcodes entspricht. Die Dokumentation kann sogar basierend auf TypeScript-Code erstellt werden. Für diesen TypeScript-Indikator könnte man auch eine höhere Note geben - wenn man beim Programmieren in JavaScript nicht so etwas wie
JSDoc ,
Tern.js und viele Tools zum Generieren von Dokumentation verwenden könnte. Persönlich bin ich kein Fan von JSDoc, daher wird TypeScript in meiner Analyse zu diesem Indikator sehr geschätzt.
Es sollte beachtet werden, dass man selbst mit der besten Dokumentation, die in den Code der Welt integriert ist, nicht auf echte Dokumentation verzichten kann. Daher kann man mit Recht sagen, dass TypeScript-Funktionen die vorhandenen Dokumentationskompilierungsfunktionen eher erweitern als ersetzen.
▍ Typensicherheit
Wie sich herausstellte, ist es beim Vergleich der Typensicherheit von TS und JS nicht möglich, einen besonderen Unterschied festzustellen. Befürworter von TypeScript sprechen häufig über die Vorteile der Typensicherheit, aber es kann nicht gesagt werden, dass die Typensicherheit die Fehlerdichte in der Produktion erheblich verringert. Dies ist ein wichtiger Punkt, da die Verwendung von Codeüberprüfung und TDD schwerwiegende Auswirkungen auf die Fehlerbehebung hat (allein die Verwendung der
TDD- Technik reduziert Fehler um 40-80%). Wenn Sie TDD mit einer Analyse der Projektarchitektur, einer Überprüfung der Spezifikationen und Codeüberprüfungen kombinieren, können Sie die Fehlerdichte um mehr als 90% reduzieren. Viele dieser Techniken (insbesondere TDD) können Ihnen dabei helfen, dieselben Fehler zu finden, die mit TypeScript erkannt werden können, sowie viele Fehler, die TypeScript nicht erkennen kann.
Hier geben wir einige Berechnungen aus
dieser Studie . Das theoretische Maximum an "öffentlich verfügbaren" Fehlern, die von TypeScript erkannt werden können, liegt bei etwa 15%. "Öffentliche" Fehler sind Fehler, die die Projektentwicklungsphase überstehen und in einem öffentlichen Repository landen.
Die oben genannte Studie überwachte Fehler, die im Voraus bekannt waren. Dies beinhaltete das Wissen, welche Codezeilen geändert wurden, um Fehler zu korrigieren, während das Problem und seine mögliche Lösung bekannt waren, bevor der Code eingegeben wurde. Dies bedeutet, dass selbst bei Kenntnis des Vorhandenseins von Fehlern mit TypeScript 85% der "öffentlichen" Fehler nicht erkannt werden konnten.
Warum kann TypeScript nicht so viele Fehler erkennen? Warum sage ich, dass 15% der erkannten Fehler das theoretische Maximum von TypeScript sind? Zunächst ist anzumerken, dass Fehler in den Spezifikationen gemäß der fraglichen Studie zu ungefähr 78% der Fehler in öffentlichen GitHub-Repositories führen. Die Unfähigkeit, die Spezifikationen der Programme klar zu formulieren, oder die Unfähigkeit, die Spezifikationen korrekt umzusetzen, führen zu der häufigsten Art von Fehler. Dies führt automatisch dazu, dass die meisten Fehler in TypeScript-Softwareprojekten nicht erkannt oder verhindert werden können. Die Autoren der Studie identifizieren und klassifizieren unter anderem Fehler, die von TypeScript nicht erkannt werden. Hier ist ein Balkendiagramm mit Informationen zu solchen Fehlern.
Fehler, die von TypeScript nicht erkannt werdenDas Beispiel "StringError" ist ein Fehler, der auftritt, wenn eine Zeichenfolge verwendet wird, wenn eine Zeichenfolge benötigt wird, dh, es treten keine Fehler in Typen auf, aber der Inhalt dieser Zeichenfolge selbst verursacht einen Fehler (z. B. kann eine falsche URL vorhanden sein). Mithilfe der statischen Analyse können Sie einige dieser Fehler identifizieren, indem Sie den Inhalt von Zeichenfolgen untersuchen und Beschreibungen dieses Inhalts verwenden. Dies gibt jedoch nur die Aussicht, einen kleinen Bruchteil eines kleinen Prozentsatzes von Fehlern zu korrigieren. Aus diesem Grund ist es unwahrscheinlich, dass TypeScript jemals mehr als 15 bis 18% der Fehler erkennen kann.
Hier scheint es, dass 15% schon ziemlich viel sind. Warum kann TypeScript einen viel größeren Prozentsatz an Fehlern nicht erkennen?
Da es viele Fehler gibt, die durch statische Typisierung nicht erkannt werden können, wäre es unverantwortlich, die Verwendung anderer Methoden der Qualitätskontrolle wie Codeüberprüfung und TDD abzulehnen. Daher ist es unfair, sich auf die Tatsache zu verlassen, dass TypeScript das einzige Werkzeug eines Projekts ist, das zur Behandlung von Fehlern verwendet wird. Um den betrachteten Indikator unserer Analyse der Wirksamkeit von TypeScript realistisch wahrzunehmen, lohnt es sich, die potenzielle Anzahl der von TypeScript erkannten Fehler zu berechnen, nachdem die von anderen Methoden erkannten Fehler von ihrer Anzahl ausgeschlossen wurden.
Angenommen, Ihr Projekt würde 1000 Fehler enthalten, wenn Sie keine Maßnahmen zur Fehlerbehebung ergriffen hätten. Nachdem das Projekt ordnungsgemäß getestet wurde, wurde die potenzielle Anzahl von Fehlern, die die Produktion erreichen können, auf 100 reduziert. Um die tatsächlichen Möglichkeiten von TypeScript zu sehen, schauen wir uns an, wie viele dieser Fehler mithilfe von TypeScript erkannt werden können. Da etwa 80% der Fehler mit TypeScript nicht erkannt werden können und theoretisch alle mit TypeScript erkannten Fehler mit anderen Methoden wie der TDD-Methode erkannt werden können, werden wir recht großzügig ankommen und davon ausgehen, dass TypeScript dies erkennt weitere 8% der Fehler. Hier gehen wir außerdem davon aus, dass wir nicht etwa die Hälfte der Fehler gefunden haben, die TypeScript auf andere Weise erkennt. Das Ergebnis ist folgendes:
- Ein Projekt, in dem keine Fehlerkontrollmaßnahmen angewendet werden, enthält 1000 Fehler.
- Mithilfe von Maßnahmen zur Bekämpfung von Nicht-TypeScript-Fehlern wurden 900 Fehler festgestellt.
- Nach Überprüfung des Projekts mit TypeScript blieben 92 Fehler übrig. Dies bedeutet, dass dank der Implementierung von TypeScript weitere 8 Fehler erkannt wurden.
, , TDD, , TypeScript- , , . . TypeScript . TypeScript, .
, TypeScript, TypeScript 15% . — 150 1000. , , TypeScript, 900 . , , , TypeScript - . TypeScript , , , 908 1000 (, , , , TypeScript).
. , 30-80% . :
, , , , , , , TypeScript. : TypeScript . , . .
, , - TypeScript. TypeScript, ?
▍ JavaScript - (New JS Features, Compile to Cross-Browser JS)
TypeScript 0, JavaScript. , Babel JavaScript , , , .
TypeScript JavaScript. , . JavaScript , , , , TypeScript , . , , TypeScript «».
▍ (Recruiting)
, State of JavaScript, TypeScript , 33.7% TypeScript. 5.4% TS , , 13.7% , . TS- 20%, , . — , (, , , ).
, - , TypeScript . . , TypeScript .
▍ , (Setup, Initial Training)
, . , JavaScript, TypeScript- 2-3 , 6-8 . , , , , , , TypeScript, , .
▍ (Missing Features)
, , . TypeScript JavaScript. TypeScript , . , JavaScript- , , . , , , TypeScript .
TypeScript TypeScript. , , , . , , TypeScript- . , , , , .
▍ (Ongoing Mentorship)
TypeScript, . , , , . TypeScript -. , , , , , .
, TypeScript- , , , , . , , , , , .
. . , TypeScript-, - , . « » — , , . , — , TypeScript .
▍ , (Typing Overhead)
, , , . — TypeScript, . . , , .
, , . , , , . , , , .
, . , , .
, TypeScript « ». Haskell , . TypeScript, , , , , .
, TypeScript- . — , TypeScript- , , , , . TypeScript- , , . , , — .
« » . , .
« » — , . « » — .
« » — TypeScript. :
- . «» ( — Haskell).
- , , , . TypeScript- , , , , , , . , , TypeScript-, Stack Overflow.
TypeScript, , . , , .
, TypeScript , , .
TypeScript , . TypeScript , , , . TypeScript, TypeScript- , TypeScript.
, TypeScript , , « » TypeScript . , TypeScript-, .
TypeScript, , , , — , , TypeScript. TypeScript . , — , , TypeScript.
.
TypeScript , «JavaScript, ». : «JavaScript, ».
! TypeScript.
