Ich fing anfänglich mit einem kleinen Projekt an und bearbeitete php-Dateien und so in Notepad ++. Früher war es einfach, an ein Feature zu denken und es als separate Datei in das Projekt einzufügen. Als das Projekt größer wurde, begann meine Produktivität zu sinken, weil ich mich nicht mehr an all die Funktionen erinnern konnte, die ich gemacht habe und wo sie gespeichert wurden usw. Dann fügte ich eine IDE (PhpEd) und SVN hinzu und bemerkte dann a große Steigerung der Produktivität.
Ich merke, dass ich wieder an Produktivität einbüße (weil alles wieder zu komplex wird). Das Projekt ist von ungefähr 20 Dateien ausgegangen - & gt; 100 Dateien, und es wird schwierig, alles in meinem Kopf zu verwalten (sogar mit einer IDE). Ich frage mich, ob die Leute Tipps haben, was ich tun kann, um die Produktivität wieder zu steigern. (Was ist die nächste Ebene? Wenn es eine gibt?)
Irgendwelche Softwaretools oder Tipps, wie man Programmdesign angehen kann / Dinge einfacher zu visualisieren, zumindest?
Ich weiß, dass es keine Wunderwaffe gibt, aber jede Idee wäre hilfreich.
Zum Beispiel benutzt ihr bestimmte Tools, um neben einer IDE / SVN den Tag zu überstehen. Schreiben Sie Code auch auf eine bestimmte Art und Weise, so wird dies in Zukunft kein Problem sein? (Einzelheiten bitte).
Die kalte, harte Tatsache ist, dass die Effizienz der Entwickler mit der Projektgröße sinkt. Dies ist seit Jahrzehnten bekannt. Es gibt Methoden zu helfen, aber sie erfordern etwas Disziplin.
Die beste Lösung ist, auf eine höhere Abstraktionsebene zu gehen. Schreibe Routinen, die als Bausteine dienen, die du verwenden kannst, als wären sie Standardbibliotheken oder Sprachkonstrukte. Dokumentieren Sie ihre Schnittstellen und programmieren Sie nur die Schnittstellen. Wenn Sie das Gefühl haben, dass Sie wissen müssen, wie eine Routine, an der Sie nicht arbeiten, implementiert wird, verwenden Sie sie entweder falsch oder haben die Schnittstelle nicht ausreichend dokumentiert. Seien Sie langsam, um eine Schnittstelle hinzuzufügen, langsamer, um etwas zu löschen, und denken Sie daran, dass das Ändern von Elementen davon Sie stark verletzen kann.
Die Lokalität ist dein Freund. Je mehr Sie sich auf ein kleines Gebiet konzentrieren können, desto besser sind Sie. Die Programmierung an Schnittstellen hilft dabei. Das Zusammenhalten von Routinen hilft dabei, so dass die Routinen immer nur eine Sache machen.
Die Objektorientierung ist sehr nützlich, da sie die beiden obigen Elemente unterstützt. Es fördert die Kapselung und Codierung für eine Schnittstelle und gruppiert verwandte Teile des Codes zusammen.
Testgetriebene Entwicklung ist wertvoll, um die Programmierung für eine Schnittstelle zu erzwingen. Schreiben Sie Tests basierend auf der Schnittstelle, nicht auf der Implementierung. Dies hat den schönen Nebeneffekt, dass die Testsuiten selbst die Schnittstelle definieren. Wenn es nicht getestet wird, zählen Sie nicht darauf. Stellen Sie sicher, dass Sie Testsuiten problemlos ausführen können und sich daran gewöhnen.
Refactoring wird notwendig sein. Planen Sie darauf, besonders wenn Sie etwas ändern. Sie benötigen sauberen Code. Darüber hinaus werden Sie unweigerlich feststellen, dass Sie die Funktionalität an die falsche Stelle gesetzt haben.
Denken Sie auch daran, dass nichts davon das Problem vollständig lösen wird. Große Softwareprojekte sind von Natur aus schwierig.
Zeichnen und / oder schreiben Sie es aus. Wenn Sie sagen, es ist alles in Ihrem Kopf, dann nehmen Sie sich etwas Zeit von der Codierung und dokumentieren Sie Ihre Arbeit. Dies kann Absätze enthalten, die erklären, warum Sie etwas getan haben.
Diagramme und andere visuelle Elemente helfen Ihnen auch dabei, es zu organisieren.
Ich habe festgestellt, dass einige Programmierer die nicht-technischen Faktoren in Projekten ignorieren. Dies gilt insbesondere für einzelne Entwickler, die nicht die Struktur einer Gruppe haben, um sie zu führen. Ihre Arbeit ist mehr als nur Code und Sie sollten alle Aspekte Ihres Prozesses betrachten.
Seien Sie nie stolz darauf, Code in einem Notizblock zu bearbeiten! IDE spart Zeit und steigert Ihre Effizienz. Wenn das Projekt groß wird, sollten Sie sich um das Projektmanagement kümmern und ein effizientes "Prozessmuster" wie RUP (Rational Unified Process), EUP oder OOSP einhalten. Ihr SVN ist Teil von SCM . Natürlich sind in einem Pattern weitaus mehr Aktivitäten definiert. Wie beim Dateiverwaltungsproblem können Sie sie in verschiedene Pakete aufteilen und sie an verschiedenen Stellen speichern. Wenn Sie keine Ahnung von "Software Engineering" haben, können Sie auf einige Bücher von Scott W Ambler oder andere über SE (Software Engineering) verweisen. Denken Sie daran, Software ist weit mehr als CODE!
Ein guter Entwickler weiß, dass Entwicklung mehr ist als Programmierung. Ein großer Entwickler weiß, dass Entwicklung mehr ist als Entwicklung. Von Scott W Ambler
Test Driven Development könnte für Sie nützlich sein.
Erstellen Sie zuerst Ihre Tests und schreiben Sie dann den Code, um diese Tests zu bestehen.
Wenn Sie einen Code hinzufügen / ändern, haben Sie eine Regressionstest-Suite, die Sie ausführen können, um sicherzustellen, dass Sie nichts kaputt gemacht haben. Dies spart meiner Erfahrung nach viel Zeit, insbesondere wenn die Komplexität und Größe einer Anwendung zunimmt.
Bei großen Codebasen geht es bei der Produktivität weniger um Tools als vielmehr um den Code, den Sie schreiben. Verbringen Sie Zeit, um die Qualität Ihres neuen und vorhandenen Codes zu verbessern. Ja, es verlangsamt Sie kurzfristig, aber es erlaubt Ihnen, Ihr Tempo mit der Zeit zu halten.
Dies gilt unabhängig von Ihren Tools oder Ihrer Sprache. Die besten Werkzeuge der Welt werden niemandem helfen, der ein Durcheinander macht. Zunächst möchte ich einige einfache Ideen beachten:
Für viel detailliertere Informationen darüber, wie man großartigen Code gestaltet, schlage ich vor, hier zu stöbern.
>Ich habe früher an einem Projekt gearbeitet, das ungefähr eine Million Zeilen Code (C #, C ++) enthielt und es wächst immer noch.
1) Um eine solche Codebasis zu verwalten, wurde die Ordnerstruktur des SVN-Archivs so angelegt, dass sie verschiedene Architekturen unseres Produkts nachahmt. Auf diese Weise wurde es einfacher, den Weg durch das Archiv zu finden.
2) Außerdem hatten wir unser eigenes Tool für die benutzerdefinierte Erstellung. Wenn Sie eine große Codebasis haben, ist es möglicherweise nicht möglich, jederzeit alles zu erstellen, um ein kleines Feature zu testen. Unser benutzerdefiniertes Build-Tool hatte viele Optionen, die das Archiv in jeder Granularität aufbauen konnten.
3) Normalerweise habe ich beobachtet, dass wenn Sie die generische Funktionalität / Helfer richtig nutzen, das Erstellen neuer Dinge obendrein einfacher wird und auch das Aufblähen von Code vermeidet.
4) Richte ein Wiki ein, wenn mehr Entwickler an deinem Projekt arbeiten. Wiki-Dokumentation ist mühelos, suchbar und hilfreich, wenn es richtig gemacht wird.
Das ist alles woran ich gerade denken kann. Hoffe das hilft
Was ist mit diesem Mythos, der um OOP schwebt, um den Tag zu retten? Wenn das wahr ist, warum drängen die Linux / Kernel-Leute immer noch neue Versionen auf eine wöchentliche Basis? Mit anderen Worten: Sind alle ASM / C-Programmierer zur "Hello World" -Komplexität verurteilt?
Ich bin mir nicht sicher, wonach genau Sie fragen. Ich meine Arbeit an den Problemen vor und wenn sie auftreten:
Wenn Sie viele Dateien und LOCs haben, reduzieren und reorganisieren Sie sie. Zum Beispiel durch den Aufbau oder die Verwendung von Rock-Solid-Frameworks für bestimmte Aufgaben (PDO statt mysql ()). Mit anderen Worten, wiederhole dich nicht. Kurze, einprägsame, ähnliche Funktionsnamen: get_user_ID (), get_task_ID (), db_query () ....
Ist Kommunikation in der Gruppe ein Problem? Probieren Sie Wikis aus, versuchen Sie es mit internen IMs, versuchen Sie es mit weiteren Kommentaren, fragen Sie die Gruppe, was sie nicht mögen und wollen verbessert werden. Es hängt völlig vom Projekt ab.
Wenn Sie in einer Gruppe arbeiten, seien Sie nicht überall. Arbeite an deinen Teilen und verbessere sie. Das spart Zeit, die Sie in die Denkweise anderer Programmierer investieren müssen. Eine Änderung nach der anderen. Öffne keine 200 Dateien und bearbeite völlig andere Dinge.
Automatisieren und beschleunigen Sie alles, wenn möglich: Bereitstellung, Versionierung, Dokumentation, Tests.
Große Projekte sind große Projekte und diese sind immer schwer zu verstehen. KISS ist gut, aber nach meiner Erfahrung hilft es manchmal, das Ding auf selbständig funktionierende Komponenten zu zerlegen, die über XML, sprachspezifische Schnittstellen usw. kommunizieren. Kurz gesagt: Mache viele kleine Projekte aus der großen heraus.
>Ich behalte eine persönliche Todo / Erinnerungsliste als "myname.todo.txt".
Schnelle Bereitstellung ist Pflicht! Installieren Sie zum Beispiel eine lokale Lampe / XAMPP und sehen Sie sich Ihre Änderungen direkt an.
Mein erster Gedanke ist, dass du Sachen schreiben musst. Dein Kommentar über "es ist alles in meinem Kopf" macht mir Sorgen, dass
Ich finde ein Wiki, selbst wenn ich der einzige Benutzer bin, ist phänomenal hilfreich bei der Organisation meiner Gedanken. Der Bearbeitungsprozess ist einfach und schnell, was es mir ermöglicht, den Inhalt meines Gehirns buchstäblich in ein durchsuchbares, digitales Medium zu übertragen.
Es spielt keine Rolle, welches Wiki du wählst, nimm dir etwas Zeit, um die Syntax wirklich zu lernen, damit du nicht ständig auf die Formatierung achtest.
Dann setzen Sie sich einfach hin und dump .
Sobald Sie etwas auf der Seite haben, können Sie anfangen, Ihre Gedanken zu reorganisieren, und es ist einfacher, die gesamte Systemarchitektur von einer hohen Ebene aus zu sehen, wenn sie direkt vor Ihnen steht.
Ich habe auch viele clevere und interessante Wege gefunden, meine Architektur zu reparieren, indem ich alles in einem völlig anderen Medium vor mir habe.
Wie Steve McConnel sagt, besteht die größte Herausforderung bei der Programmierung in der Verwaltung der Komplexität.
Sie haben mehrere Möglichkeiten, es zu verwalten:
Meiner Meinung nach sind die ersten beiden Punkte (Werkzeuge und Techniken) zwar gut, aber nicht wirklich etwas. Zum Beispiel habe ich Kollegen in meinem Team, die alte Editoren verwenden, und sind fast so produktiv wie Kollegen, die Eclipse verwenden.
Die anderen beiden Punkte hingegen helfen viel mehr: Disziplin, gutes Design und Refactoring helfen, die Komplexität so gering wie möglich zu halten, und gute Teamarbeit ermöglicht es, größere Projekte in Angriff zu nehmen, die alleine schon zu komplex wären.
Ich denke, du solltest Brooks 'klassisches Buch The Mythical Man-Month, Jubiläumsedition lesen. Obwohl das Originalbuch Arbeiten von Mitte der 60er Jahre beschreibt, sind die zugrunde liegenden Wahrheiten immer noch korrekt. Und die spätere Arbeit zu ' No Silver Bullet (die in der Jubiläumsausgabe enthalten ist) ist sehr aufschlussreich.
>Kurz gesagt, erklärt das Buch, dass Programme, die größer werden, schwieriger zu verwalten (verstehen, pflegen, entwickeln), weil es mehr Dinge zu beachten gibt. Fast alle Designtechniken und Programmiertechniken werden verwendet, um diese Probleme zu begrenzen, aber die Probleme existieren, wenn die Software größer wird (das ist der "wesentliche" Teil des Untertitels von "No Silver Bullet").
Gewöhnen Sie sich regelmäßig Ihren Code an und suchen Sie nach Möglichkeiten, Wiederholungen zu eliminieren (dh wenden Sie das Prinzip "Do not Repeat Yourself" oder "DRY" an) und lassen Sie diese Wiederholung rücksichtslos umgestalten. Je mehr gängige Code-Snippets in wiederverwendbare Methoden und Klassen gepusht werden, desto einfacher ist es, neuen Code zu schreiben und desto mehr Hebelwirkung haben Sie für das Problem.
Mit einer guten IDE können Sie Gemeinsamkeiten finden und Refactorings anwenden.
Achten Sie auch auf Open Source-Frameworks und -Tools, die Aspekte Ihrer Software automatisieren. Ihre Verwendung ist eine massive Anwendung des DRY-Prinzips.
Sicher, verwenden Sie zuerst oo Programmierung und Vererbung. Als nächstes würde ich Framework wie Code-Zünder für den Start, fügen Sie ein Modul für das Layout (damit Sie konsistente Website-Layout haben) und vielleicht ein paar andere, Point ist nicht zu viel Zeit auf gemeinsame Dinge verbringen. Leider sind Migrationen für CI nicht großartig, aber sie existieren, also wäre etwas in dieser Richtung nützlich, um mit db umzugehen. Mit diesen können Sie Ihre Produktivität wieder haben, da Sie keine Zeit mit kleinen Dingen verbringen werden.
Bei größeren Projekten ist es so, dass sie mehrere Aspekte haben und je mehr diese vorhanden sind, desto mehr Zeit benötigen Sie, um sie zu berücksichtigen.
Hoffe, das hilft.
Die Verwendung eines PHP MVC-Frameworks würde die Menge an Code, die Sie verfolgen müssen, stark reduzieren. Es wird sich um viele der Dinge kümmern, die Sie wahrscheinlich selbst schreiben mussten, wie Sitzung, Datenbank-Ebene usw. Durch die Verwendung eines Frameworks wird es Ihnen helfen, Ihre Dateien logisch zu organisieren.
Ich habe festgestellt, dass Test-Driven Development (TDD) / verhaltensgesteuerte Entwicklung (BDD) mir hilft, die Dinge in Ordnung zu halten, wenn sie größer werden. Selbst wenn Sie nur Komponententests schreiben, die Funktions-, Integrations- und andere Tests auslassen, kann dies allein eine große Hilfe sein. Wenn sich deine Code-Basis in ein schwerfälliges, schwankendes Sumpfding des Schicksals verwandelt, werden deine Tests es in mehr oder weniger die richtige Richtung laufen lassen und verhindern, dass es über einen Felsen stolpert, mit dem Gesicht nach unten in den Schlamm fällt und ertrinkt, weil es auch ist schwer aufzustehen.
Wenn Sie genug Tests schreiben und sie gut durchdacht sind, können sie es so machen, dass Sie Änderungen vornehmen können und sofort wissen, ob die Änderung etwas kaputt gemacht hat. Ohne Tests können Sie nach einem gewissen Punkt nichts ändern.
Ich kenne die PHP-Szene nicht so gut, aber es scheint, dass es Test-Frameworks für PHP gibt, einschließlich einer PHPUnit .
Sie haben ein riesiges Projekt für PHP, meiner Meinung nach. Es kann getan werden, aber Sie müssen wirklich organisieren.
Zerlege es so weit wie möglich in unabhängige Stücke, jedes mit nur einer kleinen Schnittstelle.
"Fertig" so viel wie du kannst. Behandeln Sie dann diesen "fertigen" Code als API, damit Sie ihn nicht mehr ansehen müssen. Nehmen Sie an 4,5 Tagen in der Woche an, dass jemand anderes es geschrieben hat und dass Sie nur die Schnittstelle kennen.
Gehen Sie hier einen Schritt, aber brechen Sie das Projekt in kleineren Projekten / API / Module / Packages / Assemblies (nennen Sie sie, was immer Sie wollen) sollte der nächste logische Schritt hier sein.
Das menschliche Gehirn kann nur so viele Dinge gleichzeitig verarbeiten, es gibt nur so viel, was unser Arbeitsgedächtnis bewältigen kann. Wenn Sie kleinere Details hinter einer höheren Abstraktionsebene verbergen, können Sie diese Dateien vergessen, bis etwas unter der Haube verkehrt ist. Wenn das passiert, müssen Sie nur diese spezielle Haube öffnen, um sie dort zu reparieren. Verwenden Sie unterschiedliche Abstraktionsgrade und Ihre Projekte werden plötzlich viel kleiner, wo nur eine Handvoll Einheiten sinnvoll sind, während der Rest nur dafür sorgt, dass sie funktionieren. OOP ist sehr gut darin, Implementierungsdetails zu verbergen, während Funktionale auf höherer Ebene offen gelegt werden. Davon abgesehen gibt es andere Paradigmen als OOP, aus denen Sie wählen können.
Also mein Rat an Sie an diesem Punkt
Damit können Sie die Anzahl der Dinge, die Sie an Ihr Projekt erinnern müssen, dramatisch reduzieren und auf die nächste Größenordnung skalieren.
Dann wird Ihr nächster Schritt darin bestehen, OOP genauer zu betrachten und mehr über Architektur und Designmuster zu erfahren. Sie werden Ihnen helfen, die Domäne Ihres Systems noch mehr zu reduzieren.
nützliche Leckerbissen
Hör auf so zu tun, als könntest du alles in deinem Kopf behalten. Irgendwann (sieht aus, als hättest du es erreicht) ist es einfach nicht mehr möglich. Wie geht man mit einem Projekt um, das zu groß ist, um es sich zu merken? Nun, genauso behandeln Sie Projekte, die von einer anderen Person geschrieben wurden oder die Sie schreiben, um von jemand anderem verwaltet zu werden.
Der wichtigste Punkt: Schreibe guten Code. Verwenden Sie konsistente, aussagekräftige Namen für Klassen, Methoden, Variablen usw. Schreiben Sie Funktionen (bzw. Methoden), die genau das tun, was der Name sagt, nicht mehr und nicht weniger. Keine kniffligen Abkürzungen, unerwartete Nebenwirkungen, Zeitbomben, Überraschungen. Sie müssen in der Lage sein, eine Funktion mit Zuversicht zu verwenden, ohne ihre Implementierung zu lesen, um zu überprüfen, was sie tut und wie.
Organisieren Sie Ihren Code. Separater GUI-Code aus Business-Logik-Code. Halte sie in separaten Ordnern. Wenn eine Datei beides enthält, refaktorieren Sie sie. Wenn Sie Code generiert haben, bewahren Sie diesen in einem separaten Ordner auf (so dass Sie nie versucht sind, ihn zu ändern).
Verwenden Sie ein Versionskontrollsystem. (Kann nicht oft gesagt werden)
Profilieren Sie Ihren Prozess!
Genau wie Profiling-Code können Sie Ihren Entwicklungsprozess profilieren.
Schauen Sie, wo die meiste Zeit verbracht wird und versuchen Sie, diesen Teil Ihres Prozesses zu optimieren.
Der größte Knall für Ihr Geld kommt wahrscheinlich von:
Versionskontrolle (z.B. Svn, Mercurial, Git etc.)
Build Server (z. B. Hudson)
Tests
Refactoring
Sie müssen Ihren Code-Erstellungsprozess neu gestalten. Möglicherweise auch dein Code.
Ich empfehle auch Code Complete lesen.