Was würden Entwickler anders machen? [geschlossen]

Als Entwickler verbringe ich den größten Teil meiner Zeit mit dem Nachdenken über Code, Benutzeroberfläche, Datenstrukturen usw., aber (ich gebe tapfer zu) ich neige nicht dazu, die Auswirkungen meiner App auf Systemadministratoren und Datenbankadministratoren zu berücksichtigen, bis es Zeit für die Bereitstellung ist die App.

Erstens tut es mir leid. Zweitens, was würden ich und andere Entwickler, mit denen Sie zu tun haben, anders machen? Welche Dinge würden Ihnen das Leben erleichtern, weniger Probleme verursachen, die Zusammenarbeit fördern und Abstürze, Leistungsprobleme und Konfigurations-Albträume reduzieren?

1. Denken Sie über den Tag 0 nach und bauen Sie Sicherheit ein.
2. Verwenden Sie die Versionskontrolle für alles: Quellcode, Dokumentation, Konfiguration usw.
3. Dokumentation, Dokumentation, Dokumentation.
4. Saubere Installation und Deinstallation mit plattformeigenen Paketen
5. Trennen Sie Konfigurationsdaten von Bibliotheken und ausführbaren Dateien
6. Unterstützung für die parallele Ausführung verschiedener Versionen zum Testen und Migrieren
7. Robuste, konfigurierbare Protokollierung
8. Leichte, genaue und sichere Überwachung
9. Anwendungsüberprüfung und -sicherung
10. Wie reagiert Ihre Anwendung auf Probleme: Nicht genügend Arbeitsspeicher, Dateisystem voll, Netzwerkausfall, fehlende / beschädigte Konfigurationsdateien, Zeitversatz?
11. Verwenden Sie immer separate Entwicklungs-, Test- und Produktionsumgebungen. Bei all der kostenlosen VM-Software gibt es keine Entschuldigung!

Denken Sie daran, dass Ihre Anwendung wahrscheinlich mehr Status hat als "Hoch" oder "Runter". Zeichnen Sie ein Zustandsdiagramm. Die meisten Anwendungen haben Zustände wie:

• Nieder
• Initialisierung
• Wiederherstellung
• up-but-not-accepting-Arbeit
• warten
• Checkpointing
• wird bearbeitet
• beenden
• Herunterfahren
• Nieder

Überlegen Sie, was passiert, wenn das System in jedem Zustand abstürzt. Wie überwacht und steuert ein Sysadmin Statusübergänge?

Unterscheiden Sie den "Benutzer" von der SA.

Ein "Benutzer" muss wissen, wie er mit Ihrer Software umgeht. Benutzer interessieren sich nicht für Dinge wie die Installation Ihrer Software.

Der SA ist es egal, wie Sie Ihre Software verwenden, er muss jedoch einige wichtige Details zur Installation der Software kennen.

Verfassen Sie die Dokumentation für jede dieser Rollen separat, einschließlich der für jede dieser Rollen relevanten Informationen.

Einer meiner Wünsche ist die Einbeziehung der richtigen Meldungen in Ausnahmen und Fehlercodes. Es ist völlig undurchsichtig für jemanden, der die Anwendung nicht entwickelt hat, was das JimmyNotAtHomeException: it's late!bedeutet.

Aber eine Nachricht wie Unable to find jimmy - initial manual call_mother procedureist sehr hilfreich.

Kommunikation, Kommunikation, Kommunikation. Jedes Problem zwischen einem Systemadministrator und einem Entwickler kann so gut wie immer auf einen Mangel an Kommunikation zurückgeführt werden. Wenn sich vor einem Projekt die Sysadmins (oder ein Vertreter davon) und die Entwickler zusammengetan und eine nette Rahmendiskussion geführt hätten, könnten viele Probleme auf der ganzen Linie vermieden werden. Ich kann Ihnen nicht sagen, wie viele Dinge durcheinandergebracht werden, weil Sie alle auf einer Box in der Entwicklung entwickeln, nur um zu sehen, wie sie in prod in Flammen aufgehen, weil die App dann in App-Server + DB-Server + Schnittstellenserver usw. getrennt wird. Ein großes Lob dafür, dass Sie dieses Thema angesprochen haben.

Binden Sie uns frühzeitig in das Projekt ein. Wie echt echt früh, in der funktionalen Spezifikationsphase.

Jemand anderes hat erwähnt, dass es auf jedem PC manuell installiert werden muss, aber dasselbe gilt für Konfigurations- und Konfigurationsänderungen. Wenn Sie so etwas wie Connect Strings clientseitig speichern und regelmäßig aktualisieren müssen, werden wir Sie wahrscheinlich umbringen wollen .

Wählen Sie aus dem gleichen Grund eine Technologie, die ordnungsgemäß zentral verwaltet und konfiguriert werden kann. Stellen Sie sicher, dass es sich gut in die von uns verwendeten zentralen Verwaltungstools integrieren lässt.

Testen Sie immer mit dem kleinsten gemeinsamen Nenner. Dies bedeutet, dass Sie als Nicht-Administrator auf dem primitivsten Betriebssystem, der Anwendungssuite und der Browser-Plattform häufig verwendet werden. Wir möchten nicht, dass ein erforderliches Browser-Upgrade für alle unsere Benutzer in der letztmöglichen Minute auf uns gelandet ist.

Machen Sie uns keine Vorwürfe, wenn etwas schief geht. In meinem alten Job haben die Entwickler jedes Mal, wenn eine App kaputt ging, sofort mit dem Finger auf uns gezeigt. "Sie haben einen neuen Patch installiert, Browser werden nicht aktualisiert, Ihre Sicherheit ist zu streng" oder was auch immer. Dies erzeugt eine zerstörerische Atmosphäre. Wir sind wirklich auf der gleichen Seite und wollen mit Ihnen zusammenarbeiten, um das Problem zu beheben, können dies aber unter diesen Umständen nicht.

Sei nicht elitär.

„Verschwenden Sie nicht meine Zeit, Kumpel. Sie sind nur ein Systemadministrator für Hunde. Ich schreibe die Software und Sie warten sie nur.

Ein Entwickler hat mir diese Worte tatsächlich einmal gesagt (1). In E-Mail. An eine große Verteilergruppe weitergeleitet. Die Implikation war klar: Als Entwickler war er Herr und Meister des gesamten Software-Universums; und ich war nur ein Tagelöhner, der angestellt wurde, um Aufgaben zu erledigen, mit denen er seine wertvolle Zeit nicht verschwenden konnte. Natürlich ist dies ein fast Worst-Case-Beispiel, aber Sie wissen, ich habe starke und schwache Echos dieses Kommentars von einer Reihe von Entwicklern sowohl vor als auch nach (2) gehört.

Du verdienst vielleicht mehr Geld als ich (aber nimm es nicht an!). Es ist jedoch ein Team erforderlich, um die Systeme zu erstellen, zu betreiben und zu warten, auf die sich unsere Benutzer verlassen. Letztendlich dienen wir ihnen alle.

Ich verstehe, dass Ihr Job und Ihre Fähigkeiten sich von meinen unterscheiden. Ich respektiere deine Fähigkeiten. Ich hoffe, Sie beantworten meine Fragen auch dann, wenn sie Ihnen elementar und dumm erscheinen. Ich werde diese Höflichkeit fröhlich erwidern!

Ich bin nicht auf einem verrückten Power-Trip, wie so viele schlechte (oder einfach gleichgültige) Entwickler gesagt und gedacht und in verschiedenen Foren gepostet haben. Aber meine Bedenken sind anders als deine, und meine Fragen und Vorschläge dienen nicht meinem Ego. In der Tat ist es meine Aufgabe, Sie besser aussehen zu lassen, indem Sie Ihre Apps in einem Top-Zustand halten, verfügbar sind und auf alle Benutzer reagieren. Dazu muss ich den Rest des Netzwerks und der Systeme auf dem neuesten Stand halten.

Mir ist völlig bewusst, dass Sie in der Vergangenheit auf dumme, machtverrückte und / oder einfach nur faule Admins gestoßen sind. Ich versuche nicht einer zu sein und nicht so auszusehen. Wenn Sie Platz für diese Möglichkeit lassen und sie anerkennen, wenn Sie sie sehen, sind Sie sich ziemlich sicher, dass Sie das bekommen, was Sie brauchen, während sich die anderen Arschlöcher immer noch darüber aufregen, was für ein Arschloch ihr Sysadmin ist.

(1) Er bestand auch darauf, dass sein Programm (ein Tool zum Schreiben und Verwalten von Softwareanforderungen) zum Installieren und Ausführen Domänenadministratorrechte benötigte. Es war ein großes Sicherheitsrisiko.

(2) Ich habe auch mit vielen großartigen Entwicklern zusammengearbeitet, die bei Bedarf unterrichten und bei Bedarf lernen konnten.

Respektieren Sie, dass die Sysadmins einen Job zu erledigen haben, und lassen Sie sie ihren Job erledigen. Viele Unternehmen haben inkompetente Systemadministratoren, was oft nicht realistisch ist. Aber ich habe arrogante Entwickler gesehen, die den Rat von Systemgruppen ignorierten, auch nachdem die Sysadmins ihre Kompetenz bewiesen haben.

Besprechen Sie den Entwurf eines neuen Systems mit Sysadmins. Oft gibt es wertvolle Erkenntnisse. Entwickler betrachten Diskussionen mit Sysadmins häufig als "vorzeitige Optimierung" und geben erste Anforderungen an. Ich habe tatsächlich gesehen, wie der Leiter einer Entwicklungsgruppe sagte, es sei Zeitverschwendung, mit Systemadministratoren und Datenbankadministratoren über die Anforderungen für neue Datenbankserver zu diskutieren, selbst wenn beschrieben wurde, ob es sich um eine schreibintensive oder eine leseintensive Last handelt, oder Wie viel Speicher würde benötigt.

Besprechen Sie Leistungsprobleme mit Sysadmins. Ehrlich gesagt sind nur Sysadmins in der Lage, Leistungsmetriken auf Systemen richtig zu interpretieren. Ich habe gesehen, wie Entwickler entschieden haben, dass Linux immer Speicher verliert, weil der von "free" gemeldete freie Speicher immer kleiner wird, selbst wenn die Ausgabe von "free" zum zehnten Mal erklärt wird.

Ziehen Sie keine Schlussfolgerungen, ohne dies mit den Systemadministratoren zu besprechen. Ich habe gesehen, wie Entwickler sich mit Theorien wie "Datenbanken sind immer festgefahren" (sie wussten nicht, dass iostat überhaupt existiert), "RAID 5 ist schneller für Transaktions-Workloads" (basierend auf der Erinnerung an ein verschobenes Datenbanksystem) befasst haben von einer Hardwareplattform zur anderen - es war eine leseintensive Arbeitslast, die RAID5-Lösung verfügte über mehr und schnellere Laufwerke, die auf mehr Controller verteilt waren.

Entwerfen Sie keine Lösung für ein Systemproblem, ohne dies mit Systemadministratoren zu besprechen. Ich arbeitete in einer pathologischen Umgebung, in der Entwickler eine Lösung entwarfen und um kleine Unterstützung bei der Implementierung baten. Die Mitglieder der Unix-Gruppe neben mir, dem Leiter der Unix-Gruppe und seinem Chef, wollten Entwickler als "Kunden" behandeln und nicht als Mitarbeiter, die versuchen, eine allgemeine Infrastruktur zu schaffen. Der Kunde hatte immer Recht, ohne zu hinterfragen, was er tat oder warum. Ich war der einzige, der darauf bestand, das Problem beschreiben zu lassen, damit eine korrekte Lösung gefunden werden konnte. Handle nicht so, dass pathologische Umgebungen wie diese entstehen. Dies hat keinen Nettonutzen zur Folge. Stattdessen werden Systemmanager defensiv agieren und jeder wird darunter leiden.

Du bist nicht mehr in der Schule. Dies sind reale Systeme und sie verhalten sich nicht ideal. Zum Beispiel hat nicht alles eine Latenz von Null. Wenn ein Systemadministrator Sie warnt, dass Clustering-Lösungen nur für politische Zwecke gedacht sind und die zusätzliche Komplexität des Systems die allgemeine Zuverlässigkeit verringert, nehmen Sie es ernst. Sie müssen einen realen Ausfallmodus festlegen. Wenn Sie beispielsweise den Server verlieren, mit dem Sie über TCP kommunizieren, wird die Verbindung wahrscheinlich nicht für Sie zurückgesetzt. Sysadmins verstehen die realen Fehlermodi.

Hören Sie entweder zu, was Ihr Sysadmin Ihnen sagt, oder beklagen Sie sich beim Management, dass Ihre Sysadmins inkompetent sind und gefeuert werden müssen. Es macht keinen Sinn, Ihren Sysadmin zu ignorieren.

Überlegen Sie, wie Sie Ihre Anwendung bereitstellen. Machen Sie sich klar, dass es Sinn macht, dies mit Ihren Systemadministratoren zu besprechen. Wenn Sie über 100 identische Server verfügen, die sich nur aufgrund einer einzigen Konfigurationsdatei unterscheiden, können Sie die Masterkopien dieser Konfigurationsdateien an einem zentralen Ort speichern. Erkennen Sie, wie viel besser es jedem geht, wenn sich Ihre Anwendung leicht erneut bereitstellen lässt. Wenn es ein Problem mit einem System gibt, möchten Sie es lieber in weniger als einer Minute auf ein Ersatzsystem zurücksetzen oder eine Ewigkeit warten, bis das defekte System repariert ist? Wenn Sie Ihre Anwendung erneut bereitstellen können, kann das Betriebssystem einfacher und sicherer aktualisiert werden. Das könnte Sie in Zukunft interessieren.

Wenn Sie ein Problem haben, das Ihrer Meinung nach am Betriebssystem liegt, ist es sinnvoll, den Sysadmin sofort anzurufen, um es zu überprüfen. Aber nachdem eine flüchtige Untersuchung nichts ergeben hat, müssen Sie das Problem erklären.

Verstehen Sie, dass es einen Unterschied zwischen "langsam reagieren" und "überhaupt nicht reagieren" gibt.

Konfigurieren und gestalten Sie die Dinge auf vorhersehbare Weise und ändern Sie sie auf vorhersehbare Weise für das Betriebssystem, für das Sie entwickeln. Das bedeutet alles. Zum Beispiel: OpenLDAP hat eine seltsame Art, Googlevels zu erstellen. Auf bestimmten IMAP-Servern sind nicht einmal Konfigurationsdateien vorhanden, sondern es müssen Optionen kompiliert werden. Einige Pakete möchten, dass sich ihre Inhalte in einem bestimmten Verzeichnispfad befinden, was unvermeidlich gegen die Konventionen eines bestimmten Betriebssystems verstößt. Diese Dinge stechen alle in meinen üblichen Konfigurationen als Warzen hervor.

Es ist eine allgemeine Regel, aber nehmen Sie nicht an, dass Sie etwas Besonderes sind, und sind daher gesegnet, die allgemeinen Konventionen für die Funktionsweise von Softwarepaketen auf Ihrer Plattform zu brechen, es sei denn, es gibt einen hinreichend guten Grund für Ihre Software, der dies erfordert. "Ich bin der festen Überzeugung, dass dies so sein sollte" ist nicht gut genug, um das übliche Setup aller zu brechen. Dies muss ein Grund für die Funktion sein, die Ihre Software ausführen möchte.

Wenn die App zwischen Servern kommuniziert, schließen Sie bitte mindestens einen Systemadministrator in die Entwurfsphase ein. Dokumentieren Sie außerdem die Abhängigkeiten von anderen Diensten: SQL, SMTP, HTTP usw. Lassen Sie uns nicht raten, was Sie tun, oder wir können Ihnen nicht helfen, wenn etwas nicht so funktioniert, wie Sie es erwartet haben.

Bitte ermöglichen Sie die automatisierte Bereitstellung Ihrer Software auf Dutzenden oder Hunderten von Systemen. Wenn eine Organisation ein Softwarepaket benötigt, haben Sysadmins mit ziemlicher Sicherheit keine Zeit, es manuell auf jeder Box zu installieren. Wenn für eine Datei Lizenzinformationen erforderlich sind, ist es von großem Vorteil, zu dokumentieren, wie diese bereitgestellt werden.

Adobe hatte in der Vergangenheit einige Installationsprogramme, mit denen man nur schwer arbeiten konnte . bitte ziele höher als das!

Denken Sie an die Skalierung vom ersten Tag an. Sysadmins können Wunder vollbringen, indem sie ein Performance-Problem mit Geld / Hardware bewerfen. Manchmal hilft jedoch kein Betrag davon - denken Sie insbesondere an das Sperren - manchmal können Sie sich nicht aus einem Sperrproblem herauskaufen. Vielen Dank für die Frage :)

Oh und versuchen Sie, 64-Bit zu sein, wo es möglich ist, und auch Multi-Threaded :)

Design für den Betrieb.

Mehr als alles andere hier ...

• Fordern Sie eine simulierte Produktionsumgebung an (einen Entwicklungsserver oder eine virtuelle Maschine mit derselben Konfiguration wie der Live-Server), und testen Sie anschließend den Freigabeprozess. Stellen Sie uns dann diesen Freigabeprozess zur Verfügung, einschließlich einer Liste der Änderungen und der Reihenfolge, in der sie angewendet werden sollen (dh 1. Wartungsmodus aufrufen, 2. SQL-Update anwenden, 3. Quelle auf X-Version aktualisieren, 4. Wartungsmodus verlassen, 5. bete)
• Stellen Sie sicher, dass Sie über einen Wartungsmodus verfügen, der Benutzer aus dem Verkehr ziehen kann, um die Datenintegrität zu gewährleisten. Sie möchten nicht, dass wir ein großes Systemupdate auf mehreren Servern ausführen, auf denen Benutzer angemeldet sind und Transaktionen ausführen. Dies ist in den meisten Fällen ein Rezept für einen Fehlschlag.
• Verwenden Sie ein Entwicklungsmodell, das etwas standardisiert ist. Beispielsweise verwenden alle neuen Anwendungen bei der Arbeit (Webgruppe) Zend Framework.
• Stellen Sie uns Änderungsprotokolle zur Verfügung, die wir lesen können, einschließlich einer Liste der behobenen Fehler, nach denen wir suchen können, um eine Vorstellung vom Umfang der Änderungen zu erhalten. Manchmal können wir potenzielle Probleme identifizieren, nur weil wir eine andere Sichtweise haben.

Obwohl es unrealistisch ist, wäre es hilfreich, wenn Entwickler gezwungen wären, in einer produktiven Sysadmin- oder DBA-Rolle zu arbeiten, bevor sie sich der Welt entziehen.

So viele spezialisierte Anwendungen, mit denen ich mich befasse, haben entweder keine Ahnung von der Installation in einer verwalteten Umgebung oder begehen Gräueltaten beim Datenbankdesign.

1) Die Protokolldatei, in der die Fehler detailliert protokolliert werden. oder ein gutes Fehlerverfolgungssystem wie ELMAH.

2) Die ausführliche Dokumentation zur Installation, Implementierung und zum SA-Handbuch.

3) Plus das oben erwähnte Zeug von anderen erstaunlichen SAs. :)

Das ist alles, woran ich gerade denken kann.

Das Buch Release It! hat eine schöne Auswahl an Horrorgeschichten darüber, was in der Produktion schief gehen kann. Das Lesen kann Anregungen / Ideen für das Entwerfen im Hinblick auf Vorgänge liefern. (Es wurde von Michael Nygard geschrieben, der sowohl auf der Entwicklungs- als auch auf der Betriebsseite gearbeitet hat.)

• Entwickeln Sie nicht ohne Spezifikationen
• Dokumentieren (oder sicherstellen, dass diejenigen, die Dokumente erstellen, dies genau tun)
• Haben Sie keine Angst, den Kunden zu unterstützen (als höheres Support-Level)

Meiner Erfahrung nach würde der größte Unterschied darin bestehen, ob Entwickler ab dem ersten Tag über die Bereitstellung nachdenken. Sobald Sie mit der Konzeption eines neuen Features in der Produktions- / Kundenumgebung beginnen, sollten Sie überlegen, wie es in dieser Umgebung bereitgestellt wird Umwelt und wie es laufen wird.

Sobald sie in den Entwicklungsprozess einsteigen, ist es noch nicht zu spät, aber es kann einige Zeit dauern, bis sie in der Lage sind, ihre Perspektive so weit zu ändern. Sie erkennen erst, wie abstrakt sie die Codebasis betrachten, wenn sie gezwungen sind, sich mit ihr auseinanderzusetzen. In ihren Augen ist es nur eine "Komponente". Von besonderem Interesse ist, wie es in einer vorhandenen Umgebung bereitgestellt wird, in der die vorherige (oder ältere!) Version der Software ausgeführt wird. Bereitstellungsdiskussionen können erhebliche Auswirkungen darauf haben, wie die Architektur an die neue Funktion angepasst wird.

Was ich bisher noch nicht gesehen habe, ist konfigurierbar. Wenn Sie eine App haben, die irgendeine Art von Konfigurationsdatei verwendet, machen Sie alles konfigurierbar.
In meiner Firma habe ich eine einfache App geschrieben, die ein Stück unserer Datenbank exportiert. In der nächsten Woche habe ich es umgeschrieben, damit ein kleiner Teil ausgeschaltet werden kann. Seitdem musste ich jede Woche Teile umschreiben und neu erstellen, um eine kleine Funktion zu ändern. Ich habe gerade eine XML-Konfigurationsdatei hinzugefügt, und jetzt ist es viel einfacher, sie erneut bereitzustellen.
Ich liebe Konfigurationsdateien.

Ich wünschte, Entwickler hätten eine bessere Trennung von QA-Aufgaben. Ich denke, dass es schön ist, wenn ein Entwickler einige Testfälle für ein Projekt erstellen kann, an dem er / sie arbeitet, aber es wäre schön, wenn diese Tests an die Qualitätssicherung weitergereicht würden. Tatsächlich ist es schön, wenn Entwickler QA-Ingenieuren ein wenig helfen, weil es letztendlich für DEV von Vorteil ist.

Stellen Sie sicher , es ist erträglich: Neben allem anderen hier, Blick auf diesen Beitrag auf SO erwähnt - https://stackoverflow.com/questions/205374/what-are-the-core-elements-to-include-in-support- Dokumentation/