Impressum


Aufmerksamkeit
Objektorientierung
der direkte Weg

 

Softwareentwicklung

Auswahl: Softwareentwicklung   |   148 Ideen   |   Seiten:  <<  <  5  6  7  8  9  10  11  12  13  14  >  >> 
 
23.03.2007 17:49
Softwareprogramme erneuern sich genauso wie die Zellen eines Körpers. Deshalb können Prinzipien und Architekturgedanken fließend eingebracht werden.
Analogie Architektur Software Softwarearchitektur Softwareentwicklung
 
18.10.2006 21:40
Man starte mit den einfachsten Standard-Tools und betrachte diese als Ausgangspunkt für die Entwicklung einer immer passenderen und mächtigeren Entwicklungsumgebung, die sich im Kontext einer konkreten Projektumgebung individuell entwickelt.
Entwicklungsumgebung Softwareentwicklung
 
17.10.2006 15:28
Die permanente und allgemeine Beschäftigung mit dem Thema "Unsicherheit" läßt das Thema tatsächlich wachsen (Die Macht des Geistes).
Sicherheit Software Softwareentwicklung
 
17.10.2006 15:28
Das ganze Sicherheitsthema hat einen Beigeschmack von Ohnmacht. Als wäre man völlig willkürlich Gefahren ausgesetzt, die von den Inhalten des Geistes und den Themen, mit denen man individuell beschäftigt ist, gänzlich unabhängig existieren.
Sicherheit Software Softwareentwicklung
 
Voll sprechende Bezeichner als ein Weg zu echter Codeverständlichkeit26.09.2006 11:46
Codeverständlichkeit bezieht sich hier darauf, daß ein Entwickler selbst mit dem eigenen Code klarkommt. Man tue es nur für sich aus einem inneren Bedürfnis heraus und nur so viel man will und nur auf die Weise, die einem Freude macht. Insofern haben alle folgenden Punkte nur den Charakter von informativen Vorschlägen.
  • deutsch; Klarheit wird selbstverständlich am leichtesten in der Muttersprache erreicht. Und wie wahrscheinlich ist es, daß ein nicht deutsch sprechender Softwareentwickler Änderungen in einem in Deutschland geschriebenen Codestück vornehmen muß? Sehr unwahrscheinlich! Aber tausende deutscher Softwareentwickler quälen sich mit englischen Bezeichnern ab. Es ist in Ordnung, daß wir in Deutschland noch deutsch sprechen. Es braucht niemand - auch im Business nicht - ein schlechtes Gewissen deswegen zu haben.
  • englisch-deutscher Mischmasch ist natürlich auch kein Problem, denn "nur-deutsch" oder "nur-englisch" wären formale Anforderungen und hier geht es ja um Verständlichkeit anstelle von Formalismus.
  • von unverständlichen Kürzeln freihalten; Insbesondere Codierungsrichtlinien und formale Anforderungen führen zu technischen, inhaltlich bedeutungslosen Kürzeln. Die Grundlänge eines Bezeichners kann dann schon so lang sein, daß man sich kaum noch traut, etwas sprechendes anzuhängen
  • voll sprechend ausgeschrieben und ruhig auch witzig, individuell und originell. Das Handling von langen Bezeichnern kann man durch Nutzung der Kopierfunktion des Editors optimieren. Aber das ist Sache individuellen Programmierstils.
  • Lesbarkeit erhöhen durch Visualisierung von Wortgrenzen mit Unterstrich oder erster Buchstabe eines Wortes groß
Bezeichner Codeverständlichkeit Programmieren Softwareentwicklung
 
Das Prinzip der einfachen Lösung24.09.2006 21:23
Es gibt immer eine wirklich einfache Lösung. komplexe Standards und Schnittstellen einfach übergehen und weitersuchen.
Einfachheit Lösungen Softwareentwicklung
 
16.09.2006 02:46
Es dürfte bei den meisten Projekten normal sein, daß die ersten Implementierungen schnell an strukturelle Grenzen stoßen, an denen ein kompletter Neuanfang dringend anzuraten ist. Diese Grenzen sind erreicht, wenn alles immer komplexer und Erweiterungen immer mühsamer werden, wenn man immer weniger durchsieht in dem Ganzen und eigentlich weiß, daß andere Strukturen viel besser gewesen werden.

Nur Mut! Alles wegschmeißen und vollkommen neu implementieren!

Diese Neuentwicklung braucht nur einen Bruchteil des Aufwandes der vorhergehenden Implementierung (das gilt auch fürs 3. und 4. Neuschreiben) und das Resultat ist um so viele Dimensionen besser, daß es eine regelrechte Erlösung ist, das alte Ding los zu sein.
Aufräumen Entwicklungsprozess Programmieren Softwareentwicklung
 
16.09.2006 02:35
Was im klassischen Wasserfall-Modell als eine Abfolge von aufeinanderfolgenden zeitlich-abgegrenzten Phasen erscheint (Analyse, Design, Implementierung, Test, Inbetriebnahme), stelle man sich besser als eine Unterscheidung verschiedener Tätigkeiten vor, die allesamt über den gesamten Entwicklungsprozeß hinweg ablaufen.
Entwicklungsprozess Softwareentwicklung
 
Spaßkiller: Was mir persönlich Freude und Energie raubt16.09.2006 00:26
  • Pflichtenhefte schreiben oder lesen, Anforderungen exakt definieren müssen.
  • Spezifikation und Dokumentation schreiben oder lesen
  • Kommentare im Code, die ich nicht aus einem innerem Bedürfnis heraus für mich selbst einfüge, sondern für imaginäre andere oder für die "Codeverständlichkeit" oder für das Einhalten imaginärer Standards für "sauberes Programmieren"
  • Typen deklarieren, die sich aus dem Kontext ergeben, Typumwandlungen hinschreiben, die sich aus dem Kontext ergeben. (Tun sie das nicht fast immer?)
  • Fehlerzweige
  • Umständliche Anweisungen / Zugriffe / Lösungen aus Sicherheitsgründen, die eigentlich viel einfacher gehen
  • Objekt-Orientierung
  • Testlisten schreiben, lesen oder abarbeiten
  • Codierungsrichtlinien
  • komplexe Entwicklungstools
Energie Freude Objektorientierung Programmieren Programmiersprachen Softwareentwicklung Spaßkiller
 
Das Wesen des natürlichen Wachstumsprozesses15.09.2006 13:02
Konzentration der Aufmerksamkeit auf das, WAS entwickelt werden soll, während das WIE in dem daraus entstehenden Prozeß die volle Freiheit erhält, sich auf irgendeine Weise auszuformen.

Indem man konsequent versucht, sein Ziel auf dem schnellsten und einfachsten Weg zu erreichen, wird man in jedem Moment wissen, was unmittelbar zu tun ist.

Der Witz dabei ist der, sich nicht davon Angst machen zu lassen, daß man den Prozeß und die Strukturen - also das "Wie" - nicht komplett oder auch nicht einmal ansatzweise vorhersehen kann. Diese Angst führt nämlich zu der Versuchung, doch wieder alles starr vorzugeben und vorwegzunehmen und dabei das natürlich gewachsene, optimale "Wie" zu verpassen.

Anstatt Strukturen vorzugeben, versucht man sie in einer Anfangs vielleicht chaotischen Entwicklung zu erkennen und konsolidiert und verstärkt sie dann.

Man kann Strukturen auch zunächst vorgeben, um überhaupt einen Anfang zu finden und dann aufgeben oder sich verändern lassen, wenn bessere Strukturen auftauchen.
Anforderungen Architektur Aufmerksamkeit der direkte Weg Lösungen natürliches Wachstum Software Softwarearchitektur Softwareentwicklung Strukturen
 
 




 
Impressum © 2009-2011 Alle Rechte vorbehalten