Was sollte ein "beginnender Entwickler" über Architektur und Planung wissen [geschlossen]

8

Ich arbeite schon seit Ewigkeiten mit C und C #, ich halte mich für einen "ziemlich guten" Programmierer, aber wie schon oft erwähnt, ist Programmierung nur ein kleiner Teil der Softwareentwicklung und -entwicklung. Ich bin der einzige Programmierer für meine Abteilung, aber es sieht so aus, als ob sich das ändern wird. Was ich von der Stackoverflow-Community wissen möchte, ist folgendes:

  • Was braucht es, um vom Coder zum Entwickler zu wechseln? - Ich habe Code Complete gelesen, also glaube ich, dass ich bereit bin, diesen Sprung zu wagen. Bis zu einem gewissen Grad bin ich schon.
  • Welche Werkzeuge soll ich verwenden, wenn ich Modelle meiner Software mache? - nehme C #
  • an
  • Wie tief sollte ich meine Architektur modellieren, bevor ich harten und schnellen Code festlege? - Ich verstehe, wie subjektiv diese Frage ist, und ich hätte gern mehr Faustregeln als "naja, es kommt darauf an." Angenommen, ich schreibe im Haus Werkzeuge, die "5-10 Jahre" dauern sollen
  • Welchen Rat würden Sie jemandem geben, der den Schritt vom Coding zum Engineering macht?

Vielen Dank im Voraus! Haben Sie einen tollen Gedenktag!

    
Firoso 20.05.2009, 18:17
quelle

4 Antworten

17

Zunächst die generischen Antworten:

  • Verstehen Sie, dass jedes gegebene Tool keine Wunderwaffe ist, um all Ihre Probleme zu lösen. Wenn du also über MVC oder Functional Programming liest oder jemand ausspuckt, dass LISP all deine Probleme lösen wird, werden sie es nicht tun. Sie können eine ganze Reihe von Problemen lösen, die Sie haben, aber sie werden sie nicht alle lösen. In vielen Fällen werden sie nicht nur einige Probleme lösen, sondern auch eine ganze Reihe anderer vorstellen.
  • Verstehen Sie die Einschränkungen und Vorteile verschiedener Komponenten / Technologien / Tools, um Lösungen für jedes Problem zu finden. Treffen Sie Ihre Entscheidungen basierend auf der Auswertung aller Vor- und Nachteile - treffen Sie Ihre Entscheidungen nicht blind.
  • Wählen Sie die richtigen Tools für den Job, einschließlich Sprache, Entwicklung, Integrationstechniken.
  • Wer wird den Code beibehalten? Code für die erwartete Zielgruppe Wenn das der Fall ist, erwarte nicht, dass du in sechs Monaten einen Fix bekommst, der dich daran erinnert, was dein Denkprozess heute war ... schreibe einen Code, der einfach liest und deinen Denkprozess dokumentiert. Nicht das "Wie" - der Code macht das, sondern das "Warum". Ganz gleich, wie einfach der Code zu lesen ist, er kann Ihnen nicht sagen, warum Sie so vorgegangen sind. Code-Kommentare sind für das Warum, nicht das Wie.
  • Verstehen Sie Ihre Benutzer, wie sie arbeiten, ihre Mentalität gegenüber ihren Tools, was ihre Jobs sind, wie ihre Einstellung gegenüber der Lernkurve für Ihre Software ist.
  • Verstehen Sie die Mentalität der Person / des Teams, die / das Ihre Bewerbung unterstützt - dies bedeutet auch die Installation.
  • Verstehen Sie die Notwendigkeit der Quellenkontrolle und verwenden Sie sie.
  • Backups, nehmen Sie immer an und bereiten Sie sich auf das Schlimmste vor, wenn Sie nicht wünschen, dass Sie getan haben.
  • Erfahren Sie, wie Sie Software-Spezifikationen, technische Spezifikationen, Testdokumentationen und Benutzerdokumentationen schreiben.
  • FAT / SAT / UAT Test- und Abmeldeverfahren.
  • Setzen Sie niedrigere Erwartungen, als Sie liefern können, versprechen Sie dem Kunden keinen Lambourghini und liefern Sie einen Volkswagen Käfer [Bug]. Viel besser, den Käfer zu versprechen und einen Mercedes auszuliefern.
  • Überfordern Sie nichts - das schließt architektonisch, programmatisch oder irgendetwas anderes ein. Die Dokumentation sollte einfach zu lesen sein, die Oberfläche sollte einfach zu bedienen sein.

Jetzt die Besonderheiten:

  • Sie müssen verstehen, dass Sie das Problem untersuchen und die Problemdomäne verstehen müssen, bevor Sie beliebige Lösungen (architektonisch oder anders) bereitstellen können.
  • Verstehen Sie, was die Benutzer erwarten, wie sie geliefert werden und wie sie damit umgehen.
  • Finden Sie die am wenigsten technisch versierte Person, die Ihre Lösung verwenden wird, wenn sie es verstehen können, werden alle anderen auch.
  • Entwerfen Sie Ihre Software für Ihre Benutzer und Ihre Geldgeber. Wenn diejenigen, denen Sie es liefern, es nicht benutzen können / wollen, werden Sie nie das Ende davon hören - selbst wenn Ihre Finanziers anfänglich zufrieden sind, werden sie sehr schnell widerrufen.

Wenn Sie nicht planen, planen Sie einen Fehler

Ihre Umgebung, Ihre Softwareanforderungen, Ihre Zielgruppe, Ihr Netzwerk-Support-Personal, Ihr Budget und viele andere Faktoren werden die von Ihnen bereitgestellten Lösungen stark beeinflussen. Zum Beispiel neige ich in der Art von Umgebung, für die ich code, zu einer endlichen Menge von Werkzeugen für die Lieferung von Produkten, und sie werden wahrscheinlich für Ihre Umgebung variieren:

  • Webbrowser - IE / Firefox / Opera / Safari
  • Anwendung / Dateiserver - Windows Server, Linux, Unix
  • Webserver - IIS / Apache
  • Entwicklung von Webanwendungen - ASP.NET/C#/VB.NET/ASP/PHP/JavaScript/AJAX/MVC
  • Konsolenanwendungsentwicklung - BAT / C # / VB.NET [Schreiben Sie keine vollständige C # -App, wenn eine BAT-Datei die Arbeit viel einfacher macht].
  • Windows-Anwendungsentwicklung - C # / VB.NET
  • Datenpflege - C # / VB.NET / Excel / VBA
  • Datenbankserver - SQL Server, MySQL, Oracle
  • Netzwerk / Daten / Dateiintegrationsdienste - MSMQ, BizTalk, SonicMQ, FTP

Ich kann eine oder mehrere dieser Technologien für meine Lösung ausschließlich von dem abhängig machen, was von mir verlangt wird. Der Schlüssel ist zu verstehen, was für eine gegebene Situation relevant ist und nur diejenigen zu verwenden, die notwendig sind. Schreiben Sie beispielsweise keine vollständige Webanwendung, wenn ein Befehlszeilendienstprogramm einfach von einem einzelnen Benutzer verwendet werden kann. Schreiben Sie keine Windows-Anwendung, wenn viele Benutzer Zugriff auf eine Anwendung haben, die nicht einfach auf ihren Rechnern installiert werden kann aufgrund von Benutzereinschränkungen und eingeschränkten Systembetreuern. Schreiben Sie kein Befehlszeilendienstprogramm für Benutzer, die kaum mit der Maus durch Windows navigieren können und erwarten Sie nicht, dass ein Microsoft-Experte Ihr * nix-basiertes System unterstützt.

Stellen Sie Diagramme und Dokumentationen zur Verfügung, mit denen Probleme einfach diagnostiziert werden können. Wenn Probleme gefunden werden [und sie werden], kann der Support von users / desksides den Problem für eine bestimmte Komponente im System. Dies wird Ihnen das Leben erleichtern, da sie entweder in der Lage sind, es selbst zu reparieren oder Ihnen genügend Informationen zur Verfügung stellen, um das Problem schnell und einfach zu beheben.

Bearbeiten : Als Antwort auf Ihren Kommentar zu UML, der für diesen Zweck sehr gut ist, müssen Sie sich aber wieder Ihrer Zielgruppe bewusst sein. Wenn Sie ein einzelner Programmierer sind, der Systeme für einen kleinen Kunden entwickelt, dessen Mitarbeiter UML nicht verstehen, würden Sie genauso gut einen normalen Ablaufplan mit einfachem Englisch bereitstellen. Wenn Ihre Zielgruppe eine Softwareberatung ist, deren Aufgabe die Softwareentwicklung ist, dann ist UML auf jeden Fall ein großartiges Werkzeug - besonders wie bei einigen UML - Tools können Sie Ihre Stub - Klassen / Methoden automatisch generieren lassen, um einige davon zu automatisieren verarbeiten. Ich tendiere dazu, in kleinen Teams für kleine Unternehmen zu arbeiten, also benutze ich UML nicht so oft, wie ich möchte, und verstehe es wahrscheinlich nicht so gut, wie ich sollte, aber das heißt nicht, dass ich es nicht tun würde, wenn ich dazu aufgefordert würde putze es nicht auf. Es ist ein großartiges Tool in Ihrer Toolbox, aber verwenden Sie es nicht nur um es zu tun. Alles, was Sie im Design / in der Architektur / Entwicklung Ihrer Lösung verwenden, sollte aus einem objektiven Grund verwendet werden - verwenden Sie es nicht blind, denn jemand sagt: "Sie sollten das verwenden, weil es großartig ist".

Der Schlüssel zu guter Architektur ist dies:

  • Verstehen Sie die Werkzeuge, die Sie verwenden
  • Verstehen Sie die Gründe, warum Sie die Tools, die Sie für einen bestimmten Zweck verwenden, nicht verwenden sollten und sollten
  • Treffen Sie sachkundige Entscheidungen objektiv, stützen Sie sich nicht auf Hörensagen oder Emotionen.

Und vor allem:

  • Benutze deinen gesunden Menschenverstand !! Wenn etwas nicht richtig klingt oder sich nicht richtig anfühlt, finde heraus, warum das so ist. Im schlimmsten Fall wirst du herausfinden, dass du falsch liegst und ein Missverständnis / Missverständnis korrigiert hast. Im besten Fall hast du eine Menge Zeit gespart eine potenziell teure Option, die auf diesem Missverständnis beruht - so oder so, dass Sie besser dran sind als Sie.
BenAlabaster 20.05.2009, 19:15
quelle
5

Beachten Sie Folgendes:

  • Abstraktionen - sauber, einfach und zu der Punkt
  • Vervielfältigung - vermeiden Sie es, ernst
  • Abhängigkeiten - Ebenen Architektur, wo Schnittstellen sind Haken zum Aufhängen
  • Unveränderlichkeit - die mehr geht es um Wandelbarkeit (besonders in gleichzeitigem Umgebung) je mehr Sie beginnen zu schätzen wissen, keinen Staat zu haben.
  • Annahmen - machen Sie sie nicht, lassen Sie keine Verantwortung auslaufen. Demeter-Gesetz ist hilfreich.

Iteratives Entwerfen und Codieren mit jemandem, der Ihre Ideen überprüft oder teilt, ist enorm wichtig. Sie werden blinde Flecken haben. Probieren Sie sogar paar Programmierung.

Tests sind auf lange Sicht entscheidend. Sie sichern deinen Rücken und geben dir die Freiheit, dich ohne Angst zu verändern. Angst ist die Kraft, die zu Duplikation, Blähungen und Unreinheit führt.

    
egaga 20.05.2009 18:24
quelle
1

Meiner Meinung nach ist das Lesen von Büchern, Artikeln oder Blogs sehr wichtig. Aber es ist nicht genug. Versuchen Sie, einen erfahrenen Entwickler / Architekten zu finden, der Sie leitet. Der Wechsel vom Programmierer zum Architekten wird sehr lange dauern und Erfahrung ist das Wichtigste.

Versuchen Sie, Projekte zu bekommen, in denen Sie neue Technologien erforschen und studieren können. Aber, wirklich, versuche einen Mentor zu finden.

    
tanascius 20.05.2009 18:23
quelle
0

Schritt eins: Fragen Sie die guten Leute bei Stack Overflow.

ok guten Start

Andere Schritte: Ich entschuldige mich, dass dies keine direkten Antworten auf Ihre Fragen sind, aber hoffentlich werden sie Ihnen helfen, sie zu finden.

Wenn Sie sich in der Nähe einer Universität oder technischen Hochschule befinden, können Sie, wenn Sie einen Software-Engineering-Kurs belegen, eine längere Zeit einplanen, als Sie und Ihr Unternehmen sich leisten können, aber diese Professorentypen haben normalerweise einen guten Rat.

Sie sind also eine Ein-Mann-Operation, wie? Source Control ist ein Stück Kuchen, huh? Nicht mehr, du musst lernen, dass die Kontrolle über die Quelle dein bester Freund auf der ganzen Welt ist, nicht deine Frau, nicht dein Hund, es ist deine Quellcode-App.

Stellen Sie gute Programmierer ein! Der Unterschied von einem Programmierer zum nächsten ist enorm, ein mittelmäßiger oder schlechter Programmierer in Ihrem Team ist ein großes Problem. Im Interview geben Sie ihnen Fragen, die wirklich hart sind und Sie würden wahrscheinlich selbst vermasseln, in dieser Wirtschaft sollten Sie viele zur Auswahl haben, also stellen Sie sicher, dass Sie ein Genie bekommen.

eine vorherige Antwort sagte, einen Mentor zu finden, stattdessen Joel über Software lesen.

Ссылка

    
Atilio Jobson 20.05.2009 19:36
quelle

Tags und Links