HyperAI超神经

Dinge, die während der Entwicklung zu beachten sind

Code ist nicht nur zur Ausführung gedacht. Code ist außerdem ein Kommunikationsmittel innerhalb eines Teams, eine Möglichkeit, anderen die Lösung eines Problems zu beschreiben. Lesbarer Code ist kein schön zu haben, es ist ein grundlegender Teil des Codeschreibens. Dazu gehört, den Code klar zu faktorisieren, selbsterklärende Variablennamen auszuwählen und Kommentare einzufügen, um alles Implizite zu beschreiben. Der von Ihnen geschriebene Code wird nicht nur von Ihnen ausgeführt. Code ist auch eine Möglichkeit zur teamübergreifenden Kommunikation und eine Möglichkeit, Kollegen und Benutzern die Lösung eines Problems zu beschreiben.Lesbarer Code ist keine „schöne Sache, aber nicht okay“, aber einer der wichtigsten Teile beim Schreiben von Code. Um sicherzustellen, dass Ihr Code lesbar ist, müssen Sie ihn sauber aufteilen, gute, selbsterklärende Variablennamen wählen und alle impliziten Inhalte durch Hinzufügen von Kommentaren beschreiben.
Fragen Sie nicht, was Ihr Pull Request für Ihre nächste Promotion tun kann, sondern fragen Sie, was Ihr Pull Request für Ihre Benutzer und Ihre Community tun kann. Vermeiden Sie um jeden Preis „auffällige Beiträge“. Fügen Sie keine Funktion hinzu, wenn diese nicht eindeutig zum Zweck Ihres Produkts beiträgt. Denken Sie nicht nur daran, wie Ihr Pull Request Ihnen bei Ihrer nächsten Beförderung helfen kann.Überlegen Sie, was Sie Ihren Benutzern und der Community bieten können.. Wenn eine Funktion nicht eindeutig dazu beiträgt, das Ziel des Produkts zu erreichen, fügen Sie sie nicht hinzu.
Auch beim Code spielt Geschmack eine Rolle. Geschmack ist ein Prozess der Einschränkung und Befriedigung, der durch den Wunsch nach Einfachheit reguliert wird. Behalten Sie eine Vorliebe für Einfachheit. Halten Sie es einfach.
Es ist in Ordnung, Nein zu sagen – nur weil jemand nach einer Funktion fragt, heißt das nicht, dass Sie sie auch tun sollten. Jede Funktion verursacht Kosten, die über die anfängliche Implementierung hinausgehen: Wartungskosten, Dokumentationskosten und kognitive Kosten für Ihre Benutzer. Fragen Sie immer: Sollten wir das wirklich tun? Oft lautet die Antwort einfach nein. Lernen Sie, Nein zu sagen. Nur weil jemand nach einer Funktion fragt, heißt das nicht, dass Sie sie auch umsetzen sollten. Die Entwicklung jeder Funktion ist mit bestimmten Kosten verbunden: Wartungskosten, Dokumentationskosten und kognitive Kosten für den Benutzer. Stellen Sie sich immer Fragen wie:Sollten wir das wirklich tun? Die Antwort ist normalerweise nein.
Wenn Sie einer Anfrage zur Unterstützung eines neuen Anwendungsfalls zustimmen, bedenken Sie, dass es oft nicht die optimale Lösung ist, wörtlich das hinzuzufügen, was der Benutzer angefordert hat. Benutzer konzentrieren sich auf ihren eigenen spezifischen Anwendungsfall und Sie müssen dem mit einer ganzheitlichen und prinzipiellen Vision des gesamten Projekts entgegenwirken. Oft besteht die richtige Antwort darin, eine vorhandene Funktion zu erweitern. Wenn Sie bereit sind, einen neuen Anwendungsfall zu unterstützen, sollten Sie sich darüber im Klaren sein, dass das Hinzufügen einer Anforderung, die der Benutzer angeblich erfüllt haben möchte, normalerweise nicht der beste Ansatz ist. Benutzer konzentrieren sich auf ihre eigenen spezifischen Nutzungsszenarien und Sie müssen das gesamte Projekt aus der Perspektive der Gesamtvision des Produkts betrachten.Normalerweise besteht der richtige Ansatz darin, vorhandene Funktionen zu erweitern.
Investieren Sie in kontinuierliche Integration und streben Sie eine vollständige Unit-Test-Abdeckung an. Stellen Sie sicher, dass Sie sich in einer Umgebung befinden, in der Sie sicher programmieren können. Wenn dies nicht der Fall ist, konzentrieren Sie sich zunächst auf den Aufbau der richtigen Infrastruktur.Investieren Sie in kontinuierliche Integration mit dem Ziel, eine vollständige Unit-Test-Abdeckung zu erreichen.Stellen Sie sicher, dass Sie sich in einer Umgebung befinden, in der Sie sicher Code schreiben können. Wenn nicht, müssen Sie zuerst die richtige Infrastruktur aufbauen.

Es ist in Ordnung, nicht alles im Voraus zu planen. Probieren Sie Dinge aus und sehen Sie, was dabei herauskommt. Machen Sie falsche Auswahlen frühzeitig rückgängig. Stellen Sie sicher, dass Sie eine Umgebung schaffen, in der dies möglich ist. Es ist nicht notwendig, alles im Voraus zu planen.Testen Sie es zuerst und sehen Sie, wie es funktioniert.So vermeiden Sie frühzeitig eine Fehlentscheidung. Natürlich müssen Sie zunächst sicherstellen, dass Sie eine benutzerfreundliche, stabile und umfassende Entwicklungsumgebung erstellt haben.

Gute Software macht schwierige Dinge einfach. Nur weil ein Problem zunächst schwierig aussieht, heißt das nicht, dass die Lösung komplex oder schwer anzuwenden sein muss. Zu häufig entscheiden sich Ingenieure für Reflexlösungen, die unerwünschte Komplexität einführen (Lasst uns ML verwenden! Lasst uns eine App erstellen! Lasst uns Blockchain hinzufügen!), in Situationen, in denen eine viel einfachere, wenn auch vielleicht weniger offensichtliche Alternative verfügbar ist. Bevor Sie Code schreiben, stellen Sie sicher, dass die Lösung Ihrer Wahl nicht einfacher gestaltet werden kann. Gehen Sie alles von Grund auf an. Gute Software kann schwierige Dinge einfach machen. Nur weil ein Problem auf den ersten Blick schwierig erscheint, heißt das nicht, dass die Lösung komplex oder schwierig zu verwenden sein muss. In vielen Fällen neigen Ingenieure dazu, sehr komplexe Lösungen anzubieten, doch tatsächlich gibt es eine einfachere und leichtere Lösung, die jedoch möglicherweise nicht so offensichtlich ist.Stellen Sie vor dem Schreiben von Code sicher, dass die von Ihnen gewählte Lösung die einfachste ist.
Vermeiden Sie implizite Regeln. Implizite Regeln, die Sie selbst entwickeln, sollten immer explizit gemacht und mit anderen geteilt oder automatisiert werden. Wenn Sie einen wiederkehrenden, quasi-algorithmischen Arbeitsablauf entwickeln, sollten Sie versuchen, ihn in einem dokumentierten Prozess zu formalisieren, damit andere Teammitglieder von der Erfahrung profitieren. Darüber hinaus sollten Sie versuchen, alle Teile eines solchen Workflows, die automatisiert werden können (z. B. Richtigkeitsprüfungen), in der Software zu automatisieren. Vermeiden Sie implizite Regeln. Um alle impliziten Regeln, die Sie aufgestellt haben, explizit zu machen und sie mit anderen zu teilen, oderMachen Sie es automatisch. Wenn Sie einen wiederkehrenden, quasi-algorithmischen Arbeitsablauf entwickeln, sollten Sie nach Möglichkeiten suchen, den Prozess zu standardisieren und zu dokumentieren, damit auch andere Teammitglieder davon profitieren können. Darüber hinaus sollten Sie bei Arbeitsabläufen, die automatisiert werden können, möglichst viele davon in Ihrer Software automatisieren.
Im Designprozess sollten die gesamten Auswirkungen Ihrer Entscheidungen berücksichtigt werden, nicht nur die Aspekte, auf die Sie sich konzentrieren möchten – wie etwa Umsatz oder Wachstum. Welchen Gesamteinfluss hat Ihre Software über die von Ihnen überwachten Kennzahlen hinaus auf ihre Benutzer und auf die Welt? Gibt es unerwünschte Nebenwirkungen, die den Wertbeitrag überwiegen? Was können Sie tun, um diese Probleme zu beheben und gleichzeitig die Nützlichkeit der Software zu erhalten? Berücksichtigen Sie während des Entwurfsprozesses die Gesamtauswirkungen der gewählten Optionen, nicht nur Umsatz oder Wachstum. Welche weiteren Auswirkungen hat die Software neben den Kennzahlen, die Sie bereits überwacht haben, auf die Benutzer und die Welt im Allgemeinen? Gibt es unerwünschte Nebenwirkungen? Was können Sie tun, um diese Probleme zu beheben und gleichzeitig die Softwareverfügbarkeit sicherzustellen?

Wie schreibt man eine bessere API?

Ihre API hat Benutzer und somit eine Benutzererfahrung. Behalten Sie bei jeder Entscheidung, die Sie treffen, immer den Benutzer im Hinterkopf. Zeigen Sie Einfühlungsvermögen gegenüber Ihren Benutzern, egal ob es sich um Anfänger oder erfahrene Entwickler handelt. Ihre API hat Benutzer, daher geht es auch um die Benutzererfahrung.Berücksichtigen Sie bei jeder Entscheidung, die Sie treffen, den Benutzer. Denken Sie aus der Perspektive des Benutzers, unabhängig davon, ob es sich bei dem Benutzer um einen Anfänger oder einen erfahrenen Entwickler handelt.
Versuchen Sie stets, die kognitive Belastung Ihrer Benutzer bei der Verwendung Ihrer API zu minimieren. Automatisieren Sie, was automatisiert werden kann, minimieren Sie die vom Benutzer erforderlichen Aktionen und Auswahlmöglichkeiten, stellen Sie keine unwichtigen Optionen zur Verfügung und entwerfen Sie einfache und konsistente Arbeitsabläufe, die einfache und konsistente mentale Modelle widerspiegeln. Versuchen Sie, die kognitive Belastung der Benutzer bei der Verwendung der Produkt-API zu reduzieren. Automatisieren Sie alle Schritte, die automatisiert werden können,Minimieren Sie die Anzahl der Aktionen und Auswahlmöglichkeiten, die Benutzer treffen müssen, zeigen Sie keine unwichtigen Optionen an und entwerfen Sie einfache, konsistente Arbeitsabläufe, die einfache, konsistente mentale Modelle widerspiegeln.
Einfache Dinge sollten einfach sein, komplexe Dinge sollten möglich sein. Erhöhen Sie die kognitive Belastung gängiger Anwendungsfälle nicht zugunsten von Nischenanwendungsfällen, auch nicht minimal. Einfache Dinge sollten einfach behandelt und komplexe Dinge so weit wie möglich vereinfacht werden.Erhöhen Sie die kognitive Belastung gängiger Anwendungsfälle nicht nur für einige spezielle Anwendungsfälle.

Wenn die kognitive Belastung eines Workflows ausreichend gering ist, sollte es für einen Benutzer möglich sein, ihn aus dem Gedächtnis durchzugehen (ohne ein Tutorial oder eine Dokumentation nachzuschlagen), nachdem er ihn ein- oder zweimal ausgeführt hat. Wenn einDie kognitive Schwelle des Workflows ist niedrig genug, dann können Benutzer den Vorgang nach ein- oder zweimaliger Verwendung durch Gefühl und Gedächtnis abschließen, undSie müssen nicht nach Tutorial-Dokumentation suchen.

Versuchen Sie, eine API zu haben, die den mentalen Modellen von Fachexperten und Praktikern entspricht. Jemand, der zwar Erfahrung mit der Domäne hat, aber keine Erfahrung mit Ihrer API, sollte Ihre API mithilfe einer minimalen Dokumentation intuitiv verstehen können, indem er sich meist nur ein paar Codebeispiele ansieht und sieht, welche Objekte verfügbar sind und welche Signaturen sie haben.Bemühen Sie sich, APIs zu erstellen, die den mentalen Modellen von Fachexperten und Praktikern entsprechen.Jemand mit Domänenerfahrung, der Ihre API jedoch nicht verwendet hat, sollte Ihre API mit minimaler Dokumentation intuitiv verstehen können. Normalerweise reicht es aus, sich ein gutes Bild von Ihrer API zu machen, indem er sich lediglich einige Codebeispiele ansieht und feststellt, welche Objekte verfügbar sind und welche Eigenschaften sie haben.
Die Bedeutung eines Arguments sollte verständlich sein, ohne dass ein Kontext zur zugrunde liegenden Implementierung vorliegt. Argumente, die von Benutzern angegeben werden müssen, sollten sich auf die mentalen Modelle beziehen, die die Benutzer zum Problem haben, und nicht auf Implementierungsdetails in Ihrem Code. Bei einer API geht es in erster Linie um das Problem, das sie löst, und nicht darum, wie die Software im Hintergrund arbeitet. Die Bedeutung eines Parameters sollte leicht verständlich sein, ohne dass Hintergrundinformationen zur zugrunde liegenden Implementierung erforderlich sind. Parameter, die vom Benutzer angegeben werden müssen, sollten sich auf das Problemmodell des Benutzers beziehen und nicht auf Implementierungsdetails im Code. Der Kern einer API liegt in dem Problem, das sie löst, und hat nichts mit dem Arbeitsablauf der Software hinter den Kulissen zu tun.
Die leistungsfähigsten mentalen Modelle sind modular und hierarchisch: einfach auf hoher Ebene, aber präzise, wenn Sie ins Detail gehen müssen. Ebenso ist eine gute API modular und hierarchisch: leicht zugänglich und dennoch ausdrucksstark. Es muss ein Gleichgewicht gefunden werden zwischen der Verwendung komplexer Signaturen auf weniger Objekten und der Verwendung von mehr Objekten mit einfacheren Signaturen. Eine gute API verfügt über eine angemessene Anzahl von Objekten mit einigermaßen einfachen Signaturen. Die leistungsstärksten Modelle sind modular und hierarchisch: einfach auf hoher Ebene, aber präzise im Detail. Ähnlich,Eine gute API sollte außerdem modular und hierarchisch sein: einfach zu verwenden und ausdrucksstark. Eine gute API verfügt über eine angemessene Anzahl von Objekten mit einfachen Funktionen.
Ihre API ist zwangsläufig ein Spiegelbild Ihrer Implementierungsentscheidungen, insbesondere Ihrer Wahl der Datenstrukturen. Um eine intuitive API zu erreichen, müssen Sie Datenstrukturen auswählen, die natürlich zum jeweiligen Bereich passen – die den mentalen Modellen von Fachexperten entsprechen. Ihre API ist ein notwendiges Spiegelbild Ihrer Implementierungsentscheidungen, insbesondere Ihrer Wahl der Datenstrukturen. Um eine intuitive API zu implementieren,Sie müssen eine Datenstruktur wählen, die für die jeweilige Domäne geeignet ist, d. h. eine, die dem Modell der Domänenexperten entspricht.

Entwerfen Sie bewusst End-to-End-Workflows und nicht eine Reihe atomarer Funktionen. Die meisten Entwickler nähern sich dem API-Design mit der Frage: Welche Funktionen sollten verfügbar sein? Lassen Sie uns Konfigurationsoptionen für sie bereitstellen. Fragen Sie stattdessen: Was sind die Anwendungsfälle für dieses Tool? Was ist für jeden Anwendungsfall die optimale Abfolge von Benutzeraktionen? Welche API ist am einfachsten, um diesen Workflow zu unterstützen? Atomare Optionen in Ihrer API sollten einem klaren Bedarf entsprechen, der in einem Workflow auf hoher Ebene entsteht. Sie sollten nicht hinzugefügt werden, „weil jemand sie vielleicht braucht“.Entwerfen Sie bewusst End-to-End-Workflows und nicht nur eine Reihe atomarer Funktionen.Beim Entwerfen einer API fragen sich die meisten Entwickler: Welche Funktionen sollen bereitgestellt werden? Lassen Sie uns Konfigurationsoptionen für diese Funktionen bereitstellen. Tatsächlich sollte die richtige Frage für Entwickler lauten: Was sind die Anwendungsszenarien dieses Tools? Was ist für den Benutzer in jedem Anwendungsfall die beste Aktionsfolge? Was ist die einfachste API, die diesen Workflow unterstützen kann?
Fehlermeldungen und generell jegliches Feedback, das einem Benutzer im Verlauf der Interaktion mit Ihrer API bereitgestellt wird, sind Teil der API. Interaktivität und Feedback sind integraler Bestandteil des Benutzererlebnisses. Gestalten Sie die Fehlermeldungen Ihrer API bewusst.Fehlerberichte und jegliches Feedback, das den Benutzern während ihrer Interaktion mit der API bereitgestellt wird, sind Teil der API.Interaktivität und Feedback sind ein integraler Bestandteil der Benutzererfahrung. Sie müssen die Fehlermeldungen Ihrer API sorgfältig gestalten.
Da Code Kommunikation ist, ist die Benennung wichtig – egal, ob es sich um die Benennung eines Projekts oder einer Variable handelt. Namen spiegeln wider, wie Sie über ein Problem denken. Vermeiden Sie zu allgemeine Namen (x, Variable, Parameter), vermeiden Sie zu lange und spezifische Namensmuster, vermeiden Sie Begriffe, die unnötige Reibung erzeugen können (Master, Slave) und stellen Sie sicher, dass Sie bei der Namenswahl konsistent sind. Namenskonsistenz bedeutet sowohl interne Namenskonsistenz (nennen Sie nicht „dim“, was an anderen Stellen „axis“ heißt) als auch Konsistenz mit etablierten Konventionen für den Problembereich. Bevor Sie sich für einen Namen entscheiden, sollten Sie unbedingt nach vorhandenen Namen suchen, die von Domänenexperten (oder anderen APIs) verwendet werden. Da Code Kommunikation ist, ist die Benennung wichtig, sei es bei der Benennung von Projekten oder Variablen. Der Name spiegelt die Art und Weise wider, wie Sie über ein Problem denken.Vermeiden Sie die Verwendung zu allgemeiner Namen, zu langer Benennungsmuster und Begriffe, die zu unnötigen Missverständnissen führen könnten. Achten Sie auf eine konsistente Namenswahl.Unter Namenskonsistenz versteht man sowohl interne Namenskonsistenz als auch Übereinstimmung mit etablierten Normen im Problemfeld. Bevor Sie sich für einen Namen entscheiden, achten Sie darauf, nach Namen zu suchen, die bereits von Experten auf dem Gebiet verwendet werden.
Die Dokumentation ist für die Benutzererfahrung Ihrer API von zentraler Bedeutung. Es ist kein Add-on. Investieren Sie in hochwertige Dokumentation; Sie erzielen höhere Renditen als durch die Investition in weitere Funktionen. Die Dokumentation ist der Schlüssel zur Benutzererfahrung Ihrer API. Es ist kein Add-on.Investieren Sie Energie in das Schreiben hochwertiger Dokumentationen.Dies kann höhere Erträge bringen als die Entwicklung weiterer Funktionen.

Zeigen, nicht erzählen: Ihre Dokumentation sollte nicht darüber sprechen, wie die Software funktioniert, sondern zeigen, wie man sie verwendet. Zeigen Sie Codebeispiele für End-to-End-Workflows. Zeigen Sie Codebeispiele für jeden einzelnen gängigen Anwendungsfall und jede Schlüsselfunktion Ihrer API. Zeigen Sie es den Benutzern, anstatt es ihnen zu erzählen: Ihre Dokumentation sollte nicht erläutern, wie die Software funktioniert, sondern den Benutzern zeigen, wie sie sie verwenden.Codebeispiele, die End-to-End-Workflows zeigen;Zeigen Sie Codebeispiele für jeden gängigen Anwendungsfall und jedes Hauptmerkmal Ihrer API.

Falls es eine Prüfung zu Keras gibt, habe ich einen Spickzettel vorbereitet

Super Neuropedia

Wort

univariat

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

multivariat

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

Phrase

logistische Regression Logistische Regression

Serviceimplementierung Service-Implementierung

Die Neujahrsliste Des Vaters Von Keras, Sie Verdienen Es Im Jahr 2019