Clean Code / Software Principles - Wo seid ihr??



  • Danke @daMicha ,
    lesen hätte geholfen 😖



  • @tbird sagte in Clean Code / Software Principles - Wo seid ihr??:

    @hustbaer sagte in Clean Code / Software Principles - Wo seid ihr??:

    Was sind denn die "gültigen" Coding Standards? Es gibt einige Dinge die schon sehr stark verbreitet sind, wie eben z.B. englische Bezeichner. Aber wer sagt dass das ein "gültiger" Standard sein soll? Und was genau heisst "gültig" in dem Zusammenhang überhaupt?

    Es gibt hier nicht die eine offizielle Stelle die vorschreibt welche Standards vorgeschrieben bzw. empfohlen sind.

    Es gibt sehr wohl allgemeingültige Prinzipien / Standards, die einzuhalten sind, unabhängig von den "firmeninternen" coding styles.

    Nein, gibt es nicht. Wenn du anderer Meinung bist, bitte nenn mir die Entität die vorgibt welche Prinzipien/Standards einzuhalten sind und die Grundlage ihrer Autorität.

    Dazu lese bitte das Buch "Clean Code" von Robert C. Martin oder lese dich in die SOLID Prinzipien ein.

    Ich glaube du hast nicht verstanden was ich dir sagen will. Ganz egal was in dem Buch drinnen steht: auf welcher Grundlage forderst du dass es als allgemeine Autorität anerkannt werden muss?

    Es mag dir so erscheinen dass bestimmte Dinge allgemeingültig sind. Oder gar dass das sogar "klar" ist, und sich daher jeder daran halten sollte. Bloss ist das nur deine Wahrnehmung bzw. Meinung. Und du wirst genügend andere Entwickler finden die das ganz anders sehen. Bzw. die vielleicht grundsätzlich zustimmen dass bestimmte Dinge allgemeingültig sind und das auch völlig klar ist - aber nicht mit dir übereinstimmen welche Dinge das sind.

    Für "Englisch als Sprache in der Programmierung" kannst du die mal die Ergebnisse dieser Google-Suche ansehen: https://www.google.com/search?q=lingua+franca+software+development

    Also ich persönlich halte es im Allgemeinen für einen Fehler etwas anderes als Englisch für Bezeichner in Programmen zu verwenden. Wobei es Ausnahmen gibt, z.B. wenn man Programme entwickelt die gezielt auf die Rechtslage eines Landes zugeschnitten sind. Oder wenn das Programm sich ausschliesslich mit einer Problemdomäne befasst die "lingua franca" eben nicht Englisch ist.

    Ansonsten stimme ich dir natürlich zu, dass abweichende Regelungen innerhalb der Firma getroffen werden können - sie sind aber dann nicht "optimal" im Sinne des Software Designs.

    Lol.

    1. Ich habe das wo du mir da zustimmst gar nicht behauptet.

    2. Auch hier ist wieder das Problem dass eben nicht klar ist was die "Basis" ist von der Abweichungen gemessen werden.

    3. Ich kann selbst wenn ich die ersten beiden Punkte ignorieren nicht zustimmen. Es gibt bei so gut wie jeder Richtlinie gute Gründe davon abzuweichen bzw. sie für ein bestimmtes Projekt vielleicht sogar mit einer quasi konträren Richtlinie zu ersetzen. Gute Richtlinien führen auch eine Liste an von bekannten, guten Gründen von der Richtlinie abzuweichen. Nur fehlt diese auch oft, und vor allem kann man nicht davon ausgehen dass sie vollständig ist.

    Wobei mir 3 hier gar nicht so wichtig ist. Der Punkt den ich primär vermitteln wollte ist 2.



  • @Quiche-Lorraine sagte in Clean Code / Software Principles - Wo seid ihr??:

    @hustbaer sagte in Clean Code / Software Principles - Wo seid ihr??:

    Was sind denn die "gültigen" Coding Standards?

    Ich kenne da den MISRA-C Standard.

    MISRA-C ist zwar ein Standard der AFAIK in bestimmten Bereichen vorgeschrieben ist - aber eben nur in bestimmten Bereichen. D.h. er ist definitiv nicht allgemeingültig.



  • @Columbo sagte in Clean Code / Software Principles - Wo seid ihr??:

    Es gibt hier nicht die eine offizielle Stelle die vorschreibt welche Standards vorgeschrieben bzw. empfohlen sind.

    Zuallererst darf man nicht vergessen, dass der durchaus gueltige C++ Standard selbst auf Englisch verfasst ist, und entsprechend auch die Standardbibliothek und alle keywords etc. englisch sind. Das ist eine normative Basis fuer jeden C++ Code.

    Ein weiterer grosser Faktor ist die Lesbarkeit/Verstaendlichkeit von Code fuer andere Programmierer. Programmierer im internationalen und auch interregionalen Jobmarkt haben Englisch eben als gemeinsamen Nenner. Wie man im Internet lesen kann, schreiben auch asiatische Firmen ihren Code auf Englisch (und kommentieren ihn groessenteils auch darin). Das wird sich auch hoechstwahrscheinlich niemals aendern.

    Natuerlich kann eine deutsche Firma ihren Code deutsch schreiben, aber das wird schon ziemlich unleserlich wirken, wenn man APIs/Bibliotheken etc. benutzt die alle auf Englisch sind. Die Sprache sickert eben von "oben" (Standard & wichtige Bibliotheken/APIs, POSIX etc.) herab. Sich dagegen zu stemmen hat wenig Sinn.

    Ob es jetzt eine gute Idee ist Englisch für Bezeichner zu verwenden oder nicht ist für das worum es mir ging völlig egal. Mir ging es darum, dass @tbird hier ein paar ziemlich eindeutig absolute Aussagen gemacht hat -- und ich auf Grund seines Schreibstils auch angenommen habe dass das keine Schlampigkeit/Bequemlichkeit war, sondern ernstgemeinter Dogmatismus. Und den wollte ich nicht unkommentiert lassen.

    In seiner Antwort wird das auch nochmal schön klar:

    Es gibt sehr wohl allgemeingültige Prinzipien / Standards, die einzuhalten sind, unabhängig von den "firmeninternen" coding styles.

    Viel eindeutiger dogmatisch und absolut kann man das kaum formulieren. Und in dieser Form ist die Aussage mMn. einfach nur Quatsch.

    Genau so Quatsch wie wenn ich behaupten würde es gäbe allgemeingültige Schönheitsideale oder einen globalen Konsens darüber ob wir zwecks Senkung der CO2 Emissionen in Kernkraft investieren sollten.


    z.T. Englisch: ich stimme deinen Argumenten grösstenteils zu. Ich rate auch immer wieder Englisch zu lernen wenn ich sehe dass Leuten z.B. deutsche Compiler-Fehlermeldungen posten oder explizit (nur) nach deutschen Büchern/Tutorials fragen.

    Ich bin nur der Meinung dass es kein Argument gibt aus dem man ableiten könnte dass jeder das so sehen muss. Also dass Englisch die lingua franca der Informatik ist bestreite ich nicht. Das heisst aber nicht automatisch dass es auch für jedes Projekt oder jede Firma am sinnvollsten ist alles in Englisch zu schreiben.

    Es gibt sogar ein halbwegs gutes Gegenargument: Es gibt immer noch viele Programmierer bzw. Leute denen man das Programmieren leicht beibringen könnte (weil sie intelligent genug sind und die Grundlagen der Logik verstehen), die aber nicht Englisch können. Und diese kann man nicht einsetzen, wenn man alles in Englisch schreibt. Das Set an englischen Fachbegriffen die in der Standard Library vorkommen ist nicht sehr gross - und nur diese zu lernen ist ein viel geringerer Aufwand als sämtliche Begriffe + Grammatik zu lernen die mach braucht um englischen Code inklusive Kommentaren in der jeweiligen Problemdomäne zu verstehen.

    Gerade für kleinere Firmen kann das durchaus wichtig sein. Kleine Firmen können oft keine konkurrenzfähigen Gehälter zahlen und sind auch oft für internationale Bewerber nicht interessant - z.B. weil sie zu viele Positionen (Projektleiter, Personalbüro etc.) mit Personen besetzt haben die nicht Englisch können. Und so kann es für solche Firmen eben Sinn machen wenn sie ihren Code in der Muttersprache des eigenen Landes schreiben, damit sie Programmierer einsetzen können die nicht Englisch können.

    Und daher kann ich einer dogmatischen Aussage wie "wer was anderes als Englisch für Code verwendet, macht eindeutlich was falsch" (sinngemäss) nicht zustimmen.



  • @tbird sagte in Clean Code / Software Principles - Wo seid ihr??:

    Es gibt Auftraggeber, die für ihre hausinterne Software ein Dokumentationssprache vorschreiben. Das beinhaltet dann manchmal auch Klassen-, Attribut-, Methoden- und Variablennamen. Insbesonders dann, wenn von einem Geschäftsprozess aus eine Software entwickelt wird und durchgängig von der Fachabteilung verstanden werden soll.

    Dann läuft in dieser Firma grunsätzlich etwas schief...

    Ich denke dir fehlt etwas die Erfahrung bzw. der Blick über den Tellerrand.

    Fast jede Firma braucht Software, nicht nur Softwarefirmen. Und ab einer bestimmten Grösse ist da quasi immer "eigene" Software dabei, sei's jetzt von hausinternen Programmierern entwickelt oder von externen Firmen. Und in vielen Firmen, speziell nicht-IT Firmen, gibt es halt auch genug Leute die nicht oder nicht gut Englisch können. Oft auch Abteilungsleiter/Projektleiter/Key User etc. Wenn die dann die Doku nicht verstehen können, weil sie in Englisch ist, dann hast du ein Problem.

    Das heisst nicht automatisch dass die Software unbedingt in der Landessprache geschrieben sein muss. Aber es kann durchaus die bessere Lösung sein. Denn das Gemisch zwischen dem Englisch der Programmiersprache/Standardlibrary und der Landessprache in der Doku hast du dann sowieso, notwendigerweise. Die Frage ist dann nur wo man am besten die Grenze zieht. Und darauf gibt es keine klare, allgemeingültige Antwort.


  • Mod

    @hustbaer sagte in Clean Code / Software Principles - Wo seid ihr??:

    Fast jede Firma braucht Software, nicht nur Softwarefirmen. Und ab einer bestimmten Grösse ist da quasi immer "eigene" Software dabei, sei's jetzt von hausinternen Programmierern entwickelt oder von externen Firmen. Und in vielen Firmen, speziell nicht-IT Firmen, gibt es halt auch genug Leute die nicht oder nicht gut Englisch können. Oft auch Abteilungsleiter/Projektleiter/Key User etc. Wenn die dann die Doku nicht verstehen können, weil sie in Englisch ist, dann hast du ein Problem.

    Ojeh, wir sind also in einer Firma, die groß genug ist, um ihre eigene Technik zu machen, aber die Programmierer und/oder Manager sind weder in der Lage, den neuesten Stand der Technik zu verfolgen, noch international zu kooperieren. Da ist die Einschätzung, dass in der Firma etwas grundsätzlich schief läuft, schon ganz angebracht. Programmierer die nur Deutsch können, kannst du vielleicht vor 30 Jahren rechtfertigen, wo die Welt noch nicht so groß und verknüpft war, und man mit einer einfachen Ausbildung schon als Fachexperte zählen konnte. Heute heißt das, dass so jemand nur Jürgen Wolf lesen kann, anstatt Stackoverflow, und alle Entwicklungen der letzten 5-15 Jahre sind auch unzugänglich. Ich bin sicher, für Management gilt ähnliches.

    Ich arbeite bei einer Firma, bei der tatsächlich auch deutsche Technikdokumentation herumgeistert (eben jene, die in den 1980ern geschrieben wurde), mit dem Resultat, dass man heute den Zusatzaufwand hineinstecken muss um ausländische Fachkräfte einzuführen. Das schlimsmte ist, das man da in den 1980ern denselben Aufwand umgekehrt betrieben hat, den das sind alles selbstausgedachte Übersetzungen (auch damals schon wurde alle neue Technik international auf Englisch dokumentiert…) und die interne Übersetzung, die man sich damals ausgedacht hat, ist quasi die Definition wie diese Begriffe auf Deutsch lauten. Von daher kann man auch niemanden anweisen, einfach eine Übersetzungsmaschine zu nutzen.

    Da ist es natürlich trotzdem vertretbar, weil man 1980 in der BRD nicht genug englischsprachige Ingenieure zu dem Thema finden konnte. Aber wenn du das heute noch machen musst, dann hat deine Firma ein Problem, ein großes.



  • @SeppJ sagte in Clean Code / Software Principles - Wo seid ihr??:

    Da ist es natürlich trotzdem vertretbar, weil man 1980 in der BRD nicht genug englischsprachige Ingenieure zu dem Thema finden konnte. Aber wenn du das heute noch machen musst, dann hat deine Firma ein Problem, ein großes.

    Wer sich bei überwiegend deutschsprachigen Mitarbeitern für eine englischsprachige Dokumentation entscheidet, wenn es dafür keine externen Gründe gibt, der entscheidet sich für eine schlechtere Dokumentation! Oder willst Du behaupten, Du wärst in der Lage Dich mit gleicher Qualität auf Englisch auszudrücken wie auf Deutsch? Es ist und bleibt eine Fremdsprache, und man erreicht niemals die gleiche Sprachkompetenz in einer Fremdsprache wie in der eigenen Muttersprache.



  • @SeppJ
    Vorweg: ich arbeite nicht in einer solchen Firma.

    Aber ich kenne ein paar Leute die das tun. Klar kann man da dann sagen "oh je, da läuft ja einiges falsch". Nur ändert das nix. Es ist halt einfach so. Und ein IT Leiter der strikt der Meinung ist "wir müssen jetzt alles Englisch" wird die Situation der Firma vermutlich nicht signifikant verbessern.

    in einer Firma, die groß genug ist, um ihre eigene Technik zu machen

    Nur damit wir uns nicht falsch verstehen: ich meinte da z.B. auch Firmen die sowas wie SAP oder Dynamics AX verwenden und da eigene Anpassungen/Erweiterungen drin/dran haben. Dazu muss die Firma nicht besonders gross sein. Je nach Branche reicht da ein Betrieb mit ein paar hundert Mitarbeitern.



  • @SeppJ sagte in Clean Code / Software Principles - Wo seid ihr??:

    Ojeh, wir sind also in einer Firma, die groß genug ist, um ihre eigene Technik zu machen, aber die Programmierer und/oder Manager sind weder in der Lage, den neuesten Stand der Technik zu verfolgen, noch international zu kooperieren. Da ist die Einschätzung, dass in der Firma etwas grundsätzlich schief läuft, schon ganz angebracht. Programmierer die nur Deutsch können, kannst du vielleicht vor 30 Jahren rechtfertigen, wo die Welt noch nicht so groß und verknüpft war, und man mit einer einfachen Ausbildung schon als Fachexperte zählen konnte. Heute heißt das, dass so jemand nur Jürgen Wolf lesen kann, anstatt Stackoverflow, und alle Entwicklungen der letzten 5-15 Jahre sind auch unzugänglich. Ich bin sicher, für Management gilt ähnliches.

    Nehmen wir mal an, eine Behörde will eigene Geschäftsprozesse digitalisieren. Die Geschäftsprozessbeteiligten (aus mehreren Ländern mit verschiedenen 1. und ggf. 2. Sprachen) sprechen einheitlich die Sprache der Behörde (in D wäre das deutsch, setzen die Behörden jedenfalls voraus).
    Die Geschäftsprozesse werden in der Behördensprache beschrieben, damit die Prozessbeteiligten diese verstehen können.
    Aus den Geschäftsprozessen werden z.B. UML-Aktivitätsdiagramme. Damit diese mit den zugrundeliegenden Geschäftsprozessen verglichen werden können, werden alle darin vorkommenden Artefakte wie z.B. Aktivitäten (ggf. Methoden von Klassen) auch in der Behördensprache abgefasst.
    Der Entwickler nutzt jetzt die für die "sichtbaren" Artefakte (Klassen, Methoden etc.) auch die Behördensprache. Kann natürlich jegliche anders sprachlichen Dinge z.B. aus Bibliotheken nutzen.
    Ich habe auch schon gesehen, dass auf eine englischsprachige API eine deutsche "draufgelegt" wurde.
    Wenn die Behörde ein Qualitätsmanagement betreibt, wird ein behördensprachlich sattelfester Mensch die Doku prüfen und ggf. sprachlich glattziehen.

    PS. Ich kann heutzutage alles aus dem Internet in fast jeder Sprache lesen! Translater und gesunde Interpretation.



  • @Helmut-Jakoby sagte in Clean Code / Software Principles - Wo seid ihr??:

    Ich kann heutzutage alles aus dem Internet in fast jeder Sprache lesen!

    Du glücklicher! Ich bleibe öfters mal an TLA's (z.B. MO, RCA, TBD,...) oder English von Indern, Japanern und manchmal von Schweizern hängen.


  • Mod

    @john-0 sagte in Clean Code / Software Principles - Wo seid ihr??:

    @SeppJ sagte in Clean Code / Software Principles - Wo seid ihr??:

    Da ist es natürlich trotzdem vertretbar, weil man 1980 in der BRD nicht genug englischsprachige Ingenieure zu dem Thema finden konnte. Aber wenn du das heute noch machen musst, dann hat deine Firma ein Problem, ein großes.

    Wer sich bei überwiegend deutschsprachigen Mitarbeitern für eine englischsprachige Dokumentation entscheidet, wenn es dafür keine externen Gründe gibt, der entscheidet sich für eine schlechtere Dokumentation! Oder willst Du behaupten, Du wärst in der Lage Dich mit gleicher Qualität auf Englisch auszudrücken wie auf Deutsch? Es ist und bleibt eine Fremdsprache, und man erreicht niemals die gleiche Sprachkompetenz in einer Fremdsprache wie in der eigenen Muttersprache.

    1. Ja, ich kann das. Dokumentation ist keine Poesie. Ich muss keine Ballade schreiben, die den Leser zu Tränen rührt. Wobei ich durchaus einsehe, dass ich das besser kann als andere.
    2. Das ist keine Ausrede. Der Nachteil, sich in einer Nischensprache festgefahren zu haben, ist zu gravierend.

    @hustbaer sagte in Clean Code / Software Principles - Wo seid ihr??:

    Aber ich kenne ein paar Leute die das tun. Klar kann man da dann sagen "oh je, da läuft ja einiges falsch". Nur ändert das nix. Es ist halt einfach so. Und ein IT Leiter der strikt der Meinung ist "wir müssen jetzt alles Englisch" wird die Situation der Firma vermutlich nicht signifikant verbessern.

    Dass das so gelebt wird, bestreitet wohl niemand. Aber dass das ein Zeichen dafür ist, dass in der Firma krass etwas schief läuft, doch bestreitest du doch wohl auch nicht? Eine Firma deren Experten kein Englisch sprechen, ist wie ein Restaurantkoch, der nur Sachen aus dem eigenen Garten benutzt. Er mag noch so talentiert sein, das Ergebnis wird nicht mithalten können mit der Konkurrenz, die sich aus aller Welt bedienen kann.

    @Helmut-Jakoby sagte in Clean Code / Software Principles - Wo seid ihr??:

    Der Entwickler nutzt jetzt die für die "sichtbaren" Artefakte (Klassen, Methoden etc.) auch die Behördensprache. Kann natürlich jegliche anders sprachlichen Dinge z.B. aus Bibliotheken nutzen.
    Ich habe auch schon gesehen, dass auf eine englischsprachige API eine deutsche "draufgelegt" wurde.
    Wenn die Behörde ein Qualitätsmanagement betreibt, wird ein behördensprachlich sattelfester Mensch die Doku prüfen und ggf. sprachlich glattziehen.

    Sind Behörden-IT-Projekte nicht berühmt für ihre überbordenden Kosten und ihr regelmäßiges Scheitern?



  • @SeppJ sagte in Clean Code / Software Principles - Wo seid ihr??:

    Sind Behörden-IT-Projekte nicht berühmt für ihre überbordenden Kosten und ihr regelmäßiges Scheitern?

    Für das Scheitern sind in der Regel die hoch kompetenten "Beratungsfirmen" verantwortlich. Teils auch, weil diese einfachste Probleme hochkomplex lösen wollen (könnte ja sonst der Kunde selbst ;-).



  • @hustbaer sagte in Clean Code / Software Principles - Wo seid ihr??:

    Ich denke dir fehlt etwas die Erfahrung bzw. der Blick über den Tellerrand.

    Genau deswegen habe ich hier diesen Thread eroeffnet. Mir geht es darum, ein guter Architect fuer meine Kollegen zu sein - und nicht nur einer der Vorschreibt was zu tun ist und wie dieses zu tun ist.

    Dass es Ausnahmen der Regeln gibt, gerade bei einem Mittelstaendler (der mal ein Familienbetrieb war), ist klar - und dass es Branchen-Spezifische Fachwoerter gibt, die auf Englisch keiner mehr versteht - ja, auch moeglich.

    Jedoch wollen gerade WIR zu einem "Global Player" werden, der wir aber noch lange nicht sind. Darum muss man einige Dinge eventuell Dogmatisch sehen.



  • @SeppJ sagte in Clean Code / Software Principles - Wo seid ihr??:

    1. Das ist keine Ausrede. Der Nachteil, sich in einer Nischensprache festgefahren zu haben, ist zu gravierend.

    Die Nischensprache Englisch ist gemeint? Die meiste IT-Dokumentation wird mittlerweile in chinesisch geschrieben, und das wird in Zukunft noch viel häufiger der Fall sein. In den USA wächst der Anteil der Spanischsprechenden immer mehr, so dass die Bedeutung des Englischen auch dort geringer werden wird. Deutsch ist die zweithäufigste Muttersprache in Europa (nach Russisch).

    Ernsthaft formuliert, was für einen Sinn hat es in Pidgin-English Dokumentationen zu verfassen? Vielen ist gar nicht bewusst, wie schlecht sie Englisch sprechen und schreiben, und das führt dann zu Problemen, weil bestimmte Dinge nicht gut formuliert sind und zu Missverständnissen führen.


  • Mod

    Lol wut? Zeig mir mal die Doku von Redwood.js, die Specs von DOCSIS 4, oder die Referenz von Tensoflow auf Chinesisch oder Deutsch.

    Ernsthaft formuliert, was für einen Sinn hat es in Pidgin-English Dokumentationen zu verfassen? Vielen ist gar nicht bewusst, wie schlecht sie Englisch sprachen und schreiben, und das führt dann zu Problemen, weil bestimmte Dinge nicht gut formuliert sind und zu Missverständnissen führen.

    Das Problem der Firma ist ein anderes, nämlich dass sie Techniker im Dienst haben, die nicht ausreichend Englisch sprechen, als dass man sie auf dem internationalen Markt ernst nehmen kann. Dann wird die Webseite eben mit reinem Javascript nach Jürgen Wolf geschrieben; das Verteilernetz wird nach Anleitung der Bundespost betrieben; und die Daten nur mit Methode kleinster Quadrate nach Gauss interpretiert. Das kannst du dir nur erlauben, wenn du aufgrund geografischer Faktoren keine Konkurrenz hast, und keine Ambitionen, jemals größer zu werden.

    Ich hätte jetzt den Bäcker von der Ecke als Beispiel für einen Betrieb ohne internationale Konkurrenz gebracht, aber dann fiel mir ein, dass mittlerweile nahezu alle Bäckereien entweder direkt (übernommen) oder indirekt (durch Kauf fertiger Backmischungen) von großen Ketten abhängen. Und diese Großen sprechen bestimmt nicht Deutsch bei internen IT-Prozessen. Da liegt dann die wahre Lehre drin.



  • @john-0 sagte in Clean Code / Software Principles - Wo seid ihr??:

    Vielen ist gar nicht bewusst, wie schlecht sie Englisch sprachen und schreiben, un

    Oh ja, ich kann da nicht anders, als auf das Buch The devil lies in the detail zu verweisen. 😉

    Und schlimmer, wir nutzen doch in unserem täglichen Sprachgebrauch viele englische anmutende Begriffe. Da kann doch der Wechsel zum Englischen nicht schwer sein! Das ist doch half the rent. 😉

    SCNR



  • @SeppJ sagte in Clean Code / Software Principles - Wo seid ihr??:

    Lol wut? Zeig mir mal die Doku von Redwood.js, die Specs von DOCSIS 4, oder die Referenz von Tensoflow auf Chinesisch oder Deutsch.

    Ach, Projekte die us-amerikanisch (Redwood.js, TensorFlow) oder international (DOCSIS) sind (da sind wir wieder am Punkt externe Gründe), haben keine Doku auf Chinesisch oder Deutsch? Natürlich ist diese auf Englisch verfasst. Nur warum soll man für eine deutsche Steuersoftware, eine Arztpraxen Abrechnungssoftware, eine Rechtsanwaltssoftware, … die Dokumentation auf Englisch verfassen? Keine dieser Softwarepakete wird außerhalb von Deutschland (auch nicht in Österreich und der Schweiz) benutzt werden, weil die rechtlichen Voraussetzungen nicht gegeben sind. Fakt ist, China entwickelt in immer schnelleren Zyklen eigene Software, die natürlich nur in der Landessprache dokumentiert wird. Bei einem Markt von >1 Milliarde Menschen ist das auch kein großes Problem. Wir sehen doch schon, dass Firmen wie Huawei in die westlichen Märkte drängen.

    Was das Thema Techniker betrifft: Früher gab es in Deutschland gut ausgebildete Handwerker und Techniker, aber weil wir da ein erhebliches Nachwuchsproblem haben leidet mittlerweile die Qualität. In den USA oder UK gab es niemals eine vergleichbare Ausbildung mit den daraus resultierenden Qualitätsproblemen bei Technikern/Handwerkern. Sprachkenntnisse deutscher Techniker waren früher das kleinste Problem.


  • Mod

    @john-0 sagte in Clean Code / Software Principles - Wo seid ihr??:

    Nur warum soll man für eine deutsche Steuersoftware, eine Arztpraxen Abrechnungssoftware, eine Rechtsanwaltssoftware, … die Dokumentation auf Englisch verfassen?

    Damit du nicht für den gesamten Lebenszyklus der Software (von der Planung bis zum Endbetrieb) ausschließlich auf deutsche Arbeitskräfte angewiesen bist?



  • Schon interessant dieser Thread, es dreht sich doch viel um die Sprache und das dazu passende Tastaturlayout.

    Frageschwerpunkt von @tbird war nicht nur "lingua franca", sondern auch "Clean Code, SOLID, allg. Software Principles" um langlebigen, verständlichen, wartbaren Source-Code zu erstellen. Und eigentlich geht es doch bei Letzterem um so etwas wie Vorgehensmodelle zur Softwareentwicklung und nicht nur ums "coden" (Außer man versteht unter Softwareentwicklung nur "coden" und nicht eine umfangreiche Ingenieurleistung).

    Ist das nicht viel ausschlaggebender für ein erfolgreiches Softwareprojekt?



  • @john-0 sagte in Clean Code / Software Principles - Wo seid ihr??:

    Früher gab es in Deutschland gut ausgebildete Handwerker und Techniker, aber weil wir da ein erhebliches Nachwuchsproblem haben leidet mittlerweile die Qualität.

    Uff, und ich erlebe recht heftige Probleme mit Outsourcing aus Indien, China, USA und Thailand. Und es betrifft Software, Hardware, Verpackung und Packaging.

    Ich kann es hier nicht beschreiben, man muss es selbst erlebt haben. Einen regelmäßige Kontrolle des Blutdrucks vorrausgesetzt.


Anmelden zum Antworten