Tactiques de développement : cycles de développement phoenix

Question

Je me demandais comment vous faites pour développer de grandes applications quand vous êtes votre propre patron. Pour ma part, j'ai appris à la dure la nécessité de la patience et de l'espoir. J'ai travaillé sur l'implémentation d'une application (sous la forme d'une série de scripts liés à une base de données) qui regroupe les articles de Wikipedia en utilisant une combinaison de connaissances des Wikilinks et du texte/contenu des articles. Je m'y emploie depuis deux ans maintenant ; pas encore de résultats.

Je n'arrive pas à obtenir de résultats car je remanie continuellement mes scripts et ma db en raison de changements dans l'essence (pseudo-code, l'algorithme théorique) ou la forme (scripts, threads, tables db, l'algorithme pratique) de l'algorithme. En gros, je me retrouve à apprendre continuellement des erreurs que je découvre lors de la mise en œuvre ; le diable étant dans les détails, les réponses le sont aussi semble-t-il.

De toute façon, à chaque fois que je remanie un script ou un tableau ou autre, je dois mettre au rebut toute ma documentation et script. Je suis maintenant capable de le faire sans crainte, mais cela m'a fait détester la programmation (je déteste les détails).

Je pense que la réingénierie est la voie à suivre puisque je pense à long terme et que je souhaite apprendre rapidement, mais je me demande si vous avez une expérience de programmation similaire ou si vous n'avez jamais vraiment besoin ou choisi d'avoir un meilleur script issu de la mort du dernier (comme un phénix).

La partie la plus difficile pour moi est de gratter ma documentation car je passe plus de temps à documenter qu'à coder ; j'utilise la documentation comme un moyen de discuter des problèmes et d'envisager des solutions ; je l'utilise pour formuler des solutions réalisables. Si ce n'était que pour moi, cela ne me dérangerait pas de la mettre au rebut, mais je l'écris toujours comme si elle devait être publiée la semaine suivante. En effet, en développant un script, je cherche aussi à me développer moi-même ; j'essaie aussi, comme ceux d'entre vous qui participent à ce site web, de partager mes connaissances ou ma sagesse avec les autres.

Quoi qu'il en soit, j'ai développé à pleine vitesse ces deux derniers mois, en réorganisant d'innombrables essais, scripts, tables, etc ; ma patience est à bout car je cherche des résultats.

Des tactiques, de l'aide, des expériences ou des anecdotes que vous souhaitez partager ?

Answer 1

Une bonne devise en matière de programmation est la suivante : "Soyez prêt et heureux de tout jeter au moins une fois", généralement plus. Je suis actuellement en train d'écrire un shell complet à partir de zéro pour un nouveau système d'exploitation et je suis sur le point d'abandonner complètement une partie de la conception, je n'aime pas la façon dont je gère les commandes intégrées par rapport aux commandes modulaires chargeables.

On dirait que vous avez plongé, tête la première excité à l'idée d'écrire du code. D'après ce que j'ai compris, vous avez passé du temps avec du pseudo-code (j'utilise même un grand tableau effaçable à sec) pour déterminer la structure de votre code mais le code n'a pas pu survivre à des changements radicaux de ladite structure.

Il peut y avoir de bonnes raisons pour lesquelles vous travaillez de manière complètement isolée. Si c'est possible, comme d'autres l'ont suggéré, faites appel à quelqu'un d'autre qui comprend le résultat final que vous espérez obtenir et élaborez une nouvelle conception. Gardez à l'esprit que votre application s'est avérée être assez volatile, le nouveau design ne doit pas vous faire tout jeter parce que quelques éléments ont changé.

Je pense que vous êtes également victime de ce que l'on appelle l'optimisation prématurée. Essayez de mettre en place quelque chose qui fonctionne, même si c'est horriblement inefficace et maladroit, puis passez vraiment du temps à regarder comment les choses peuvent être améliorées. Cette étape est presque le précurseur d'une nouvelle conception qui pourrait survivre à des changements radicaux à l'avenir. Si vous ne pouvez pas faire appel à quelqu'un d'autre, une travail modèle de vos erreurs actuelles est presque aussi bon qu'un autre collaborateur.

Answer 2

Tenez un journal de développement ; c'est l'endroit où vous discutez des détails avec vous-même, où vous mettez les choses sur papier, où vous esquissez la documentation, où vous prenez des notes sur les problèmes actuels et futurs, où vous vous rappelez ce que vous avez essayé et ce qu'il vous reste à essayer, etc. C'est aussi une bonne idée de toujours noter ce qu'est la "prochaine chose à faire", afin de ne pas perdre de temps à vous souvenir/réviser quand vous aurez le temps de travailler dessus. Datez chaque entrée.

J'ai utilisé cette approche sur un certain nombre de projets individuels de longue haleine, parfois frustrants, dont la durée varie de quelques mois à plusieurs années, et cela m'aide à rester concentré et à ne pas essayer quelque chose plus d'une fois.

Cela a également éliminé la pression interne de tout documenter, ce qui pourrait vous être très utile.

Pensez-y de la manière suivante : les notes que vous vous faites à vous-même sur ce que vous avez fait vous sont utiles, mais la documentation détaillée destinée à des tiers pour du code qui est mis au rebut est une une perte de temps .

Peut-être que cela aidera vos neurones de documentation TOC à se taire pour que vous puissiez résoudre complètement le problème, puis documenter la solution de travail - au lieu de continuellement re-documenter la dernière prototype .

Answer 3

Comme vous travaillez en solo, essayez d'obtenir un retour d'information de la part de quelqu'un d'autre qui en sait suffisamment pour comprendre ce que vous essayez de faire. Vous serez surpris par les idées que d'autres personnes peuvent proposer.

Lorsque vous travaillez contre rémunération, c'est un peu plus facile car vous devez obtenir l'acceptation de votre client, ce n'est pas aussi ouvert que dans votre situation actuelle.

Answer 4

Je pense que la partie la plus difficile de l'ingénierie logicielle (et non de la programmation en tant que telle) est de trouver le juste équilibre entre le pragmatisme pour que ce soit fait MAINTENANT et pour que ce soit fait RIgHT.

Il y a une tendance parmi les (bons) programmeurs à toujours vouloir démonter les choses et les remonter d'une manière plus nette/plus froide/plus propre/.... C'est une bonne chose ... sauf quand cela signifie que tout se retrouve continuellement en morceaux et que l'objectif insaisissable d'un système fonctionnel (et vraiment propre) s'éloigne.

Pour ma part, je dois me forcer à accepter que quelque chose n'est pas parfait et me contenter d'obtenir un peu de des résultats dans un court laps de temps. La meilleure façon de procéder, à mon avis, est de fixer une série de jalons à court terme qui mènent à l'objectif final. Il faut ensuite s'attacher à respecter ces jalons, même si une autre partie du projet semble plus tentante pendant un certain temps.

Answer 5

Je me demandais comment vous faites pour développer de grandes applications lorsque vous êtes votre propre patron.

J'ai commencé par écrire des pages et des pages et des pages de spécifications fonctionnelles... décrivant à différents niveaux de détail (y compris l'interface utilisateur) ce que je voulais que le logiciel fasse.

J'ai également essayé de minimiser les risques en écrivant quelques prototypes, des composants logiciels de démonstration des éléments les plus risqués ou les moins bien compris.

Quoi qu'il en soit, chaque fois que je réorganise un script ou un tableau ou autre, je dois mettre au rebut tous les ...

Je remanie certainement ce que j'ai écrit (je travaille sur ce sujet depuis 2005), mais uniquement pour ajouter de nouvelles fonctionnalités. Notez que "refactor" est un terme technique (recherchez-le : il existe des livres sur le sujet) : notez que "refactor" n'est pas du tout la même chose que "scrapper" ce que j'ai déjà écrit (au contraire, je le modifie et j'y ajoute).

Je m'y emploie depuis deux ans maintenant ; aucun résultat pour l'instant. ... Quoi qu'il en soit, je me suis développé à pleine vitesse ces deux derniers mois ...

Je ne sais pas quelle est votre expérience en tant que programmeur. À moins que vous ne soyez très expérimenté, certaines options sont :

• Acceptez un projet plus petit (n'espérez pas terminer un projet trop important par vous-même) ... l'effort et les compétences nécessaires pour mener à bien un projet ne sont pas linéaires par rapport à la taille du projet (par exemple, un projet deux fois plus important peut être cinq fois plus difficile à réaliser).

• Commencez, mais ne vous attendez pas à terminer (c'est une occasion d'apprendre dont vous tirerez profit).

• Travailler avec quelqu'un d'autre

• Travaillez plus lentement et méthodiquement (si vous ne faites que 100 mètres, vous pouvez commencer à courir, mais si vous faites 100 kilomètres, vous devez préparer une carte, etc.)

La partie la plus difficile pour moi est de gratter ma documentation car je passe plus de temps à documenter qu'à coder ...

Quelqu'un (pas nécessairement moi) devrait répondre à votre paragraphe, ou peut-être pourriez-vous en dire plus.

Je suis très intéressé par ce sujet (en fait, le produit que je développe sert à documenter le développement de logiciels), mais je ne sais pas quoi répondre à votre paragraphe particulier.