it-swarm-eu.dev

Wie übe ich absichtlich Software Engineering?

Ich habe gerade das Lesen beendet dieser aktuelle Artikel . Es ist eine sehr interessante Lektüre und macht einige großartige Punkte. Der Punkt, der mich besonders angesprochen hat, war folgender:

Der Unterschied bestand darin, wie sie diese [gleiche] Zeit verbrachten. Die Elite-Spieler verbrachten fast dreimal mehr Stunden als die durchschnittlichen Spieler mit absichtlichem Üben - der unangenehmen, methodischen Arbeit, Ihre Fähigkeiten zu erweitern.

In diesem Artikel (wenn Sie ihn nicht lesen möchten) werden Geigenspieler behandelt. Als Softwareentwickler habe ich mich natürlich der Softwarefähigkeit zugewandt. Zugegeben, es gibt einige sehr natürlich talentierte Menschen da draußen, aber immer wieder sind es diese Leute, die ihre Fähigkeiten durch gezieltes Üben erweitern, die in ihrem Handwerk wirklich außergewöhnlich werden.

Meine Frage ist - wie würde man die "Skalen" der Softwareentwicklung und der Informatik üben? Wenn ich Klavier übe, verbringe ich mehr Zeit auf Skalen und weniger auf einem lustigen Lied. Wie kann ich dasselbe bei der Entwicklung von Software tun?

Um frühzeitige Antworten zu vermeiden, halte ich "Arbeit an einem Open Source-Projekt" und ähnliche Antworten nicht für richtig. Sicher ... dass Ihre Fähigkeiten verbessern kann , aber Sie könnten genauso gut stecken bleiben und sich auf etwas konzentrieren, das für Ihr Handwerk insgesamt unwichtig ist. Es kann das Äquivalent dazu sein, "Twinkle Twinkle Little Star" zu lernen und niemals Chopin spielen zu können.

Also frage ich noch einmal: Wie würden Sie jemandem vorschlagen, der absichtlich Software-Engineering praktiziert?

48
JasCav

Es gibt einen Unterschied zwischen dem, was wir als Softwareentwickler tun, und dem, was ein Geiger (oder alles andere, was körperliche Übung erfordert) tun würde. Ein Geiger übt stundenlang methodisch, weil er seinem Gehirn sehr spezifische Muster für den Umgang mit einem Instrument beibringt.

Das Üben von Software-Engineering beinhaltet auch Lernmuster. Je mehr Projekte Sie durchführen, desto mehr lernen Sie (hoffentlich) darüber, was funktioniert und was nicht. Es gibt kein Standardrezept für das Schreiben großartiger Software (deshalb vergleichen manche Leute unseren Beruf eher mit einem "Handwerk" als mit reiner Wissenschaft). Also mein Rat Nr. 1, schreibe Code, dann schreibe mehr Code. Und denken Sie nicht, dass es Ihnen nicht so viel beibringt, wenn das, woran Sie arbeiten, Spaß macht. Ich sage, wählen Sie etwas, das IS Spaß macht; es wird Ihr Interesse länger behalten und Sie werden sich so viel mehr amüsieren.

Sie müssen keinem Open Source-Projekt beitreten, wenn Sie dies nicht möchten. Setzen Sie sich einfach ein Ziel, etwas würde Sie interessieren, und beginnen Sie einfach mit dem Codieren. Sie müssen es nicht einmal beenden, also werden Sie nicht enttäuscht, wenn Sie nach der Hälfte des Projekts beschließen, es fallen zu lassen und zu etwas anderem zu gehen. Wenn Sie sich von diesem Projekt entfernen, müssen Sie vor allem über bessere Fähigkeiten und mehr Wissen über die von Ihnen verwendete Technologie verfügen.

Hinweis Nr. 2, lesen Sie Pragmatic Programmer . Die wichtigste Erkenntnis aus diesem Buch ist, dass Sie hin und wieder einen Schritt zurücktreten und Ihren Prozess überprüfen müssen, um über das Schreiben einer Software nachzudenken, während Sie darüber nachdenken, wie Sie eine Software schreiben. Wenn Sie arbeiten, stellen Sie es nicht einfach in ein Regal und gehen Sie weiter, sondern werfen Sie einen weiteren Blick darauf und überlegen Sie, wie Sie es besser hätten machen können. Sie müssen nicht gehen und es tatsächlich wiederholen, aber wenn Sie darüber nachdenken, werden Sie Ihr Gehirn trainieren, um die Muster zu erkennen, die ich im Intro erwähnt habe.

Tipp Nr. 3: Sprechen Sie mit anderen Personen, die leidenschaftlich gerne Code schreiben. Hören Sie, was sie getan haben und wie sie sich den Dingen näherten. Und erklären Sie ihnen, was Sie tun. Ich habe nur wenige Freunde bei der Arbeit und in regelmäßigen Abständen gehe ich einfach in ihren Würfel und skizziere schnell das Design der Software, an der ich arbeite. Manchmal nicken sie nur, aber manchmal könnten sie sagen: Wenn Sie diese Kiste hierher bewegen und diese Klasse loswerden, können Sie sich 2 Arbeitstage sparen und die Vorteile A, B und C erlangen.

Tipp Nr. 4, nachdem Sie einige Projekte durchgeführt und einige Muster gefunden haben. Gehen Sie zurück und lesen Sie Bücher wie das berühmte GoF-Buch . Wenn Sie bereits gearbeitet haben, werden Sie a) einige der Dinge erkennen, über die Autoren sprechen, und b) verschiedene Möglichkeiten entdecken, wie Sie Ihre Projekte hätten angehen können.

Tipp Nr. 5: Lesen Sie immer weiter und fordern Sie sich selbst heraus. Kommen Sie nie in den Modus, in dem ich jetzt Technologie X kenne, deshalb bin ich ein Experte. Egal wie viel Sie zu lernen glauben, denken Sie daran, es gibt unendlich viel mehr, das Sie abbrechen können. Im Großen und Ganzen wissen Sie also immer noch nicht so viel. Lesen Sie weiter Blogs; eine neue Sprache lernen. Ich habe zum Beispiel über F # und funktionale Programmierung gelesen, obwohl ich hauptsächlich in C++ programmiere und angefangen habe, funktionale Konzepte auf meinen objektorientierten Code anzuwenden. An einigen Stellen vereinfachte dies die Verwendung mehrerer Threads und die Datensynchronisation erheblich.

25
DXM

Keines der oben genannten ist Software-Engineering. Es ist alles nur eine zufällige Programmierung.

Software Engineering (SE) ist eine technische Disziplin, die sich mit einem systematischen, strengen und disziplinierten Ansatz für das Design, die Entwicklung, den Betrieb und die Wartung von Software sowie die Untersuchung dieser Ansätze befasst. das heißt, die Anwendung von Engineering auf Software.

Insbesondere kann Software entwickelt werden, wenn Sie technische Techniken anwenden. Um solche Techniken zu erlernen, ist es am besten, einen relevanten SE-Master-Abschluss zu studieren. Wenn Sie sich selbst unterrichten, lernen Sie vielleicht etwas über Programmieren, aber ich kann mir nicht vorstellen, dass Sie selbst Ingenieurwissenschaften lernen.

Beispiel: Der Programmierer kommt und beginnt mit dem Schreiben von Code, dem Optimieren von Code usw. (alles, was für einen Programmierer wichtig ist, ist Code und nichts als Code). Komplexe Projekte kommen oft zu spät, das Budget wird bis zu einigen Größenordnungen überschritten und die Software löst die Anforderungen nicht gut. Dies ist als Software-Krise bekannt. Die Antwort darauf ist die SE-Disziplin.

SE kommt und möchte als erstes die Problemdomäne verstehen. Es wird ein Engineering-Ansatz angewendet, insbesondere Requirements Engineering (RE) (Anforderungserhebung -> Anforderungsanalyse -> Anforderungsspezifikation -> Anforderungsvalidierung).

Das Ergebnis von RE ist in der Regel eine Reihe von Modellen wie das Kontextmodell, das Verhaltensmodell und das Geschäftsprozessmodell. Aus diesen Modellen versteht SE das Geschäftsproblem und entwirft eine Softwarelösung.

Das Design bedeutet normalerweise, dass SE Anforderungsmodelle in eine komponentenbasierte Systemarchitektur übersetzt und dann das Komponentendesign für jede Komponente einzeln erstellt. Dies führt zu einer bestimmten Spezifikation von Komponentengrenzen, Komponentenschnittstellen und Klassen, aus denen Komponenten zusammengesetzt werden sollen.

Der nächste Schritt ist jemand, der zu diesen (normalerweise automatisch generierten) Schnittstellen kommt und deren Implementierung erstellt. Diese Person kann ein Programmierer sein. Schließlich folgt SE mit der Software-Validierung, bei der alles anhand des ursprünglichen Designs und der Anforderungen getestet wird.

In SE verfügen Projekte normalerweise über einen Projektplan, mit dem Ingenieure Projekte planen, steuern und überwachen können. Insbesondere wird Software pünktlich, im Rahmen des Budgets und nach Spezifikation entwickelt.

Während der Implementierungsphase der Software wird für jedes Artefakt eine Dokumentation erstellt und viele Konfigurationselemente (Configuration Items, CIs) werden generiert. Diese müssen irgendwie verwaltet werden. Normalerweise gibt es in SE ein SCM-Repository (Software Configuration Management) und ein Änderungsmanagement. Ein weiterer Teil von SE ist Software Process (SP), d. H. RUP, Scrum, DSDM, Crystal, Waterfall, ...

SP muss ausnahmslos wie in der Dokumentation dokumentiert und genau befolgt werden, damit die Ergebnisse immer reproduzierbar sind. (ISO 9000). Dies bezieht sich auf die Softwarequalität.

Ein weiteres SE-Thema ist Softwaremessung und -schätzung, mit der Sie die Effizienz Ihres SP, die Teamleistung, die geschätzte Projektgröße (LOC - Lines of Code), d. H. COCOMO, die geschätzte Projektabwicklung (Manntage) und ähnliches messen können.

SE hat noch viel mehr zu bieten, als diese kurze Antwort beschreibt. Wenn Sie SE-Ansätze anwenden, anstatt nur Code zu schreiben, üben Sie SE.

Da SE immer noch ein aufstrebendes Gebiet ist, nennen sich Nicht-Ingenieure selbst Ingenieure. Sofern sie keine technischen Ansätze anwenden, sind sie lediglich Programmierer.

Weitere Informationen finden Sie unter Software Engineering von Ian Sommerville und www.ieee.org/www.computer.org. In diesen Ressourcen ist SE die technische Disziplin. Bei Stack Overflow und in vielen Unternehmen leihen sie sich leider den Begriff SE aus und verwenden ihn als anderen Namen für die Programmierung.

8
user42242

Zwei Dinge, die mir in den Sinn kommen, sind Project Euler und Googles AI Challenge . Insbesondere wenn Sie dies in einer anderen Sprache als Ihrer täglichen Arbeitssprache tun, sind diese Probleme so eingeschränkt, dass Sie Ihre Fähigkeiten erweitern können, aber auch so einfach, dass Sie klare Ansätze haben.

Ich habe dieses Jahr die KI-Herausforderung gemacht, und was mich am meisten fasziniert, ist, dass das Problem einfach genug ist, um mit grundlegenden Algorithmen gelöst zu werden, aber Sie werden das Zeitlimit pro Runde erreichen, wenn Sie es auf naive Weise tun . Sie müssen nicht nur den roten Teil der Grundlagen verstehen, sondern auch die zugrunde liegenden Gründe dafür, damit es innerhalb der Zeitbeschränkungen funktioniert.

6
Karl Bielefeldt

Nachdem Sie einen Codeblock geschrieben haben, der funktioniert und einen Test besteht, fragen Sie sich: "Kann dieser Code besser sein?". Besser bedeutet in diesem Zusammenhang nicht unbedingt schneller oder effizienter, obwohl das ein Teil davon ist. Die Klarheit des Codes ist ebenfalls wichtig - kann jemand darauf schauen und verstehen, was er tut? Fragen Sie sich, ob Sie diesen Code einem potenziellen Arbeitgeber als Vertreter Ihrer besten Arbeit vorlegen würden.

Tun Sie dies nicht nur für Ihren persönlichen Code. Besuchen Sie Websites wie diese und beantworten Sie Fragen, bei denen Sie ein funktionierendes Beispiel angeben müssen. Das Schreiben von Code, der eines Tages von Menschen kopiert und verwendet werden kann, die gerade lernen, kann ein starker Motivator sein. Stellen Sie sicher, dass Sie dies mit Ihrem richtigen Namen tun, damit Sie keine andere Wahl haben, als ihn als Ihren eigenen zu beanspruchen.

Eine andere Möglichkeit, dies zu tun - und ich sehe, dass Sie es sind - besteht darin, ein Blog zu schreiben, in dem Sie Code bereitstellen müssen. Dies zwingt Sie wiederum dazu, Code zu schreiben, der in der Öffentlichkeit für Kritik offen ist.

Wenn Sie Code schreiben, der von anderen gelesen und geprüft wird, entspricht dies meiner Meinung nach dem Üben von Skalen.

3
Bryan Oakley

Ein Ansatz könnte darin bestehen, ein relativ nicht triviales Projekt (z. B. über 1000 Zeilen) in andere Sprachen zu portieren. Sie werden feststellen, dass dies viele Annahmen hervorhebt, die Ihre Sprache für Sie getroffen hat.

Ein anderer Ansatz könnte darin bestehen, ein größeres Projekt zu bestimmen - nach Ihrer Schätzung mindestens 10KLoC - und es schnell zu schreiben. Schreiben Sie es weiter und pflegen Sie es, nachdem es sein Ziel erreicht hat. Hier erfahren Sie, wie Sie Codebasen verwalten, die im Laufe der Zeit mutieren.

Nur ein paar Gedanken.

3
Paul Nathan

Wie übt ein Schriftsteller das Schreiben von Büchern?

OK, ich wollte damit sagen, dass das Schreiben von Code nicht mit dem Beherrschen eines Musikinstruments vergleichbar ist. Die Rolle eines Programmierers ist eher ein Schriftsteller oder ein composer, der versucht, den richtigen Akkord zu finden. Sie sollten sich also fragen, wie diese Profis stattdessen ihr Handwerk üben. Eigentlich denke ich, dass unser Beruf mehr hat gemeinsam mit denen als mit anderen Ingenieurdisziplinen.

Ein Autor übt das Schreiben durch Schreiben von Büchern und ein composer übt das Komponieren durch Komponieren von Musik, daher sollte ein Programmierer das Programmieren durch Programmieren üben.

1
onemasse