Sollte ein Entwickler gegen unnötige oder schädliche Funktionen argumentieren?

Was ist eine gute Einstellung der Entwickler, wenn sie über neue Funktionen diskutieren, und zwar über unkritische / fragwürdige Funktionen?

Angenommen, Sie entwickeln eine Java-ähnliche Sprache, und der Chef sagt: "Wir brauchen Zeiger, damit Entwickler direkt mit dem Objektspeicher experimentieren können!"

Sollte der Entwickler die Idee verwerfen, weil sie unvorstellbare Komplexität und Sicherheitslücken schafft, oder sollte er tun, worum es geht?

Dies mag kein gutes Beispiel sein, aber was ist mit Dingen, die sich eher in einer Grauzone befinden, wie das Hinzufügen von Schaltflächen, die den Workflow unterbrechen oder gegen die interne Struktur des Programms usw. verstoßen?

Was ist die optimale Verteilung "kann" vs. "kann nicht" für einen normalen Programmierer?

EDIT: Die Frage ist nicht über einen schlechten Chef: D

Ich war mehr daran interessiert, wie Menschen an neue Probleme herangehen, die eine spürbare Menge von Problemen mit sich bringen und vielleicht nur von geringem Nutzen sind.

Sollte die allgemeine Einstellung sein:

1. Ja, wir werden es tun, die Komplexität vermasseln
2. vielleicht
3. Nein, die allgemeine Überarbeitung und die Auswirkungen rechtfertigen die Änderung nicht

Wie soll ein guter Entwickler reagieren?

Das Beste ist, ein Meeting zu haben und die Vor- und Nachteile als Gruppe zu besprechen und auf dieser Basis die beste Lösung zu besprechen. Wenn Sie ein Team haben, lassen Sie es sich auf eine Lösung einigen. Sobald sich ein Team auf etwas geeinigt hat, tendieren Manager und "Chefs" dazu, sich für die Lösung zu entscheiden.

Wenn Ihr Chef immer noch nicht einverstanden ist, haben Sie alles getan, was Sie tun können: Sie haben Ihr Team und Ihre Manager zusammengebracht und die Vor- und Nachteile abgedeckt, und trotzdem hat Ihr Chef eine potenziell minderwertige Lösung ausgewählt.

Der Schlüssel dazu ist die Diskussion der Vor- und Nachteile als Gruppe. Auf diese Weise besprechen Sie mit Ihrem Team die beste Lösung und weisen gleichzeitig auf die Entscheidung Ihres Chefs hin (bevor er sie trifft), ohne die politische Gegenreaktion zu haben, nach der die Leute wissen, warum Sie die Entscheidung Ihres Chefs für richtig halten war der falsche.

Dies ist eine zarte arbeitspolitische Situation, die jedoch einvernehmlich gehandhabt werden kann.

Wenn Ihr Chef Sie auffordert, dumme Aufgaben zu erledigen, sollten Sie (freundlich) erklären, warum dies dumm ist.

Wenn er oder sie den Punkt nicht versteht, dann sind Sie verpflichtet, dumme Dinge zu tun. Das ist es. Er ist der Boss. In diesem Fall können Sie einfach tun, was er / sie sagt, oder mit seinem / ihrem Chef sprechen oder den Job wechseln.

Sie könnten dem Chef sagen , dass es zwar technisch möglich ist, wird es kostet X Menge an Zeit und Geld ausgegeben Aufwand auf Analyse, Design, neu zu schreiben vorhandenen Code, Test, Regressionstests, ... Und dann fragen , ob das Merkmal es wert ist . Manchmal lautet die Antwort "Ja! Das müssen wir haben!", Manchmal "Nein, ich denke nicht".

Wenn die Funktion, nach der gefragt wird, gegen ein Kernprinzip der Anwendung verstößt (z. B. "Blaue Schaltfläche hinzufügen!" Für eine Benutzeroberfläche, die gemäß Kundenanforderung nur rote Schaltflächen enthält), halte ich sie für in Ordnung zu fragen "Warum?" und erwähne, dass es gegen das vorgegebene Design verstößt.

Am Ende ist fast alles ein "Können" (es ist aus technischer Sicht vielleicht nicht schwer , eine blaue Benutzeroberfläche mit einem roten Knopf zu versehen), es ist eher eine Frage des "Sollte".

Um Ihre bearbeitete Frage zu beantworten, sollte die Antwort "Vielleicht" lauten, bis weitere Untersuchungen und Analysen durchgeführt wurden.

Sie möchten nicht mit "Ja, bedingungslos" antworten, da Sie sich möglicherweise auf etwas festlegen müssen, das Sie innerhalb des vorgegebenen Zeitrahmens nicht liefern können.

Sie möchten nicht mit # 3 "Nein, es ist zu viel Arbeit" antworten, denn dann scheinen Sie nicht kooperativ und unnötig schwierig zu sein.

Aus der Sicht eines Entwicklers: Sagen Sie NIEMALS jemandem, der die Rechnungen bezahlt, dass er nicht das haben kann, was er will. Stattdessen können Sie ihnen sagen, dass sie es für diesen Preis nicht haben können oder dass sie es nicht genau so haben können, wie sie es ursprünglich gedacht hatten.

Zu Ihrem "Zeiger" -Beispiel; .NET, eine Umgebung mit verwaltetem Code, verfügt über Zeiger. Sie sind für ein hohes Maß an Interoperabilität mit nicht verwaltetem Code von entscheidender Bedeutung. Ihre "sichere" Verwendung ist jedoch streng geregelt, und wenn sie in "unsicherem" Code verwendet wird, erfordert dieser Code zur Laufzeit höhere Sicherheitsberechtigungen. Wenn Sie eine verwaltete Sprache entwickeln, für die auch ein direkter Speicherzugriff über Zeiger erforderlich ist, könnten Sie ein ähnliches Schema für die Zusammenstellung hinter den Kulissen finden, bei dem Sie verwaltete schreibgeschützte Zeiger verwenden, bei denen Sie nicht automatisch zusammenstellen können, und " true "zeigt nur in den vertrauenswürdigsten Bereichen der Codebasis.

Zu Ihren GUI-Beispielen: Wenn Sie wissen, dass eine neue Funktion den aktuellen Code-Fluss "unterbricht", können Sie dies testen und stabiler entwickeln, um frühere Arbeiten des Workflows rückgängig zu machen. Ihre Kunden und manchmal sogar Ihr Vorgesetzter haben normalerweise keine Ahnung oder kein Interesse an der Struktur des Programms. Wenn etwas, was sie wollen, aufgrund der Art und Weise, wie Sie das Programm strukturiert haben, schwierig ist, dann ist die Struktur per definitionem falsch, weil Sie nicht tun können, was der Client will.

In jedem Fall kann diese neue Funktion den Umfang der erforderlichen Arbeiten über das hinaus erhöhen, was der Kunde sich vorgestellt hat. Dies erfordert entweder eine Verlängerung des Zeitplans, mehr Geld und / oder eine Reduzierung anderer geplanter Arbeiten.

Wenn Sie jedoch wissen, wie Sie auf einfachere oder logischere Weise dasselbe grundlegende Ergebnis erzielen können, kann dies dem Kunden vorgeschlagen werden. Obwohl es sie definitiv gibt, habe ich glücklicherweise noch keinen Kunden gesehen, der sich kategorisch geweigert hat, den Eingaben von Entwicklern zuzuhören, insbesondere in einer agilen Umgebung, in der es einen "Product Owner" gibt, dessen einzige Aufgabe es ist, sich mit der Entwicklung verschiedener erforderlicher Details zu befassen, wie z diese.

Wenn Sie viele Jahre mit dem Programmieren für große Anwendungen verbringen und dabei kritisch darüber nachdenken, entwickeln Sie ein genau abgestimmtes Gefühl dafür, wann ein Feature Probleme verursachen wird, die seine Nützlichkeit überwiegen. Ein anderes Wort dafür ist Weisheit , und genauso wie es bei anderen Arten von Weisheit der Fall ist, kann es eine Herausforderung sein, diejenigen dazu zu bringen, die ihren Wert nicht sehen.

Andere Poster haben argumentiert, dass Sie versuchen sollten, die Kosten des Problems, das durch ein problematisches Feature verursacht wird, zu quantifizieren. Dies ist eine gute Idee, wenn dies möglich ist, in der Regel jedoch nicht. In der Regel können nur die unmittelbaren Implementierungskosten geschätzt werden. Auch das ist bei größeren Features oft schwierig. Was die zukünftigen Kosten angeht, sind Sie in einer schwierigen Situation. Sie wissen nicht mit Sicherheit, welche anderen Funktionen erforderlich sind oder wie lange das Produkt gewartet wird. Die Kosten sind in der Regel viel höher, als Sie mit einer Schätzung auf der Grundlage von harten Fakten belegen könnten.

Je mehr Kompetenz Sie in der Vergangenheit unter Beweis gestellt haben, desto mehr Spielraum haben Sie, um ein Feature für eine schlechte Idee zu erklären. Das kann nur mit der Zeit und einer nachgewiesenen Erfolgsgeschichte geschehen. Sie sollten sich jedoch stets bemühen, die Anfrage zu erfüllen, da dies von Ihrem Kunden gewünscht wird. Sie sollten Vorbehalte ausdrücken, die auf Ihren Erfahrungen beruhen. Sobald Sie dies getan haben, wird dies in 90% der Fälle zu einem Nichtproblem, da Sie eine Konversation beginnen, die das Problem an der Wurzel packt dieses Feature überhaupt? An diesem Punkt können Sie Alternativen anbieten oder vielleicht zustimmen, dass die angeforderte Funktion zwar Probleme verursacht, aber dennoch erforderlich ist.

Natürlich ist es auch möglich, dass Sie sich einfach irren. Macht Software-Engineering keinen Spaß?

Da die Frage ziemlich vage ist, werde ich sie mit meiner Antwort etwas verallgemeinern.

Befragen Sie sie immer, aber hören Sie auf ihre Argumentation. Manchmal vergessen die Leute einfach, wie praktisch eine Funktion ist oder wie lange die Programmierung dauern würde. Auf der anderen Seite geraten wir manchmal in die Programmierer-Mentalität, effizient / schnörkellos / usw. zu sein, und wir vergessen, dass das, was wir als nicht wesentlich für ein Projekt betrachten, wirklich nicht für den Kunden ist.

Wenn sie einen guten Grund haben, lassen Sie sie wissen, wie lange es dauern würde, es und alle möglichen Unebenheiten zu programmieren, auf die Sie während der Implementierung stoßen werden, und sehen Sie, ob sie weiterhin damit fortfahren möchten. Geben Sie andernfalls an, warum Sie das nicht für eine gute Idee halten, und sehen Sie, wie sie darauf reagieren. Spülen und wiederholen.

Das meiste ist bereits gesagt, aber eines möchte ich in meinem aktuellen Arbeitsumfeld hervorheben. Ich arbeite für ein Unternehmen, das Auftragnehmer für andere Unternehmen ist, und unsere Anwendungen beziehen sich auf Geschäftsprozesse (zu einem angemessenen Betrag treiben sie den Verkauf und die Kundenkommunikation voran).

Geschäftsprozesse zusammen mit den dazugehörigen Produkten können (zumindest wenn das Unternehmen groß genug ist) sehr komplex sein. Wenn Sie eine komplexe Sache modellieren, weist die resultierende Anwendung bis zu einem gewissen Grad eine entsprechende Komplexität auf. Da die meisten Geschäftsleute nur ihren Teil des Prozesses sehen, ist die Komplexität der gesamten Anwendung / des Prozesses größer als die Komplexität, die nur für einen Benutzer sichtbar ist.

Mein Punkt ist, dass, wenn eine neue Geschäftsanforderung entsteht, diese für die Geschäftsleute funktioniert, da sie die Komplexität nicht wesentlich erhöht, sondern möglicherweise einen größeren Einfluss auf das gesamte System hat. Meiner Meinung nach ist dies kein Grund, sich gegen diese Änderung auszusprechen. Es ist der richtige Punkt, um den Aufwand (und die Kosten) mit dem Kunden zu besprechen. Es wird den Kunden wahrscheinlich nicht davon abhalten, dieses Feature zu entwickeln, aber mit der Zeit werden sie ein Gefühl für die Anwendungen und einige Diskussionen über "uuh, du bist so teuer!" Bekommen. wird viel weniger wählerisch sein.

Ich weiß nicht, ob Sie sich in einer vergleichbaren Situation befinden, aber ich habe erfahren, dass die Situation der Stakeholder nicht unbedingt die Komplexität aufweist, mit der sich Entwickler und Architekten des IT-Systems konfrontiert sehen. In dieser Situation hilft die Kommunikation beiden Seiten.

Entschuldigung, aber diese Frage klingt wie eine minderjährige Bitte um väterlichen Rat. In diesem Fall muss der gute Entwickler die folgenden Gebote einhalten:

• Bleib dir selbst treu. Wenn Sie sich bei einer Funktion unwohl fühlen, äußern Sie Ihre Bedenken hörbar. Die Chancen stehen gut, dass das Team nur auf eine Eröffnung wartet.
• Versuchen Sie nicht, die Erfahrung durch die Faustregeln der Erfahrenen zu ersetzen. Für Sie ist jede Situation anders, jede Funktion ist neu. Dies ist ein Plus, das Ihre Senioren nicht haben.
• Softwareentwicklung ist keine exakte Wissenschaft, sie wird es niemals sein. Sammeln Sie daher Weisheit, nicht Verhalten.
• Akzeptiere die Niederlage. Wenn das Team etwas anderes vereinbart, wiederholen Sie Ihre Bedenken nicht ad nauseam.
• Denk positiv. Wenn die Idee wirklich nach "Abschuss" bittet, versuchen Sie, positive Aspekte zu finden und zu benennen, bevor Sie die Mängel auflisten.
• Erfahren Sie, wie Sie mit Menschen interagieren. Wir Entwickler legen oft technisches Wissen über soziale Kompetenz. Die technischen Fähigkeiten erreichen frühzeitig ihren Höhepunkt, aber die soziale Kompetenz kann bis zur Pensionierung weiter wachsen.

Ich glaube daran, schlechte Anforderungen zurückzudrängen. Aber ich glaube auch, dass, wenn Sie Ihr Bestes gegeben haben, um zu erklären, warum sie schlecht sind und sie immer noch wollen, Sie zustimmen und Ihren Job machen.

Ich hatte zum Beispiel Leute, die Anforderungen wollten, die sich gegenseitig ausschließen, was die Anwendung bereits tut. Wenn ich das tue, wird dies zu 100% garantiert brechen. Also sende ich die Anforderung zurück und sage ihnen, dass dies gegen diese andere Geschäftsregel verstößt, die wir bereits eingeführt haben. Möchten sie diese Regel auch ändern? Oft hat die kleine Gruppe, die eine bestimmte Anforderung hat, keinen Zugriff auf das Gesamtbild dessen, was der Rest der Anwendung tun kann. Die meiste Zeit, als ich eine dieser Antworten zurückgeschickt habe, hat der Kunde festgestellt, dass die Anfangsregel kritischer war, und festgestellt, dass sich die gewünschte Änderung nicht gelohnt hat. Wenn sie sich entschieden haben, die Änderung vorzunehmen, haben sie dies nach Rücksprache mit den Personen getan, die die ursprüngliche Anforderung vorangetrieben haben.

Manchmal können sie nur Fragen zur Klärung stellen, um zu erkennen, dass das Problem nicht so einfach ist, wie sie dachten. Manchmal möchte man fragen, warum sie etwas wollen und kommt zu dem wirklichen Bedürfnis, das die Veränderung antreibt. Sobald Sie dies verstanden haben, ist es oft einfacher, eine alternative Lösung zu finden, die für Sie als Entwickler geeignet ist und deren Anforderungen erfüllt. Wenn Sie diese Lösung dahingehend präsentieren können, wie sie ihren Anforderungen besser gerecht wird als der ursprüngliche Vorschlag, haben Sie die Chancen, dass Ihre Änderung akzeptiert wird, erheblich verbessert.

Manchmal, wenn eine Änderung auf einer grundlegenden Ebene in Ihrem Design zu Chaos führt, reicht es aus, ihnen die neue Schätzung der Stunden, die die Änderung dauern wird, mitzuteilen, um sie zu deaktivieren. Wenn Sie dies mit einer Risikobewertung kombinieren, die aufzeigt, in welche kritischen Funktionen Sie möglicherweise neue Fehler einführen, und ihnen mitteilt, dass 3 Personen 6 Wochen engagierten Einsatz benötigen, ist dies plötzlich nicht mehr so ​​wichtig.

Aber manchmal sagt man ihnen, dass dies keine gute Idee ist und warum, und sie sagen immer noch: "Schade, dass wir es brauchen." Sie gewinnen einiges und Sie verlieren einiges und manchmal haben sich die geschäftlichen Anforderungen wirklich geändert, und die Anwendung muss dies berücksichtigen. Sobald die Entscheidung endgültig ist, ist es nicht mehr an der Zeit zu hinterfragen, was Sie tun, und es ist an der Zeit, damit fortzufahren. Wenn Sie Ihre Einwände dokumentiert haben, sollten Sie persönlich immer noch an einem guten Ort sein, wenn das Budget überschritten wird und neue und aufregendere Fehler verursacht. Und sie sind möglicherweise sogar eher bereit, Ihnen beim nächsten Mal zuzuhören, wenn Sie nachweislich bei solchen Dingen richtig liegen.

Der Schlüssel zum Gewinnen vieler dieser Diskussionen (niemand gewinnt alle) besteht darin, zunächst eine Erfolgsbilanz zu erstellen, um zu wissen, wovon Sie sprechen. Senden Sie als nächstes ein schriftliches Dokument, in dem angegeben ist, welche Bedenken Sie haben (viele Manager sind risikobehaftet, sie möchten mit größerer Wahrscheinlichkeit nicht, dass jemand ein Dokument hat, das sie später als falsch erweist, und sie widmen dem, was Sie schriftlich festhalten, mehr Aufmerksamkeit) und schließlich um sicherzustellen, dass sie alle Kosten (nicht nur Stunden, sondern auch Sicherheitsrisiken, das Einführen neuer Fehler, das Versäumen von Fristen usw.) für die Durchführung der Änderung verstehen. Veränderung ist nicht kostenlos und sie müssen das verstehen. Der nächste Schlüssel ist, dies wie ein Erwachsener und nicht wie ein jammerndes Kind zu tun ("aber ich möchte es nicht benutzen ... weil es mir nicht gefällt"). Machen Sie ein Geschäftsmodell, wenn Sie es nicht tun, und Sie werden viel weiter kommen, wenn Sie eine schlechte Anforderung zurückschieben.

Wenn ich Sie richtig lese, geht es in Wirklichkeit um unbekannte Komplexität. Anfangs las ich Ihre Frage wie folgt: "Ich sehe das äußerst wahrscheinliche Risiko einer übermäßigen Komplexität, aber der Chef nicht". Aber Sie sagen, dass der Chef kein Problem ist, und ich gehe davon aus, dass Sie nicht sicher sind, welche Risiken bestehen Hinzufügen von inakzeptabler Komplexität sind.

In diesem Fall würde ich eine Art Risikominderungsstrategie empfehlen. Bild, das Sie erwägen, Ihrer API WCF / Web-Services hinzuzufügen, was ohne Belohnung fantastisch oder sehr komplex sein kann:

• Fügen Sie das Feature in einem Zweig hinzu. Wenn es funktioniert, führen Sie es zusammen. Wenn es sich in ein Rattennest verwandelt, töte es.
• Starten Sie ein neues einseitiges Projekt und führen Sie einen Proof of Concept durch. Wenn Sie in kurzer Zeit keinen Proof of Concept durchführen können, lassen Sie ihn fallen. Wenn der Proof of Concept funktioniert, vergrößern Sie ihn und integrieren Sie ihn in Ihren
• Durchsuchen Sie das Internet nach Personen, die sich mit dieser Funktion oder Technologie auseinandersetzen. Wo viel los ist, kann eine Technologie echte Risiken einer übermäßigen Komplexität bergen. Java Beans und COM + sind wahrscheinlich alte, aber gute Beispiele für Funktionen, die die Komplexität erheblich gesteigert haben und möglicherweise die Vorteile der Gleichung nicht erfüllen

Argumentieren Sie nicht. Besprechen Sie möglicherweise ja. Es sollte jedoch als Ergänzung zur Spezifikation behandelt und mit anderen Funktionen priorisiert werden. Wenn Sie wissen, dass die Anforderung eine unangemessene Menge an Zeit und Komplexität für die Implementierung mit sich bringt, geben Sie dies im Voraus an. Nicht als Widerspruch gegen die Ausführung der Anfrage, sondern nur als Erklärung dessen, was Ihrer Meinung nach für die Implementierung erforderlich ist.

Es kommt sehr auf die Anfrage an. Die Zeigerimplementierung ist groß genug, um ein gesamtes Projekt zu bewirken, sodass die Vorzüge abgewogen werden sollten, wenn eine Auswahl getroffen wird.

Implementierung einer Schaltfläche, die den Fluss unterbricht. Vielleicht nicht so schlimm, wenn das Formular so angeordnet werden kann, dass die Schaltfläche optional ist. Ich habe genau das getan. Ich habe den Knopf hinzugefügt, aber auch genug Informationen vor der Hand gesammelt, so dass der Knopf optional wurde. Benutzer, die erwartet hatten, dass es dort sein würde, nutzten es, und diejenigen, die erkannten, dass es nur redundant war, taten es nicht.

Es dreht sich alles um Balance und das Wissen, wann Sie Ihre Schlachten auswählen müssen. Einige Dinge sind einfacher zu implementieren, als sich mit den sozialen Aspekten des Nichteinbeziehens auseinanderzusetzen.

Das Problem, das ich sehe, ist Ihre Verwendung des Wortes argumentieren.

Sie müssen Designprobleme und die Gründe dafür ansprechen, aber seien Sie vorsichtig, da Programmierer dazu neigen, Positionen zu verteidigen, die sie eingenommen haben, und Punkte nur aus Gründen der Argumentation (manchmal) zu argumentieren. Ich muss mich davon abhalten, ein bisschen zu streiten - und es gelingt mir nicht immer. Auch wenn ich älter werde, stelle ich fest, dass ich öfter falsch liege als früher - oder schlimmer noch, ich habe nicht erkannt, wie oft ich mich geirrt habe :)

Wenn Sie Anforderungen klar definiert haben (die Sprache muss sicher sein, wir benötigen Zeiger für den Zugriff auf Legacy-Routinen), können Sie den Konflikt zwischen den beiden Anforderungen darstellen und fragen, welche wichtiger sind. Wenn Sie die Anforderungen und die Gründe dafür kennen, können Sie möglicherweise sogar eine völlig andere Lösung finden, die beide Anforderungen unterstützt (JNI - ein bisschen).

Wenn nicht, ist es vielleicht eine gute Zeit, sie zu kodifizieren!

1. Erkenne, dass du nicht alles weißt und nicht alles tun kannst.

2. Wenn Sie sicher sind, dass es eine schlechte Idee ist, sagen Sie, was schlecht ist.

3. Wenn sie versuchen, auf Sie zu drängen, sagen Sie entweder: Benötigen Sie mehr Zeit für die Analyse, brauchen Sie mehr Zeit oder sagen Sie, dass wir keine gute Lösung für dieses Problem gefunden haben.

4. Wenn sie immer noch darauf bestehen, die schlechte Idee umzusetzen, holen Sie sich eine Bestätigung von ihnen, dass Sie davon abgeraten haben, einschließlich Ihrer Gründe. Sie können sogar eine E-Mail mit einer Zusammenfassung der Diskussion an Ihren Vorgesetzten senden. Dies könnte Ihre a ** später speichern.

In einem idealen Szenario hätten Sie einen Lead-Entwickler, der die endgültigen Entscheidungen auf der technischen Seite trifft, und einen Business-Lead, der die endgültigen Entscheidungen auf der geschäftlichen Seite trifft. Dies würde die beiden Hauptfragen beantworten:

1 Was? Was will der Kunde?

2) wie? Wie erreichen wir dies aus technologischer Sicht?

Was der Kunde will, ist der ultimative Entscheider, da er die Rechnungen bezahlt

Als Entwickler sollte es Ihnen eigentlich egal sein, welche Anforderungen implementiert werden sollen.

Sie sollten jedoch erklären, ob etwas unrealistisch ist und ob es bessere Möglichkeiten gibt.

Manchmal sein tatsächlicher Kundenwunsch (von der Kundeninternallpolitik kommend). Dann ist es hoffnungslos und muss getan werden (aber das Management sollte auch überlegen, ob ein solches Projekt fortgesetzt werden soll oder ob sie den Preis neu verhandeln sollen.)

Das ist fast eine tägliche Aufgabe für mich und ich bin froh, dass es so ist.

Wenn Sie die Änderung haben, um Ihre Meinung darüber abzugeben, ob bestimmte Anforderungen Teil der Anwendung sein sollen oder nicht, erwarten nichttechnische Personen, dass Sie Ihre technischen Kenntnisse ergänzen (z. B. "Verwendung von Zeigern würde die Anwendung instabil machen" oder "Verwendung von" Ein GET-Parameter für X-Zwecke ist ein Sicherheitsrisiko "). Technische Mitarbeiter würden sich auch über Ihr Feedback zu bestimmten Vorteilen oder Nachteilen freuen, über die sie möglicherweise nicht nachgedacht haben.

Natürlich ist es hart, wenn jeder Feature X haben möchte und Sie am Ende sagen, dass es möglicherweise nicht gut ist, aber am Ende versucht jeder, eine sichere, robuste und stabile Anwendung zu erstellen (wartbar, flexibel usw.). ) und jede Stimme sollte zählen.

Die Beantwortung Ihrer Frage ist nicht Teil der Aufgabe eines Entwicklers (dh der Entwicklung), sondern ein "Extra", das Qualität und Teamarbeit liefert.

Wenn Sie in der Lage sind, die Nachteile (Komplexität, mangelnde Benutzerfreundlichkeit usw.) zu verstehen, liegt es im Interesse aller, wenn Sie dies nach besten Kräften erklären. Oft verstehen Nicht-Entwickler die Probleme beim Hinzufügen neuer Funktionen nicht. Für sie ist es einfach, weil sie nichts tun oder auch nur darüber nachdenken müssen.

Wenn jedoch die Befugnisse entscheiden, dass die neue Funktion hinzugefügt wird, sollten Sie die bestmögliche Arbeit leisten. Es ist eine Herausforderung.

Und wenn die neue Funktion zu dumm oder die Arbeitsumgebung zu beschissen ist, ist es Zeit, einen anderen Job zu finden.