nicht angemeldet
IT-Geschäftslogik, Tipps gesucht
hi Leute,
ich möchte ein Web Projekt starten.
ich habe einen Windows 2012 Server mit 1-2 GB Arbeitsspeicher zur Verfügung (wieviel Gb genau weiß ich erst wenn ich ihn habe) und ein einfaches Webpacket auf dem JavaScript, PHP, Python etc läuft.
ich möchte eine Anwendung bauen wie folgendes tut: a) der kunde (b2b und b2c) läd sich ein Plugin von der seite b) fügt das plugin in eine Software auf seinem rechner ein c) über das plugin werden alle relevanten Daten an das web projekt weitergeleitet d) der kunde kann auf der Webseite verschiedene dienste nutze, vorher muss er sich einloggen
meine erste Idee zur Realisierung war: -> JavaScript für das backend vom frontend -> Java fürs backend (aufruf von r scripten, Daten aus dem Internet loopen usw), build tool wäre maven -> r Gnu scripte für statistische berechungen -> mysql Datenbank im backend zur Verwaltung der Login Daten und aller sonstigen relevanter Daten -> c++ für die plugins (Java geht da leider nicht, alternativ würde python gehen)
da das ziemlich viele verschiedene Programmiersprachen sind, ist mir die Idee gekommen frontend, backend, Statistik und die plugins in python zu machen und tsql zu verwenden und auf eine solide lösung in tsql und python zu setzen.
was meint ihr dazu? habt ihr paar tips für mich? (das projekt ist zu klein um einen experten zu angagieren, darum bau ich lastenheften usw allein, erste Prototypen habe ich schon gebaut)
-
hi,
was meint ihr dazu? habt ihr paar tips für mich? (das projekt ist zu klein um einen experten zu angagieren, darum bau ich lastenheften usw allein, erste Prototypen habe ich schon gebaut)
Echt schwer zu sagen. Ich hab mit Perl angefangen, ein paar Jahre damit programmiert und irgendwannmal sagte da einer:
Was, CGI's in Perl entwickeln!? Das ist völlig OUT! Wenn schon CGI's entwickeln dann in c!!!
Kaum hat' er's gesagt, viel PHP vom Himmel...
-
Kaum hat' er's gesagt, viel PHP vom Himmel...
Manche munkeln auch, PHP sei aus der Hölle empor gestiegen.
-
jo, kniffelige Sache
der Vorteil wäre, dass ich alles mit python und tsql machen könnte, aber ich weiß nicht ob das am ende eine "stabile" it-lösung wird, die aktuell, modern, und wartbar gehalten werden kann und die von geschäftskunden akzeptiert wird.
tsql würde ich übrigens nehmen, weil ich einen Windows Server 2012 habe, aber ka ob das die ideale DB für meine Sache ist. ich kenn plsql und finde das besser als mysql.
meine ziele wären:
- alles (frontend, Statistik, backend, plugins) mit einer objectorientierten sprache gebacken kriegen, auch wenn das projekt so groß wird das hunderte Entwickler dransitzen
- die sprache sollte modern bleiben
- leicht sein, so dass ich zb javaentwickler schnell auf die sprache umschulen kann
- idealerweise bin ich nicht von den machern der sprache abhängig, bzw. kann sie selber "weiterentwickeln" oder sie mit einer anderen sprache auf effiziente weise kombinieren
- die Software die mit dieser sprachegebaut wird sollte, auch wenn sie stark wächst, skalierbar, überwachbar etc. sein
- eine ideale Datenbank finden...
macht es sinn große Projekte mit python anzugehen oder fehlt mir da zuviele zeug dass ich zb bei Java in form viele Werkzeuge und standartklassen ad hoc habe?
-
-
Moin!
Das klingt mir alles noch viel zu unstrukturiert und von der falschen Seite her gedacht.
ich habe einen Windows 2012 Server mit 1-2 GB Arbeitsspeicher zur Verfügung (wieviel Gb genau weiß ich erst wenn ich ihn habe) und ein einfaches Webpacket auf dem JavaScript, PHP, Python etc läuft.
Fehler Nummer 1: Zuerst die Technik festlegen.
Natürlich gibt's bei der Umsetzung eines Projekts immer limitierende Faktoren, die Einfluss nehmen. Beispielsweise der Kenntnisstand der Beteiligten - man wird keine Programmiersprache wählen, die man erst neu lernen muss, wenn in einer andere Sprache bereits Erfahrungen gemacht wurden.
Dennoch: Erst den Server anschaffen (noch dazu mit nicht so ganz klaren Hardwaredetails) klingt falsch.
ich möchte eine Anwendung bauen wie folgendes tut: a) der kunde (b2b und b2c) läd sich ein Plugin von der seite b) fügt das plugin in eine Software auf seinem rechner ein c) über das plugin werden alle relevanten Daten an das web projekt weitergeleitet d) der kunde kann auf der Webseite verschiedene dienste nutze, vorher muss er sich einloggen
Ähm... steht in diesem Absatz überhaupt irgendwas konkretes?
Ich kritisiere mal zuerst den Fokus: B2B und B2C lädt sich ein Plugin runter - wirklich? Während du bei B2B je nach Unternehmensgröße eventuell das Glück hast, auf eine kompetente IT zu treffen (und das Pech, auf eine festgelegte, nicht mal eben änderbare IT-Infrastruktur zu treffen), hast du bei B2C eigentlich die Garantie, komplett auf Noobs zu treffen, die extremen Bedarf an Support haben. B2C klingt nach einer schlechten Idee für's Plugin runterladen.
Überhaupt "Plugin": "Für eine Software"... Ich kenne gerade bei B2C eigentlich nur genau eine Software, die zuverlässig installiert ist: Irgendein Browser. Und schon das umfasst ein Minenfeld an inkompatiblen Varianten, Altversionen, unerwarteten Restriktionen etc...
Denn eigentlich geht's erstmal um was anderes: "Mit Login werden irgendwelche Daten hin- und hergeschickt"
Damit hätten wir dein Vorhaben schon mal in zwei unabhängige Projekte zerteilt: Du möchtest einerseits serverseitig eine netzwerkseitige API entwickeln, und andererseits clientseitig Implementierungsunterstützung durch Anbieten eines API-Clients bieten.
Das ist eigentlich prima, dann kannst du auf den Client nämlich erstmal verzichten und dich auf deinen Business-Case innerhalb der API konzentrieren. Denn wenn die API nicht läuft und keinen hinreichenden Grund bietet, dass man mit ihr überhaupt kommunizieren will, implementiert auch niemand einen Client (oder nimmt deinen).
Fehler Nummer 2 also: Business-Case nicht klar genug dargestellt. "Irgendwelche Daten verschicken - mit Login" ist kein Geschäftsmodell.
meine erste Idee zur Realisierung war: -> JavaScript für das backend vom frontend -> Java fürs backend (aufruf von r scripten, Daten aus dem Internet loopen usw), build tool wäre maven -> r Gnu scripte für statistische berechungen -> mysql Datenbank im backend zur Verwaltung der Login Daten und aller sonstigen relevanter Daten -> c++ für die plugins (Java geht da leider nicht, alternativ würde python gehen)
Fehler Nummer 3 (analog zu 1): Von Anfang an in Technologie zur Problemlösung denken, noch ohne das Problem überhaupt definiert zu haben.
Warum willst du Javascript für das Frontend-Backend? Warum willst du Java für das Backend? Warum willst du R für statistische Berechnungen? Warum willst du C++ für die Plugins? Warum willst du MySQL für die Datenbank?
Und vor allem: Warum willst du Zeugs, das in deiner Serverbeschreibung gar nicht auftaucht (MySQL ist bei Windows eher ungewöhnlich, funktioniert aber - eine DB ist aber ebenso wie Java nicht erwähnt).
Die eigentlich zu beantwortende Frage wäre: Welche Aufgabe ist zu lösen? Diese Frage zu beantworten ist nicht leicht. Vor allem muss sie in einer Form beantwortet werden, die man auch niederschreiben kann, um sie anderen Entwicklern, die ggf. mithelfen sollen, auch mitzuteilen.
da das ziemlich viele verschiedene Programmiersprachen sind, ist mir die Idee gekommen frontend, backend, Statistik und die plugins in python zu machen und tsql zu verwenden und auf eine solide lösung in tsql und python zu setzen.
Aha, es gibt also für Javascript, Java, R, MySQL und C++ gar keinen Grund.
Dennoch: Du bist der Umsetzung deines Geschäftsmodells mit der Diskussion über die zu verwendenden Tools keinen Millimeter näher gekommen.
Wie du richtig erkannt hast: Alle Programmiersprachen sind turing-vollständig, also lässt sich jedes Problem, das man überhaupt mit Programmieren lösen kann, in jeder Sprache lösen.
Aus Komplexitätsgründen hast du natürlich Recht, die Menge an Technologien eventuell klein zu halten. Allerdings: Warum dann Python und nicht Java? Java ist schließlich DAS Tool für Enterprise-Applikationen. Warum nicht PHP? Das ist schließlich DAS Tool für schnelle, agile Applikationsentwicklung, und man findet sogar Entwickler, die das beherrschen, auf dem Arbeitsmarkt.
was meint ihr dazu? habt ihr paar tips für mich? (das projekt ist zu klein um einen experten zu angagieren, darum bau ich lastenheften usw allein, erste Prototypen habe ich schon gebaut)
Nutze den Prototypen - es ist ja scheinbar funktionsfähiger Code. Erweitere ihn. Warum alles wegwerfen und neubauen (außer es gibt dafür Gründe)?
Da du anscheinend schon von Enterprise-Level träumst:
meine ziele wären: 1. alles (frontend, Statistik, backend, plugins) mit einer objectorientierten sprache gebacken kriegen, auch wenn das projekt so groß wird das hunderte Entwickler dransitzen
Vergiß es, du wirst niemals nie nicht mit deinem aktuellen Wissensstand (und da meine ich ausdrücklich NICHT deine Kenntnisse über Softwareentwicklung und Projektmanagement allgemein, sondern ganz speziell dein Wissen über die mit der zu entwickelnden Software zu lösenden Probleme für dein Geschäftsmodell) eine Architektur bauen können, die tragfähig ist, einmal eine Projektgröße von "mehreren hundert Entwicklern" zu haben.
Der Grund ist recht simpel: Es gibt eine Korrelation zwischen Architektur und Anzahl Zeilen Code im Projekt. Diese Antwort hier gibt eine grobe Einschätzung: http://programmers.stackexchange.com/a/85248
Unter 10k Zeilen ist das Projekt winzig, nicht der Rede wert. Mutmaßlich ist dein Prototyp noch in diesem Bereich.
10k bis 100k Zeilen sind kleine Projekte, die aber schon komplex genug sind, dass man ein paar Experten ranlassen sollte.
100k bis 2M Zeilen sind mittlere Projekte, die definitiv ein spezialisiertes Entwicklerteam (oder mehrere) benötigen, die andererseits auch schon ausreichend technische Schulden angesammelt haben, welche bei der Weiterentwicklung hinderlich sind.
Über 2 Millionen Zeilen Code sind große Projekte. Sie sind so groß und komplex, dass kein einzelner Entwickler mehr alles verstehen kann - entweder versteht er von allem etwas (dann ist er Architekt und steckt auf High-Level die Dinge zusammen), oder er versteht alles von einem Detail (dann ist er der Entwickler, der vom Architekten die Vorschläge bekommt, wie er mit den anderen Komponenten anderer Entwickler zusammenarbeiten soll).
Die Messgröße ist dabei eigentlich nicht die Codezeilenanzahl, sondern die Komplexität. Und ein beobachtbarer Nebeneffekt: Projekte wachsen mit der Zeit, und wenn sie die hier aufgestellten Grenzen in ihrer Größe überschreiten, also z.B. von 5000 Zeilen auf 15000 Zeilen wachsen, dann ändern sich die Zusammenhänge und Regeln für die Softwareentwicklung - nur rein aufgrund des Zuwachses an Komplexität.
Während ein Projekt mit 5000 Zeilen vermutlich locker von einem einzelnen Entwickler bearbeitet und erweitert werden kann, weil er sich alles problemlos merken kann, bedeutet eine Projektgröße von 15000 Zeilen ja die dreifache Menge an Code - und auch die dreifache Menge an Wünschen zur Weiterentwicklung. Das kann ein guter Entwickler vermutlich noch leisten (dummerweise erzeugt das mehr Zeilen Code, irgendwann landet man also bei 25000 Zeilen), aber auch der wird irgendwann Unterstützung durch einen zweiten Entwickler brauchen.
Und dieser zweite Entwickler ändert alles. Plötzlich reicht es nicht mehr, sich die Lösung nur im Kopf zu überlegen - man muss sie auch kommunizieren und sich abstimmen. Es reicht auch nicht mehr, dass man weiß, wo Dinge im Code abgelegt sind: Der andere Entwickler schreibt ja neuen Code, den man noch nicht kennt, man weiß also nicht mehr genau, wo was liegt. Außerdem ist vermutlich durch die gestiegene Komplexität eine Änderung in der Softwarearchitektur notwendig - oder man bekommt Änderungswünsche aufgrund der unflexiblen Strukturen nur noch immer langsamer umgesetzt. (Und umgekehrt wäre es Irrsinn, für den Prototypen bzw. die Startup-Phase schon eine wahnsinnig optimierte Architektur umzusetzen, weil sich ja immer rausstellen könnte, dass niemand das Produkt oder die Dienstleistung kaufen will).
Deshalb: Hunderte Entwickler sind definitiv in einer Codebasis von mehreren Millionen Zeilen unterwegs, und die Regeln der Softwareentwicklung in einem derart komplexen System sind ganz anders, als bei einem Prototypen auf einem Einzelserver mit 2GB RAM.
Deshalb: Vergiss das mit der zukunftsorientierten Architektur. Wird nicht funktionieren. Nicht aus Projektzuwachsgründen, und auch nicht aus Erkenntnisgewinn über die Kundenwünsche während der Projektlebenszeit.
Prio 1: Definiere dein Geschäftsmodell.
Prio 2: Definiere dein Geschäftsmodell so, dass andere es auch verstehen.
Prio 3: Definiere Features, die das Projekt als Minimalziel liefern muss, um für den Kunden nützlich zu sein, und ggf. schon Geld einbringt.
Prio 4: Wenn das alles klar ist, ergibt sich die Umsetzung auf irgendeiner Technologieplattform schon relativ von alleine.
Grüße Sven
-
Sensationelle Antwort, Sven. Besser haette ich auch nicht formulieren koennen. Die schiefe Herangehensweise "Ich weiss zwar gar nicht, was ich eigentlich bauen will aber ich hab schon mal Bauteile und Werkzeuge festgelegt" treff ich pro Woche etwa 3 bis 4 mal in Unternehmen verschiedener Groesse, besetzt mit Coding Cracks und PhDs. Immer wieder amuesant.
-