HyperAI超神经

Choses à noter pendant le développement

Le code n’est pas simplement destiné à être exécuté. Le code est également un moyen de communication au sein d’une équipe, un moyen de décrire aux autres la solution à un problème. Un code lisible n'est pas un agréable à avoir, c'est un élément fondamental de l'écriture de code. Cela implique de factoriser clairement le code, de choisir des noms de variables explicites et d'insérer des commentaires pour décrire tout ce qui est implicite. Le code que vous écrivez n’est pas seulement exécuté par vous. Le code est également un moyen de communiquer entre les équipes, un moyen de décrire une solution à un problème à des collègues et des utilisateurs.Un code lisible n'est pas une chose « agréable à avoir, mais pas acceptable », mais l’une des parties les plus importantes de l’écriture de code. Pour garantir que votre code est lisible, il faut le décomposer proprement, choisir des noms de variables pertinents et explicites et décrire tout contenu implicite en ajoutant des commentaires.
Ne demandez pas ce que votre pull request peut faire pour votre prochaine promotion, demandez-vous ce que votre pull request peut faire pour vos utilisateurs et votre communauté. Évitez à tout prix toute « contribution ostentatoire ». N'ajoutez aucune fonctionnalité si elle ne contribue pas clairement à l'objectif de votre produit. Ne pensez pas seulement à la façon dont votre demande d’extraction peut vous aider à obtenir votre prochaine promotion professionnelle.Pensez à ce que vous pouvez apporter à vos utilisateurs et à votre communauté.. Si une fonctionnalité ne contribue pas clairement à atteindre l’objectif du produit, ne l’ajoutez pas.
Le goût s’applique également au code. Le goût est un processus de satisfaction de contraintes régularisé par un désir de simplicité. Gardez un penchant pour la simplicité. Restez simple.
Il n’y a rien de mal à dire non : ce n’est pas parce que quelqu’un demande une fonctionnalité que vous devez la faire. Chaque fonctionnalité a un coût qui va au-delà de la mise en œuvre initiale : coût de maintenance, coût de documentation et coût cognitif pour vos utilisateurs. Demandez-vous toujours : Devrions-nous vraiment faire cela ? Souvent, la réponse est tout simplement non. Apprenez à dire non. Ce n’est pas parce que quelqu’un demande une fonctionnalité que vous devez la faire. Le développement de chaque fonctionnalité nécessite un certain coût : coût de maintenance, coût de documentation et coût cognitif pour l’utilisateur. Posez-vous toujours des questions telles que :Devrions-nous vraiment faire cela ? La réponse est généralement non.
Lorsque vous répondez oui à une demande de prise en charge d’un nouveau cas d’utilisation, n’oubliez pas qu’ajouter littéralement ce que l’utilisateur a demandé n’est souvent pas le choix optimal. Les utilisateurs se concentrent sur leur propre cas d’utilisation spécifique, et vous devez contrer cela avec une vision holistique et fondée sur des principes de l’ensemble du projet. Souvent, la bonne réponse est d’étendre une fonctionnalité existante. Lorsque vous êtes prêt à vous engager à prendre en charge un nouveau cas d'utilisation, sachez que l'ajout d'une exigence que l'utilisateur souhaite ostensiblement voir satisfaite n'est généralement pas la meilleure approche. Les utilisateurs se concentrent sur leurs propres scénarios d’utilisation spécifiques et vous devez considérer l’ensemble du projet du point de vue de la vision globale du produit.En général, la bonne approche consiste à développer les fonctionnalités existantes ;
Investissez dans l’intégration continue et visez une couverture complète des tests unitaires. Assurez-vous d’être dans un environnement où vous pouvez coder en toute confiance ; Si ce n’est pas le cas, commencez par vous concentrer sur la construction de la bonne infrastructure.Investissez dans l’intégration continue dans le but d’obtenir une couverture complète des tests unitaires.Assurez-vous d’être dans un environnement où vous pouvez écrire du code en toute confiance ; sinon, vous devez d’abord construire la bonne infrastructure.

Il n’y a rien de mal à ne pas tout planifier à l’avance. Essayez des choses et voyez ce qu’elles donnent. Annulez rapidement les mauvais choix. Assurez-vous de créer un environnement où cela est possible. Il n’est pas nécessaire de tout planifier à l’avance.Testez-le d’abord et voyez comment cela fonctionne.Cela permettra d’éviter de faire le mauvais choix dès le début. Bien entendu, vous devez d’abord vous assurer que vous avez créé un environnement de développement facile à utiliser, stable et complet.

Un bon logiciel rend les choses difficiles faciles. Ce n’est pas parce qu’un problème paraît difficile au premier abord que la solution devra être complexe ou difficile à utiliser. Trop souvent, les ingénieurs optent pour des solutions réflexes qui introduisent une complexité indésirable (Utilisons le ML ! Créons une application ! Ajoutons la blockchain !) dans des situations où une alternative beaucoup plus simple, bien que peut-être moins évidente, est disponible. Avant d’écrire du code, assurez-vous que la solution de votre choix ne peut pas être simplifiée davantage. Abordez tout à partir des premiers principes. Un bon logiciel peut rendre les choses difficiles faciles. Ce n’est pas parce qu’un problème semble difficile à première vue que la solution doit être complexe ou difficile à utiliser. Dans de nombreux cas, les ingénieurs ont tendance à proposer des solutions très complexes, mais en fait, il existe une solution plus simple et plus facile, mais cette solution simple n'est peut-être pas si évidente.Avant d’écrire du code, assurez-vous que la solution que vous choisissez est la plus simple.
Évitez les règles implicites. Les règles implicites que vous développez doivent toujours être explicitées et partagées avec d’autres ou automatisées. Chaque fois que vous vous retrouvez à créer un flux de travail récurrent et quasi algorithmique, vous devez chercher à le formaliser dans un processus documenté, afin que les autres membres de l'équipe bénéficient de l'expérience. En outre, vous devez chercher à automatiser dans le logiciel toute partie d'un tel flux de travail qui peut être automatisée (par exemple, les contrôles d'exactitude). Évitez les règles implicites. Pour rendre explicites toutes les règles implicites que vous avez formées et les partager avec d’autres, ouRendez-le automatique. Lorsque vous vous retrouvez à créer un flux de travail récurrent et quasi algorithmique, vous devez rechercher des moyens de standardiser et de documenter le processus afin que les autres membres de l'équipe puissent également en bénéficier. De plus, pour les flux de travail qui peuvent être automatisés, vous devez en automatiser autant que possible dans votre logiciel.
L’impact total de vos choix doit être pris en compte dans le processus de conception, et pas seulement les éléments sur lesquels vous souhaitez vous concentrer, comme les revenus ou la croissance. Au-delà des indicateurs que vous surveillez, quel impact total votre logiciel a-t-il sur ses utilisateurs, sur le monde ? Existe-t-il des effets secondaires indésirables qui l’emportent sur la proposition de valeur ? Que pouvez-vous faire pour y remédier tout en préservant l’utilité du logiciel ? Au cours du processus de conception, tenez compte de l’impact global des options choisies, et pas seulement des revenus ou de la croissance. En plus des mesures que vous avez déjà surveillées, quels autres impacts le logiciel a-t-il sur les utilisateurs et le monde en général ? Y a-t-il des effets secondaires indésirables ? Que pouvez-vous faire pour résoudre ces problèmes tout en garantissant la disponibilité des logiciels ?

Comment écrire une meilleure API ?

Votre API a des utilisateurs, elle a donc une expérience utilisateur. Dans chaque décision que vous prenez, gardez toujours l’utilisateur à l’esprit. Faites preuve d’empathie envers vos utilisateurs, qu’ils soient débutants ou développeurs expérimentés. Votre API a des utilisateurs, elle implique donc également l’expérience utilisateur.Dans chaque décision que vous prenez, pensez à l’utilisateur. Pensez du point de vue de l’utilisateur, qu’il soit novice ou développeur expérimenté.
Cherchez toujours à minimiser la charge cognitive imposée à vos utilisateurs lors de l’utilisation de votre API. Automatisez ce qui peut être automatisé, minimisez les actions et les choix nécessaires de la part de l'utilisateur, n'exposez pas d'options sans importance, concevez des flux de travail simples et cohérents qui reflètent des modèles mentaux simples et cohérents. Essayez de réduire la charge cognitive des utilisateurs lors de l’utilisation de l’API du produit. Automatisez toutes les étapes qui peuvent être automatisées,Minimiser le nombre d'actions et de choix que les utilisateurs doivent faire, n’affichez pas d’options sans importance et concevez des flux de travail simples et cohérents qui reflètent des modèles mentaux simples et cohérents.
Les choses simples devraient être simples, les choses complexes devraient être possibles. N'augmentez pas la charge cognitive des cas d'utilisation courants au profit de cas d'utilisation de niche, même de manière minimale. Les choses simples doivent être traitées simplement, et les choses complexes doivent être simplifiées autant que possible.N’augmentez pas la charge cognitive des cas d’utilisation courants uniquement pour quelques cas d’utilisation particuliers.

Si la charge cognitive d'un workflow est suffisamment faible, il devrait être possible pour un utilisateur de le parcourir de mémoire (sans consulter un tutoriel ou une documentation) après l'avoir fait une ou deux fois. Si unLe seuil cognitif du flux de travail est suffisamment bas, les utilisateurs peuvent alors terminer l'opération par le ressenti et la mémoire après l'avoir utilisée une ou deux fois, etPas besoin de chercher la documentation du tutoriel.

Cherchez à avoir une API qui correspond aux modèles mentaux des experts et des praticiens du domaine. Quelqu'un qui a de l'expérience dans le domaine, mais aucune expérience avec votre API, devrait être capable de comprendre intuitivement votre API en utilisant une documentation minimale, principalement en regardant simplement quelques exemples de code et en voyant quels objets sont disponibles et quelles sont leurs signatures.Efforcez-vous de créer des API qui correspondent aux modèles mentaux des experts et des praticiens du domaine.Une personne ayant une expérience du domaine mais qui n'a pas utilisé votre API devrait être capable de comprendre intuitivement votre API avec une documentation minimale, comme par exemple être généralement capable d'obtenir une bonne compréhension de votre API simplement en regardant quelques exemples de code et en voyant quels objets sont disponibles et quelles sont leurs caractéristiques.
La signification d’un argument doit être compréhensible sans avoir de contexte sur la mise en œuvre sous-jacente. Les arguments qui doivent être spécifiés par les utilisateurs doivent se rapporter aux modèles mentaux que les utilisateurs ont sur le problème, et non aux détails d'implémentation de votre code. Une API se concentre sur le problème qu’elle résout, et non sur la manière dont le logiciel fonctionne en arrière-plan. La signification d’un paramètre doit être facile à comprendre sans nécessiter d’informations générales sur l’implémentation sous-jacente. Les paramètres qui doivent être spécifiés par l'utilisateur doivent être liés au modèle du problème de l'utilisateur, et non aux détails d'implémentation dans le code. Le cœur d’une API réside dans le problème qu’elle résout, qui n’a rien à voir avec le flux de travail du logiciel en coulisses.
Les modèles mentaux les plus puissants sont modulaires et hiérarchiques : simples à un niveau élevé, mais précis car vous devez entrer dans les détails. De la même manière, une bonne API est modulaire et hiérarchique : facile d’accès, mais expressive. Il y a un équilibre à trouver entre avoir des signatures complexes sur moins d’objets et avoir plus d’objets avec des signatures plus simples. Une bonne API possède un nombre raisonnable d’objets, avec des signatures raisonnablement simples. Les modèles les plus puissants sont modulaires et hiérarchiques : simples à un niveau élevé, mais précis dans les détails. De la même manière,Une bonne API doit également être modulaire et hiérarchique : facile à utiliser et expressive. Une bonne API possède un nombre raisonnable d’objets avec des fonctionnalités simples.
Votre API est inévitablement le reflet de vos choix d’implémentation, en particulier de votre choix de structures de données. Pour obtenir une API intuitive, vous devez choisir des structures de données qui correspondent naturellement au domaine concerné, qui correspondent aux modèles mentaux des experts du domaine. Votre API est le reflet nécessaire de vos choix d’implémentation, notamment de votre choix de structures de données. Pour implémenter une API intuitive,Vous devez choisir une structure de données adaptée au domaine en question, c'est-à-dire qui correspond au modèle des experts du domaine.

Concevez délibérément des flux de travail de bout en bout, et non un ensemble de fonctionnalités atomiques. La plupart des développeurs abordent la conception d’API en se demandant : quelles fonctionnalités devraient être disponibles ? Donnons-leur des options de configuration. Demandez-vous plutôt : quels sont les cas d’utilisation de cet outil ? Pour chaque cas d’utilisation, quelle est la séquence optimale d’actions de l’utilisateur ? Quelle est l'API la plus simple qui pourrait prendre en charge ce flux de travail ? Les options atomiques de votre API doivent répondre à un besoin clair qui survient dans un flux de travail de haut niveau — elles ne doivent pas être ajoutées « parce que quelqu’un pourrait en avoir besoin ».Concevez intentionnellement des flux de travail de bout en bout plutôt qu'un ensemble de fonctionnalités atomiques.Lors de la conception d’une API, la plupart des développeurs se demandent : quelles fonctionnalités doivent être fournies ? Fournissons des options de configuration pour ces fonctionnalités. En fait, la bonne question pour les développeurs devrait être : quels sont les scénarios d’utilisation de cet outil ? Pour chaque cas d’utilisation, quelle est la meilleure séquence d’actions pour l’utilisateur ? Quelle est l’API la plus simple qui peut prendre en charge ce flux de travail ?
Les messages d'erreur et, en général, tout commentaire fourni à un utilisateur au cours de son interaction avec votre API font partie de l'API. L’interactivité et le feedback font partie intégrante de l’expérience utilisateur. Concevez délibérément les messages d’erreur de votre API.Les rapports d'erreurs et tous les commentaires fournis aux utilisateurs lors de leur interaction avec l'API font partie de l'API.L’interactivité et le feedback font partie intégrante de l’expérience utilisateur. Vous devez concevoir soigneusement les messages d’erreur de votre API.
Parce que le code est une communication, la dénomination est importante, qu’il s’agisse de nommer un projet ou une variable. Les noms reflètent la façon dont vous envisagez un problème. Évitez les noms trop génériques (x, variable, paramètre), évitez les modèles de noms trop longs et spécifiques, évitez les termes qui peuvent créer des frictions inutiles (maître, esclave) et assurez-vous d'être cohérent dans vos choix de noms. La cohérence de nommage signifie à la fois la cohérence de nommage interne (n'appelez pas « dim » ce qu'on appelle « axe » ailleurs) et la cohérence avec les conventions établies pour le domaine du problème. Avant de choisir un nom, assurez-vous de rechercher les noms existants utilisés par les experts du domaine (ou d’autres API). Parce que le code est une communication, la dénomination est importante, qu’il s’agisse de nommer des projets ou de nommer des variables. Le nom reflète la façon dont vous envisagez un problème.Évitez d’utiliser des noms trop génériques, évitez d’utiliser des modèles de dénomination trop longs, évitez d’utiliser des termes qui pourraient entraîner des malentendus inutiles et assurez-vous d’être cohérent dans vos choix de dénomination.La cohérence de dénomination signifie à la fois la cohérence de dénomination interne et la cohérence avec les normes établies dans le domaine du problème. Avant de choisir un nom, assurez-vous de rechercher des noms qui sont déjà utilisés par des experts dans le domaine.
La documentation est essentielle à l’expérience utilisateur de votre API. Ce n’est pas un module complémentaire. Investissez dans une documentation de haute qualité ; vous obtiendrez des rendements plus élevés qu'en investissant dans davantage de fonctionnalités. La documentation est essentielle à l’expérience utilisateur de votre API. Ce n’est pas un module complémentaire.Investissez de l’énergie dans la rédaction d’une documentation de haute qualité.Cela peut générer des rendements plus élevés que le développement de nouvelles fonctionnalités.

Montrez, ne dites pas : votre documentation ne doit pas expliquer comment fonctionne le logiciel, elle doit montrer comment l'utiliser. Afficher des exemples de code pour les flux de travail de bout en bout ; affichez des exemples de code pour chaque cas d'utilisation courant et fonctionnalité clé de votre API. Montrez aux utilisateurs au lieu de leur dire : votre documentation ne doit pas expliquer comment fonctionne le logiciel, mais doit montrer aux utilisateurs comment l'utiliser.Exemples de code montrant des flux de travail de bout en bout ;Affichez des exemples de code pour chaque cas d’utilisation courant et fonctionnalité clé de votre API.

S'il y a un examen sur Keras, j'ai préparé une aide-mémoire

Super Neuropédia

mot

univarié

[ju:nɪ'veərɪrt] adj. univarié

multivarié

[mʌltɪ'veərɪɪt] adj. multivarié

phrase

régression logistique Régression logistique

mise en œuvre du service Mise en œuvre du service

La Liste Du Nouvel An Du Père De Keras, Tu La Mérites En 2019