Jusqu'où voulez-vous aller avec YAGNI? [fermé]

https://stackoverflow.com/questions/2023638

19-09-2019
|

Question

Je développe une nouvelle application Web révolutionnaire pour le marché des entreprises. Bien sûr, beaucoup d'autres avant moi ont pensé que leur application web serait révolutionnaire pour découvrir ce n'est pas. (Ou il est, mais l'entreprise n'est pas bon quand même).

Alors, je pense, pour savoir si mon idée a une traction avec le coût le plus bas, à suivre une YAGNI extrême:

Pas de sécurité (à savoir, pas d'utilisateurs, etc.). Pour tout nouveau client installer une nouvelle instance de base de données et une nouvelle instance de webapp. Chaque instance de webapp est protégé par un mot de passe du serveur http (ou digérer l'autorisation de base, peut-être sur https).
Pas d'internationalisation. Il suffit de chaîne anglaise intégré dans le code source.
Pas de découplage. Juste des pages Web qui parlent à la base de données.
Pas de trucs de performance. Pas de files d'attente, des caches, des minuteries, des emplois d'arrière-plan, les appels asynchrones, etc.
Pas d'évolutivité. Pas de partitionnement de base de données, pas de tessons, pas le regroupement ou la réplication.
En outre, l'utilisation YAGNI au niveau micro chaque fois approprié.

Je veux juste lancer le projet et d'atteindre le plus vite possible un point où je peux vendre (ou essayer de vendre) mes fonctionnalités innovantes avec une interface utilisateur simple et engageante.

Si le plan échoue, je saurai tôt. Si elle réussit, je verrai ce que les clients veulent ensuite. Veulent-ils une version française? Ou bien ils veulent des utilisateurs et des rôles au sein de l'organisation?

Est-ce que l'on entend par YAGNI, ou est-ce un exemple pathologique et de YAGNI exagéré?

La solution

Je suis entièrement d'accord avec le principe YAGNI, mais vous voulez toujours planifier pour réussir. Si une application a besoin d'une réécriture complète quand il a soudainement plus de dix utilisateurs, il est YAGNI trop loin.

Certaines choses que vous besoin passer. De mon point de vue, les deux points les plus importants:

Ne pas vous tirer une balle dans le pied en ne préparant pas votre application pour l'internationalisation. Si votre application est une bonne, l'internationalisation va être sur la table un jour. En outre, la capacité de gérer des caractères étrangers en utilisant UTF-8 est une exigence absolue lors de la construction d'une application à partir de zéro en 2010. Internationalisation peut sembler pas si important pour un locuteur natif anglais, mais croyez-moi, il est essentiel et la douleur de internationalisant une application est horrible plus tard.
Réfléchissez à deux fois au sujet de la aucune fonction de sécurité chose. Qu'en est-il une organisation ou d'un groupe qui veut travailler avec votre application avec les utilisateurs sur les différents niveaux de sécurité. Il pourrait que ce soit est une fonctionnalité que vous pouvez vraiment faire sans - j'ai un système de sécurité à grains fins intégrée dans plusieurs de mes produits qui n'a jamais été utilisé à son plein potentiel encore. Mais pensez bien savoir si votre application peut se passer, même si elle est réussie.

Autres conseils

est ce qu'ils appellent « prototypage ». Foncez.

Il y a une subtilité entre YAGNI et prototypage.

Quand il est featuritis demandé par l'utilisateur, et vous dites non, c'est YAGNI.
Quand il est la mise en œuvre (I18N, "découplage" (?), Les files d'attente, des caches, des minuteries, etc.) et vous dites pas à vous-même. Ce n'est pas vraiment YAGNI. C'est le prototypage.

La plupart de ce que vous avez ici ne semble pas être goldplating orienté vers l'utilisateur. Je ne dirais pas cela - précisément -. YAGNI

YAGNI est de vous rappeler de voir la différence entre ce que vous peut faire et ce que vous devez faire pour satisfaire vos besoins.

Par exemple, si votre exigence dit « laisser les gens créer des comptes et de se connecter », il suffit d'utiliser les méthodes auth par défaut de votre cadre et passer à la prochaine exigence.

Votre application web peut OpenID de soutien, Active Directory, base de données locale, fichier plat, et un tas d'autres types de méthodes d'authentification, mais vous pouvez satisfaire à l'exigence en mettant en œuvre le plus simple. (Pour moi, YAGNI implique DTSTTCPW ).

"Je peux faire quoi que ce soit, donné assez de temps"

- Chaque programmeur que j'ai rencontré

Pas fan du principe de YAGNI moi-même; Je le vois utilisé trop souvent dans la justification des logiciels mal conçus. Surconception logiciel est un problème aussi bien sûr, mais « YAGNI » ne laisse pas vraiment beaucoup de place pour l'analyse d'impact réel.

Il se trouve que dans le monde des logiciels, la plupart des choses que vous pensez que vous n'êtes pas allez avoir besoin, vous allez réellement besoin. Et puis certains. Who'dathunkit.

J'ai écrit une ou deux applications qui étaient censées être des applications jetables ou hold-overs qui sont encore en production après deux ans. Ils sont une douleur à maintenir.

Surtout quand il s'agit de quelque chose comme la sécurité - vous avez probablement sont en avoir besoin

YAGNI est un bon principe, mais ce n'est pas le seul principe de conception. Beaucoup de sens de faire ci-dessus pour obtenir un produit en face des utilisateurs rapidement. Mais si, par exemple, les pages web qui parlent directement à la base de données commencent à chacun ont un code dupliqué, vous allez constater que la dépendance servilement sur un principe (YAGNI) à l'exclusion des autres (dans ce cas, SEC) limitera votre capacité pour répondre à votre nombre croissant, espérons des demandes de fonctionnalités des utilisateurs.

Si vous allez vraiment développer un application web révolutionnaire pour le marché de l'entreprise Je ne suis pas vraiment sûr de ces choses Y OU A int G onna N eed.

De même, vos exemples sont assez spécifiques. Par exemple, lorsque vous dites: « aucune fonction de sécurité » ... Je dirais que les utilisateurs est une chose que vous pouvez peut-être faire sans, mais vos entrées est désinfectante que vous ne pouvez pas. Aussi « évolutivité » est pas une question de base de données sharding ou la réplication, ce sont des décisions que vous prenez une fois que vous réalisez que votre application n'échelle pas bien.

Je préfère être prudent lorsque vous utilisez YAGNI comme ligne directrice de conception de haut niveau, il convient de mieux quand vous parlez de caractéristiques de produits bizarres ou peut-être les composants logiciels extrême flexibilité.

Juste mon 0.2

Si vous prenez « YAGNI » à cette extrême (et je vais contourner les discussions sur si oui ou non c'est une bonne idée, ainsi que des discussions sur si oui ou non c'est vraiment « YAGNI »), vous devriez être prêt à factoriser sans pitié votre codebase pour ajouter plus tard ce que vous excluez maintenant sans créer une boule de boue.

Dans mon esprit YAGNI est le plus souvent utilisé dans le contexte d'un développeur pensant « oh il serait intelligent si nous avons également ajouté fonction X. Nous pourrions avoir besoin dans l'avenir. » Jamais jamais ajouter des fonctionnalités qui ne sont pas une exigence.

Cela étant dit, votre code doit être ouvert pour modifications si votre client pense fonction Y est absolument nécessaire. Une bonne architecture est un must!

En ce qui concerne à l'évolutivité, les files d'attente, la mise en cache: il dépend. Quelle est l'exigence de l'application? Est-ce un site intranet utilisé par 10 utilisateurs simultanés ou est-ce un site Web populaire avec des millions d'utilisateurs. Ça dépend. Trouver les exigences et faire - rien de plus. YAGNI. Si votre changement d'exigence; modifiez votre demande -. il devrait être ouvert pour les modifications

YAGNI est bon s'il y a une bonne chance vous jamais besoin. Si vous n'avez pas besoin maintenant, mais vous êtes presque sûr que vous en aurez besoin dans un avenir prévisible, il est presque toujours plus facile de l'adapter à l'avant que plus tard. Lorsque vous justifiez pas la mise en œuvre des choses que vous n'avez pas besoin ce deuxième mais presque certainement besoin dans un proche avenir par YAGNI, qui est où les problèmes commencent.

Le point YAGNI est seulement une grande principale parmi d'autres est un bon de se rappeler; parfois YAGNI suggère une décision, mais il y a des raisons tout aussi bien (ou mieux) à choisir une autre.

Voici un domaine où je me sens certains partisans YAGNI peuvent aller trop loin: si vous êtes à l'aise avec OOD / polymorphisme, il en coûte généralement vous très peu à « cuire au » quelques grands points d'extension pour une utilisation future, même dans un prototype .

Voici un exemple ...

Vous créez un webapp prototype qui inclut la possibilité d'afficher une version imprimer un rapport. Vous devez travailler rapidement, mais ils ont un très bon sentiment les steakholders demanderont la possibilité de l'envoyer par e ainsi la ligne.

Dans votre code Java côté serveur, cacher la connaissance du fait que le rapport est en cours de préparation pour l'imprimante derrière une interface. Créer une classe concrète qui étend l'interface pour maintenir cette responsabilité. Ne pas vraiment en aller et write une version électronique de l'interface, car YAGNI. Mais si vous le faites jamais, vous êtes prêt pour l'ajouter sans carnage à vos fonctions existantes.

Je dirais que si vous commencez par jeter tout bon sens et de faire l'ensemble du projet de la manière la plus expediant possible, alors ce que vous finirez avec un gros tas d'échec ... Ce qui est pas un moyen révolutionnaire (tm).

Si vous voulez vraiment savoir s'il va être utile, faire écran maquettes. Peut-être même juste régulier vieux html codé en dur. Prenez ceux à des clients potentiels et voir si vous pouvez obtenir votre pied dans la porte. Si certains d'entre eux commencent à mordre, puis le buste vos fesses et de le construire.

Il va prendre du temps pour obtenir un contrat en place, obtenir le paiement, et demandez à quelqu'un sur votre personnel des clients réellement commencer à l'utiliser. Alors que ce qui se passe, construire.

Très probablement ce qui va se passer est que les clients potentiels verront votre application et, espérons-le, vous dire pourquoi cela ne fonctionne pas pour eux. Modifiez les maquettes et revenir en arrière. Itérer si nécessaire jusqu'à ce que vous avez un design frontal pour votre produit que quelqu'un est prêt à payer.

Ce que je voudrais faire est:

1) concevoir la prise en compte des bonnes décisions architecturales. Internationalisation et la sécurité sont doivent probablement nantis dans ce cas.

2) Lors du développement, créer les crochets pour ces principes à mettre en œuvre plus tard. Alors, quand vous avez le temps et le budget, vous pouvez les implemente sans faire le remodelage majeur.

3) Ensuite, vous pouvez vous concentrer sur les caractéristiques qui amélioreraient votre mouche application et sont plus importants pour vos clients potentiels.

Je pense que dans ce cas, je serais en utilisant plus de l'approche KISS que « YAGNI extrême » comme vous le suggérez.

À mon avis, YAGNI devrait être suivi par défaut car elle permet stimuler la productivité grandement .

Il y a quelques exceptions, la pensée. Par exemple, si vous développez une bibliothèque 3ème partie, vous avez besoin de penser au moins un peu à l'avance et d'anticiper les besoins des futurs utilisateurs. Cela ne veut pas dire que vous devez renoncer à YAGNI complètement, mais vous ne devriez pas suivre strictement comme avec un développement interne.

Oui, mais ...

Je suis d'accord avec beaucoup de vos considérations sauf le « pas de découplage », parce que le « il » dans YAGNI est synonyme de fonctionnalité, pas pour les étapes de penser. Présentation de quelques abstractions (seulement ceux nécessaires pour le découplage) sera rembourser immédiatement en termes d'erreurs ou d'erreurs ne fait plus rapidement trouvé et enlevé.

Une belle (car il vous permet d'économiser la pensée) façon d'introduire ces abstractions serait utiliser un bon framework web et simplement suivre son application suggérée style structuration .

En avantages sociaux, il serait alors devenu beaucoup plus facile d'ajouter de la sécurité, l'internationalisation, la performance, et d'autres choses de mise à l'échelle plus tard et votre YAGNI-comportement maintenant devrait être raisonnablement sûr.

(Malheureusement, l'argument applique uniquement si vous connaissez le framework web déjà. La connaissance règne dans le royaume YAGNI.)

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow