Comment aborder quelque chose de complexe?

Question

Vous connaissez cette partie de votre code qui est essentielle pour le projet, mais cela prendra probablement beaucoup de temps? Avez-vous déjà le sentiment de préférer travailler sur autre chose (probablement moins important) ou ne pas coder du tout plutôt que de travailler sur cette partie? Vous essayez si dur d'éviter cette bête et d'utiliser tous les trucs paresseux que vous connaissez pour retarder son implémentation inévitable?

Maintenant, je suis probablement juste paresseux, mais j'ai toujours eu à traiter avec un code comme ça. Ecrivez quelque chose que je n'ai pas envie d'écrire (et c'est pire si vous le faites pour le plaisir et pour ne pas être payé!). Un grand système qui mettra beaucoup de temps à arriver à une étape où vous obtiendrez des résultats utiles ou une indication de son bon fonctionnement. Comment commencez-vous à coder quelque chose comme ça? La plupart des gens suggéreraient probablement le diviser pour régner et des techniques architecturales similaires, mais ce n’est pas comment vous le faites. il s'agit de la façon dont vous commencez à le faire. Quelles sont les toutes premières étapes que vous feriez?

Answer 1

Je vais raconter l'histoire d'un cas dans lequel cela m'est arrivé.

Je voulais implémenter un nouvel algorithme de décision de type de trame pour x264 qui utilisait la programmation dynamique en aval (algorithme de Viterbi). Mais ça allait être compliqué, en désordre, moche, etc. Et je ne voulais vraiment pas le faire. J’ai essayé de lancer le projet sur Google Summer of Code, mais par malchance, l’un des étudiants que nous avons eu qui a tout simplement renversé son projet ... c’est celui qui a choisi ce projet.

Ainsi, après deux mois de plainte et d’évitement, j’ai finalement pu travailler sur l’algorithme. Et voici comment je l’ai fait.

Tout d’abord, j’ai parlé à l’autre développeur, qui apparemment avait déjà quelques idées sur la façon de procéder. Nous en avons parlé et il me l'a expliqué jusqu'à ce que je comprenne parfaitement le processus d'un point de vue algorithmique. C’est la première étape de tout projet de ce type: comprenez si bien l’algorithme sous-jacent que vous pouvez tout pseudocoder.

Ensuite, j'ai parlé à un autre de mes collègues. Nous sommes allés vers un tableau blanc et je l'ai esquissé jusqu'à ce qu'il le comprenne aussi. En l'expliquant à quelqu'un d'autre, j'ai appris à me comprendre moi-même. Deuxième étape: expliquez si bien l’algorithme à quelqu'un d'autre que ils peuvent le pseudocoder. Il s’agit d’une émulation du processus de programmation, car la programmation est une forme "d’explication". un algorithme à l'ordinateur.

Ensuite, j’ai écrit un prototype Java simple qui utilisait de fausses valeurs arbitraires pour la fonction de coût et n’était utilisé que pour tester la recherche Viterbi. Je l'ai terminé et vérifié par rapport à une recherche exhaustive - il correspondait parfaitement. Ma programmation dynamique était correcte. C’est la troisième étape: écrire la forme la plus simple possible de l’algorithme dans l’environnement le plus simple possible.

Ensuite, je l'ai porté en C, la langue maternelle de x264. Cela a fonctionné encore. Il s’agit de la quatrième étape: transférez cette forme simple de l’algorithme à l’environnement complet.

Enfin, j'ai finalement remplacé la fonction de coût factice par la fonction réelle. Après quelques recherches et réparations, cela a fonctionné. C'est la dernière étape: intégrer complètement l'algorithme à l'environnement.

Ce processus a pris à peine une semaine, mais du point de vue de moi au début du projet, c’était complètement décourageant et je ne pouvais même pas me lancer, même en le décomposant en une telle étape. étape par étape, j’ai pu non seulement le faire faire , mais le faire beaucoup plus rapidement que prévu.

Et les avantages allaient bien au-delà de x264; Je comprends maintenant si bien Viterbi que je peux maintenant l'expliquer aux autres ... et que les autres peuvent en bénéficier grandement. Par exemple, l’un des développeurs de ffmpeg utilise une adaptation de mon algorithme et de son code pour résoudre de manière optimale un problème quelque peu différent: le placement optimal des en-têtes dans les fichiers audio.

Answer 2

En général, j'aime la grande partie complexe. Ce sont en réalité les parties qui posent un défi et me forcent à réfléchir à ce que je fais. Ce sont tous les petits morceaux fastidieux que je n'aime pas. Cependant, quand il s'agit de faire quelque chose que j'ai retardé, je trouve un simple conseil important:

FAIS-LE !!!

Sérieusement, une fois que c'est commencé, c'est beaucoup plus facile à finir. Je trouve toujours que je remets les choses jusqu'à ce que je les commence, puis tout à coup je trouve que, maintenant que j'ai commencé, ce n'est pas aussi grave que je l'avais imaginé, et regardez, c'est déjà presque fini!

Answer 3

Diviser pour régner ne consiste pas uniquement en une structuration de code, cela fonctionne également comme une approche permettant de gérer un projet de manière conceptuelle. Si j'ai de la difficulté à démarrer un projet, c'est presque toujours parce que c'est trop gros et effrayant . En se divisant en éléments conceptuellement gérables, cela devient moins effrayant.

Je crois aussi aux " puces de suivi " comme décrit par les programmeurs pragmatiques. Réduisez le projet au plus simple possible "validation du concept". des parties centrales, par ex. sans interface utilisateur, cas spéciaux, traitement des erreurs, etc. Peut-être que ce n'est que quelques routines de base avec des tests unitaires associés. Avec cela, vous avez conquis les parties les plus effrayantes et pouvez construire à partir du noyau.

En gros, le truc pour commencer (pour moi du moins) est la suivante: ne commencez pas le projet dans son ensemble. Commencez par une petite partie (de préférence centrale) et construisez à partir de là. Si j’ai toujours encore des difficultés à démarrer, c’est parce que la petite partie que j’ai choisie est encore trop grande, je dois donc la diviser et la réduire davantage.

Answer 4

Je suis d’accord avec vous pour dire qu’un grand nombre de parties importantes et importantes d’un logiciel ne sont pas amusantes à écrire. Je commence généralement ma journée de développement par quelques petites choses, comme ajouter une fonctionnalité ici ou réparer un bogue ici. Quand le moment est venu, je commence par la grande partie, mais quand je ne peux plus voir la chose, je fais quelque chose de différent. Tout va bien si vous avez encore tout fait à temps. Et rappelez-vous que cela peut vous faciliter la tâche si vous parlez de cette grande bête à d'autres personnes avant de le faire, pendant et après votre travail. Cela libérera non seulement votre esprit, mais vous obtiendrez également l'opinion des autres d'un point de vue moins subjectif. Planifier de telles choses ensemble est également utile.

Answer 5

C'est drôle, je suis l'inverse. Quand je commence à m'attaquer à un problème, je commence par les grands. Le cœur du problème est généralement ce qui m’intéresse.

Si je fais un projet pour moi-même, je n'ai généralement pas la peine d'implémenter tous les éléments flous autour du bord, afin qu'ils ne soient jamais terminés. Si je fais quelque chose de réel, j'arrive finalement à toutes les difficultés, mais ce n'est pas ma partie préférée.

Answer 6

Je pense qu'il y a deux problèmes ici.

La première étape consiste en réalité à démarrer. Comme vous le dites, cela peut être assez délicat. Personnellement, je commence tout simplement par quelque chose, juste pour avoir quelque chose sur papier / écran. Ce sera probablement une erreur et nécessitera une édition, mais en général, il est plus facile de critiquer que de créer, même sur votre propre travail.

Ensuite, il y a le processus actuel de résolution de problèmes difficiles. Il y a un excellent livre intitulé "Conceptual Blockbusting". qui traite de différentes façons d'aborder les problèmes. J'ai beaucoup appris sur la façon dont j'aborde la résolution de problèmes et mes angles morts avec ce livre. Fortement recommandé.

Answer 7

J'essaie de créer une métaphore de ce que le système tente de faire. Je me sens toujours plus à l'aise lorsque je peux décrire le comportement en termes de métaphore.

Je l’aborde ensuite du point de vue du développement axé sur les tests, c’est-à-dire que je commence à décrire ce que le système doit faire en configurant les tests permettant de vérifier le comportement correct.

HTH.

acclamations,

Rob

Answer 8

La partie la plus difficile du projet va de n'avoir rien fait à la première ligne. Il suffit de mettre quelque chose sur papier pour lancer ce processus et c'est incroyable de voir à quelle vitesse le reste peut s'écouler d'ici.

Je suis un partisan de la " de la division et de la conquête . moi même.

Lorsqu'il y a une tâche particulièrement lourde dans un système qui pèse sur moi, je quitte l'ordinateur, prends un crayon et un papier, et la décompose en l'ensemble de ses composants logiques et de son flux de travail.

Prenez ensuite chacune de ces tâches et décomposez-les en fonctions / appels les plus élémentaires requis.

Je peux ensuite mettre en place des méthodes stub dont je pense avoir besoin. et les étaler un à un. À ce stade, chacune de ces "sous-tâches" n’est pas plus grande que les tâches de développement plus petites gravitant autour du même projet, alors sentez-vous comme une tâche beaucoup moins onéreuse qui pèse sur moi.

Answer 9

Je règle habituellement ce genre de problèmes à la maison en utilisant un stylo et un morceau de papier. J'imagine l'algorithme et / ou le flux logique, puis stub (sur le papier!) les stub de classe et de méthode et quand je rentre devant un / l'ordinateur, je peux le faire beaucoup plus facilement ... C'est probablement juste moi ..