Warum so ernst, äh ... komplex?

Question

Ich warf gerade einen Blick auf eine Frage-Liste auf dieser Seite und es brachte mich zum Nachdenken. Ich sehe viele Fragen wie:

• Sollte ich XYZ mit meinem Paket bereitstellen oder einen Verweis auf einen anderen Pfad hinzufügen?
• Wie konfiguriere ich nant/cruisecontrol/etc .. um meine Komponententests auszuführen?
• Wo soll ich meine Config-Dateien für Unit-Tests in XYZ-Setup halte
• etc ...

Nun, wenn ich entwickeln (.NET und Visual Studio), wähle ich eine ganz bestimmte Verzeichnisstruktur :

• doc: enthält alle documetnation
• lib: enthält kompilierten Abhängigkeiten
• src: enthält alle Programmquelle und Abhängigkeitsquellen
• etc: Verschiedene Dateien mit dem Projekt
• ist: kompilierte Programm Ausgabe

Generell, wenn etwas nicht innerhalb dieser Verzeichnisstruktur durchgeführt werden kann, ich kann es einfach nicht tun. Dazu gehören Komponententests, kontinuierliche Integration usw. Im gleichen Licht läuft mein gesamtes Programm mit Ausnahme von Betriebssystem- oder Netzwerkreferenzen aus dem Verzeichnis bin. Ich weigere mich, Abhängigkeiten in das Dateisystem einzuführen, die nicht im Stammverzeichnis meines Programms liegen. Ich bin sicher, dass ich einige wirklich coole Aspekte der Entwicklung verpasse, aber ich habe Cruise Control versucht und ich habe versucht nant und um ehrlich zu sein, als jemand, der mit vielen kleinen Projekten arbeitet (200+ kleine Projekte ein Jahr), im Gegensatz zu ein paar (10-20) großen Projekten, kann ich ehrlich sagen, dass die Einfachheit wünschenswerter ist als einige der Vorteile der Verwendung dieser Werkzeuge.

Ich denke meine Frage ist, bin ich nur ein Dummkopf oder scheint es, dass bestimmte Dinge nur viel komplexer sind, als sie sein müssen? Diese ganze "Design, so dass es für alle passt" -Mentalität scheint wirklich im Weg zu sein, Dinge zeitweise zu erledigen.

Answer 1

Ich sehe Ihren Punkt darüber, wie Menschen die Dinge übermäßig komplizieren können. Zu beachten ist jedoch, dass die Verwendung von "Extras" nicht immer speziell dazu gedacht ist, das Programmieren zu erleichtern. Manchmal werden sie verwendet, um es in irgendeiner Weise besser zu machen. Mit diesen zusätzlichen Tools handeln Sie Einfachheit für etwas anderes.

Zum Beispiel fügt die Verwendung eines Unit-Testing-Frameworks dem Projekt definitiv mehr Komplexität hinzu. Sie handeln jedoch Einfachheit für mehr fehlerfreien Code (in der Theorie).

Es variiert wahrscheinlich auf Entwickler-zu-Entwickler-Basis. Für jemanden wie dich scheint die Einfachheit von größter Bedeutung zu sein. Vielleicht erhalten Sie dadurch eine höhere Geschwindigkeit und weniger Zeit für die Suche nach Lösungen für Konfigurationsprobleme. Aber jemand anderer ist vielleicht bereit, etwas Zeit mit einem Framework zu spielen, um sich sicherer zu fühlen, dass sein Code solide ist.

Answer 2

200 + kleine Produkte pro Jahr ist fast eins pro Arbeitstag. Ich denke nicht, dass die Probleme, die Menschen bei großen Projekten haben, auf Sie zutreffen werden.

Ich bin neugierig. Was sind all diese kleinen Projekte, an denen du arbeitest? Es klingt lustig. Aber wenn ich so viele Projekte pro Jahr machen müsste, würde ich Python und nicht .NET verwenden. Es sei denn, Sie verwenden IronPython.:-)

Answer 3

Im Allgemeinen, wenn etwas nicht innerhalb dieser Verzeichnisstruktur getan werden kann, mache ich es einfach nicht. Dazu gehören Unit-Tests, die kontinuierliche Integration,

kleine Projekte (200+ kleine Projekte pro Jahr) als

Unter der Annahme, auf wenige (10-20) große Projekte gegenüber, dass Sie selbst arbeiten, Ihre Große Projekte (< 1 Personenmonat) würden in den meisten Geschäften "klein" und Ihre kleinen Projekte (1 Tag) "Aufgaben" heißen. Große Projekte, wie die Software für den Joint Strike Fighter oder staatliche Informationssysteme, sind Hunderte von Personenjahren. Die meisten kleinen Projekte, an denen ich gearbeitet habe, waren 2-6 Monate, und die mittleren 1-4 Jahre.

Ich denke, meine Frage ist, bin ich nur ein Dummkopf oder scheint es, dass bestimmte Dinge nur viel komplexer sind, als sie sein müssen?

Bestimmte Dinge sind komplexer, als in einem Programmiermonat erstellt werden können.

Die kontinuierliche Integration ist bei Projekten von weniger als einem Monat wahrscheinlich nicht sinnvoll, da Sie keine Zeit haben, ein System aufzubauen, in dem Sie viel nicht integrierte Arbeit haben.

Sobald Sie an etwas arbeiten, das groß genug ist, um zu vergessen, was einige Teile davon tun, oder auf etwas mit mehr als einem Entwickler, geben Komponententests einen guten Mechanismus zur Angabe des beabsichtigten Funktionsverhaltens des Systems in eine eindeutige Art und Weise.

Wenn Sie ein Softwareprogramm für verschiedene Bereitstellungen konfigurieren und bereits ein gutes Vertrauen in die Software haben, sind Tests auf Systemebene oft ausreichend.