Comment Commenceriez-Vous?
Si vous étiez développeur dans une équipe Agile, votre seul objectif est d’atteindre les objectifs de sprint. Si c’est le cas, dans 80% des cas, vous réussirez bien en commençant à développer l’interface utilisateur. Parce que cela donne à toute l’équipe une certaine validation et un sentiment de progrès.
Cependant, votre projet parallèle solo ne doit pas compter sur Agile. Vous ne devez répondre à personne sauf à vous-même. Vous devriez d’abord essayer de faire le plus dur. Je parle d’embrasser vraiment la bête.
Pour faire un produit kick-ass, vous auriez invariablement besoin de 1024 choses en plus de résoudre le problème principal. Vous devez être extrêmement conscient de la gestion des dépendances.
Vous devez gérer les utilisateurs car c’est le point d’entrée des données. Les données utilisateur sont et seront votre produit le plus précieux jusqu’au jour où vous décidez de vendre votre entreprise à Facebook ou Google.
Avec cela vient la mise en réseau. Vous vous souvenez de la manipulation des charges utiles? Vous devrez stocker des données hors ligne et les fournir via une intégration d’application mobile / Dropbox, au cas où votre consommateur le plus précieux serait transféré au Groenland ou au Congo.
Et avec cela, comment pourriez-vous oublier le coût associé aux transferts de données? Vous devez définir le protocole qui transporte de manière rentable votre charge utile entre les parties: HTTP, Websockets, TCP (Protobuffers), ou autre chose?
La sécurité des données est la dépendance finale de la chaîne une fois que vous avez défini toutes les autres dépendances (sauf si votre offre principale consiste à résoudre un problème de sécurité).
Comment chiffrez-vous vos données de bout en bout ? SHA ? MD5? Comment allez-vous mettre en œuvre la poignée de main de clé publique-privée?
Si vous connaissez ces termes pertinents, il est facile de rechercher sur GitHub ou de demander des avis sur les forums. Un bon point de départ est de rechercher l’un de ces termes sur Wikipedia et de remonter à partir de là.
En savoir plus sur eux, en savoir plus sur leurs alternatives, et en peu de temps, vous serez un juge expert dans chaque technologie que vous choisirez pour votre projet.
Suivant : Implémentez-les tous. Sans écrire une seule ligne de logique métier, c’est-à-dire.
Assurez-vous de bien lire cela.
En un mot: Gardez-le aussi découplé que possible de votre logique métier. Écrire avec des interfaces, écrire avec des classes / structures abstraites. Faites des talons d’essai en béton pour les tester.
Oui, pour tester tout cela avec primate UI, vous devez écrire quelques cas de test. Les conseils populaires dans les logiciels consistent à commencer par des cas de test, avant d’écrire une ligne de code.
TDD donne des informations sur votre base de code qu’un expert ne peut pas analyser. Vous réaliserez son énorme valeur une fois que vous aurez mis en œuvre l’étape suivante.
Rappelez-vous toujours: Vous pourriez vous tromper ici de mille façons. Mais cette étape est bien plus qu’une leçon.
Le travail effectué ici n’est jamais perdu. Il est réutilisable, car il est indépendant de la logique métier. Lorsque vous détruisez ce projet, n’oubliez pas que vous pouvez toujours réutiliser cette bête pour accélérer tous vos futurs projets. Votre temps de développement diminuera de façon exponentielle.