JetBrains Way to C++ : l’histoire intérieure de notre voyage

JetBrains Way to C++ : l’histoire intérieure de notre voyage

Dans les coulisses
Nouveaux produits

Introduction

Au cours des 15 dernières années, JetBrains a fourni aux développeurs de logiciels des outils pour les rendre plus productifs, travailler plus rapidement et résoudre des tâches banales de manière automatique. Des IDE intelligents et éditeurs de code aux outils collaboratifs, le portefeuille JetBrains couvre de nombreux aspects du développement logiciel et prend en charge un vaste ensemble de langages de programmation.

2015 a été une année spéciale pour nous avec l’introduction en avril de ReSharper C++ et CLiondeux produits entièrement nouveaux destinés aux développeurs C et C++.

Nous avons maintenant beaucoup de Cas d’utilisation du développement C et C++ couvert. Tous nos outils C++ supportent nativement C et C++, y compris le standard C++11 (avec certaines limitations), libc++ et Boost, et gèrent correctement les macros et les modèles.

ReSharper C++ est une extension pour Microsoft Visual Studio, prenant en charge le compilateur Microsoft Visual C++ et la chaîne de ressources Visual Studio associée. CLion, d’autre part, est un IDE multiplateforme autonome qui prend en charge les compilateurs GCC et Clang (notez que, sous Windows, vous aurez besoin de MinGW/MinGW-w64 ou Cygwin), GDB (ou LLDB depuis le 1.1) en tant que débogueur intégré et CMake en tant que système de construction et modèle de projet.

Les jours qui ont précédé et suivi les lancements de nouveaux produits ont été remplis d’excitation, d’attentes et de prévisions diverses, puis de la joie et de l’anxiété liées au suivi des premières ventes. Mais revenons en arrière et voyons comment nous en sommes arrivés là et où toutes les premières idées de ces produits sont nées.

Comment l’idée est née

Si vous jetez un coup d’œil à notre chronologie, l’un des produits que vous trouverez s’appelle AppCode :
l'histoire
AppCode est un IDE basé sur IntelliJ pour le développement iOS/OS X qui est devenu public en 2011. À cette époque, il s’agissait exclusivement d’un IDE Objective-C, et nous avons naïvement supposé qu’il fonctionnerait correctement sans un analyseur C++ à part entière.

Après le accueil chaleureux de la première version du programme d’accès anticipé (EAP), nous avons reçu plusieurs demandes de prise en charge d’Objective-C++ et, en même temps, nous avons commencé à lutter avec les macros. En continuant à développer notre modèle de langage dans cette direction, nous avons étonnamment rapidement trouvé prise en charge initiale de C++ dans AppCode:

cpp_inattendu

C’était vraiment un support très basique qui incluait un support d’importation automatique STL et un certain achèvement C++. Ce n’est que AppCode 1.6 qui a apporté la prise en charge de libc++, une analyse correcte pour la spécialisation des modèles, certaines fonctionnalités C++11 et Implémenter/Remplacer pour le code C++.

Jusqu’à la version 2.5, la prise en charge de C++ n’était pas notre priorité absolue dans AppCode, et nos améliorations étaient plus ou moins locales. AppCode 2.5 à l’automne 2013 a mis en scène Google Test, l’un des frameworks de test C++ les plus populaires, et plus important encore, une compréhension générale de l’importance vitale de la prise en charge de C++ dans le produit. L’analyseur a été complètement retravaillé et les refactorisations grandement améliorées. Avec tous ces changements, l’idée d’un IDE C++ séparé a commencé à prendre forme dans nos esprits.

Puis est venu le jour du poisson d’avril lorsque nous avons fait notre première annonce publique d’un IDE C++, laissant beaucoup de gens se demander s’il s’agissait vraiment d’une blague. À vrai dire, à ce moment-là, cela aurait pu aller dans les deux sens!

Nous avons travaillé sur deux implémentations distinctes de la prise en charge de C++, au cours desquelles certaines personnes sont passées d’AppCode/CLion à l’équipe ReSharper pour travailler sur ReSharper C++. Les aperçus privés et publics ont commencé en 2014 pour les deux produits.

Faire des outils pour les développeurs implique beaucoup d’écoute. Les versions du programme d’accès anticipé sont notre façon de vous impliquer, de recueillir vos commentaires et d’apporter des modifications et des améliorations aux premières étapes du développement du produit, où elles peuvent grandement influencer la planification du produit.

Nous avons mené des enquêtes sur les sites AppCode/CLion et ReSharper en demandant à nos utilisateurs leurs cas d’utilisation et leurs préférences pour les outils C++. Sur environ 5 000 réponses, plus de 3 000 ont reçu des versions privées à essayer et à utiliser. Les versions EAP publiques étaient disponibles pour tout le monde et nous sommes reconnaissants pour les près de 20 000 utilisateurs de la préversion publique chaque mois, et les 30 000 qui ont utilisé la RC finale.

S’attendant au pire mais espérant le meilleur, nous avons lancé les deux produits au public en avril 2015. Et le reste, comme on dit, appartient à l’histoire.

Recherche C++

Pour nous assurer que nous faisions la bonne chose, nous avons dû en savoir plus sur la demande de support C++, pour comprendre les principaux besoins des développeurs C++. Nous avons réalisé une étude de marché approfondie pour aider à façonner notre feuille de route. Certains résultats de l’étude sont présentés ci-dessous.

Demande de C++ dans tous les secteurs :
cpp_areas
Quelques concurrents existants :
concurrents

D’autres faits et statistiques intéressants révélés par cette recherche ont été récemment publiés dans notre Blog de CLion.

L’étude nous a aidés à identifier les domaines dans lesquels nous pourrions apporter une réelle valeur à l’espace d’outillage C++, afin d’offrir un produit intéressant et puissant à la communauté. Nous savions où appliquer notre expertise en analyse de code, génération et refactorisation à la scène, ainsi qu’un large éventail de fonctionnalités générales provenant de notre plate-forme IntelliJ (comme la prise en charge des technologies Web, VCS, les fonctionnalités de débogage, les suivis de problèmes, le terminal, etc. Suite).

Le marché Android

Dans l’espace global de développement C++, le marché lié au développement Android NDK est impossible à ignorer. Étant donné que le développement Android en Java est entièrement pris en charge dans les deux IntelliJ IDEA Ultimate et Community Editionnous avons rapidement été interrogés sur la prise en charge d’Android NDK.

En mai 2015, Google a annoncé lors de sa conférence Google I/O qu’Android Studio (qui est d’ailleurs basé sur la plate-forme open-source IntelliJ) fournira désormais un support pour le développement d’Android NDK, et ce support est basé sur CLion.
Google_io_announcement
Vous pouvez voir ce qu’il y a à bord dans Enregistrement de la session de développement Google I/O.

Nous envisageons toujours un plugin basé sur CLion pour IntelliJ IDEA, et pourrions éventuellement envisager d’avoir le NDK Android également, mais ces plans sont encore incertains et nous ne pouvons rien promettre ni donner d’estimations.

Android Studio et CLion offrent une prise en charge linguistique similaire : mise en surbrillance du code, navigation, refactorisations, mise en forme automatique, etc. Cependant, Android Studio est uniquement destiné au développement Android, tandis que CLion prend en charge tout projet multiplateforme, fournit une prise en charge intelligente de CMake (et d’autres systèmes de construction à venir), une prise en charge des technologies Web (JavaScript, XML, HTML et CSS), quelques extra Intégrations VCS (telles que la prise en charge de Perforce) et prise en charge des suivis de problèmes. Bien sûr, il y a plus à venir, avec le déjà ouvert CLion 1.1 EAP et d’autres versions à venir, y compris la prise en charge de LLDB, l’intégration avec les frameworks de test unitaire, la prise en charge de Python et bien d’autres choses intéressantes.

Analyseur C++

Comme nous l’avons déjà mentionné, à un moment donné, les équipes CLion et ReSharper C++ se sont séparées, laissant la place à deux implémentations complètement indépendantes d’analyseurs C++. Cela a été causé par deux architectures de plate-forme complètement différentes, IntelliJ et ReSharper, et deux ensembles d’idées différentes sur la façon dont les analyseurs peuvent être implémentés.

Bien sûr, cela soulève la question – pourquoi n’avons-nous pas simplement utilisé libclang mais au lieu de cela, nous nous sommes retrouvés avec deux implémentations distinctes ?

Il y a plusieurs raisons à cela. Lorsque nous avons commencé à prendre en charge C++ dans AppCode, Cycle de publication de Clang n’était pas suffisamment fiable pour utiliser libclang depuis l’intérieur de l’IDE. A cette époque, Clang avait l’air très prometteur, mais pas assez mature. En revanche, nous avions déjà une partie de notre propre infrastructure sur la plate-forme IntelliJ, et nous n’avons besoin que d’un analyseur qui s’intègre en douceur.

Cependant, la principale raison de ne pas utiliser libclang était notre besoins de mise en cache. Pour que l’IDE fonctionne efficacement pendant les refactorisations et autres opérations, nous avions besoin de la mise en cache des symboles. Et il ne s’agit pas seulement de refactorisations : trouver des utilisations contextuelles d’un symbole, créer des vues hiérarchiques appropriées, fournir des actions de navigation et faire tout cela dans un délai raisonnable nécessite une bonne connaissance du contexte du code et la mise en cache des symboles. Clang fait un bon travail de mise en cache tout en travaillant avec des fichiers individuels, en analysant de manière incrémentielle. Mais si nous parlons de l’ensemble du projet, il commence à analyser chaque fichier, tout comme un vrai compilateur devrait le faire. Et c’est là que cela peut devenir problématique depuis l’intérieur de l’IDE.

La dernière raison est injections de langage, une fonctionnalité que nous avons dans IntelliJ Platform. Par exemple, une chaîne en C++ peut être analysée comme une instruction SQL et pas seulement comme une chaîne ordinaire. Nous avons besoin que ces crochets soient également implémentés dans l’analyseur.

Avec toutes ces raisons et des années d’expertise dans les analyseurs de langage que nous avons chez JetBrains, nous avons commencé à implémenter notre propre solution et continuons à faire de notre mieux pour améliorer l’expérience utilisateur de l’IDE et l’exactitude de l’analyseur. Nous n’avons toujours pas donné un «non» définitif à libclang alors que nous suivons divers projets et solutions basés sur clang. Et, accessoirement, nous prévoyons d’inclure des annotations d’erreur Clang dans les inspections de code de CLion.

En conclusion

CLion 1.0 a reçu de nombreuses critiques depuis son lancement, et nous savons que de nombreuses personnes ont fait de CLion leur IDE de choix pour le développement C et C++. Nous apprécions grandement cela, ainsi que tous les commentaires que nous recevons, à la fois des critiques positives inspirantes et des critiques constructives qui nous poussent à nous améliorer.

Il y a eu quelques critiques intéressantes, après quoi nous avons corrigé beaucoup de choses dans les mises à jour 1.0.x (comme celui-ci) et progressent fortement avec l’EAP 1.1 (voir cette). Nous apprécions également tous vos commentaires sur les médias sociaux, les blogs et les sites de l’industrie.

examen
avis2
avis3
avis4

Quelques statistiques intéressantes sur les versions des deux premières semaines après le lancement de CLion 1.0 :

Avant de conclure, nous voulons exprimer notre appréciation des outils vraiment sympas qui fournissent des intégrations avec CLion. Il y a des pionniers comme bicode (gestionnaire de dépendances pour C et C++), et le récent Plate-formeIO (créateur de code multiplateforme et gestionnaire de bibliothèque manquant), ou le fantastique Discussion Arduino qui se passe dans notre tracker, où vous pouvez maintenant trouver quelques solutions de contournement à développer pour Arduino dans CLion ! Au fait, si vous êtes fan de Go, avez-vous essayé le Allez plugin dans CLion et le Exemple de projet CMake+Go de Glenn R. Martin?

Le voyage ne fait que commencer. Nous avons une longue feuille de route, de grands projets et beaucoup d’inspiration pour surmonter les difficultés que nous rencontrons en cours de route. Suivez-nous sur Twitter et essayez CLion aujourd’hui!

Development Source

Related Posts

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Clés Redis dans la RAM |  Redis

Clés Redis dans la RAM | Redis

No Comment

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *