Dois-je m'inquiéter si je résout un grand nombre de mes problèmes de la même manière?

J'apprécie vraiment les jeux de programmation et les créateurs / jeux de puzzle. Je me retrouve à concevoir un grand nombre de ces problèmes de la même manière et, finalement, à utiliser une technique similaire pour les programmer avec laquelle je suis vraiment à l'aise.

Pour vous donner un bref aperçu, j'aime créer des graphiques où les nœuds sont représentés avec des objets. Ces objets contiennent des données telles que des coordonnées, des positions et bien sûr des références à d'autres objets voisins. Je vais les placer tous dans une structure de données et prendre des décisions sur ces informations dans une "boucle de jeu".

Bien que ce soit un bref exemple, ce n'est pas exact dans toutes les situations. C'est juste une façon avec laquelle je me sens vraiment à l'aise. Est-ce mauvais?

Non ça va.

Le but de la programmation pratique est de trouver des solutions qui pourraient être utiles dans de nombreux développements similaires. Vous venez d'en trouver un.

Vous ne pouvez pas et ne devez pas créer des solutions différentes juste pour le plaisir d’être différentes. Mais vous devez certainement avoir un regard critique sur vos solutions à chaque fois et vous demander si elles sont toujours bonnes ou peut-être que l'industrie a progressé depuis et que vous devez vous aligner en conséquence.

Si cela fonctionne bien, appelez-le un modèle de conception. Si ce n'est pas le cas, mais que vous ne savez pas mieux, c'est l'anti-modèle du marteau d'or.

De façon réaliste, dans nos emplois de jour, nous avons tendance à poser un bon nombre de problèmes assez similaires.

Dans ces situations, s'en tenir à ce que vous savez peut être bon. J'ai vu plus d'exemples de mauvaises solutions de personnes implémentant quelque chose qu'ils ne comprenaient pas que quelqu'un utilise bien une technique non idéale.

Si vous connaissez bien quelque chose, il est probable que vous puissiez l'adapter au besoin et que votre mise en œuvre soit solide et efficace. Ces choses ne seront probablement pas vraies dès vos premières tentatives de nouvelles techniques.

Mais le revers de la médaille est que si tout ce que vous avez est un marteau, tout ressemble à un clou. Vous devriez faire des choses pour vous rendre conscient des alternatives et quand vous poussez peut-être trop loin vos favoris.

Peut-être choisir quelques changements non urgents / non critiques et les utiliser pour se mettre au courant des solutions alternatives?

Bonne question, et je dois admettre que c'est quelque chose qui me hante aussi.

Quand est-ce bien? Faites une analyse des performances de votre code - si vous voyez que vous êtes dans O (log n) ou O (n) ou O (n log n) et que le problème est donc mappable à des structures de données connues, vous êtes généralement d'accord.

Quand est-ce que ça ne va pas? La complexité de votre temps ou de votre espace est O (n ^ 2) ou pire, ou le problème par définition est NP complet. Dans ces situations, vous devez appliquer un peu d'heuristique, appliquer des connaissances d'autres domaines, etc.

Exemple rapide: dans la conception de puces, choisir comment organiser les portes dans le circuit pour une puissance minimale est NP-complet. Seuls les graphiques ne vous feront pas beaucoup de bien même si c'est un besoin indispensable. Vous devez lire du matériel supplémentaire, souvent interdisciplinaire et appliquer les connaissances dans votre domaine. Par exemple, les algorithmes génétiques (algorithmes qui imitent les croisements génétiques et les mutations, tels que définis dans la biologie 101) ont beaucoup d'application dans la conception de puces matérielles.

Pas nécessairement, si c'est un bon moyen de les résoudre :)

Habituellement, lorsque je travaille sur une "solution", je choisis ces choses dans l'ordre:

• simplicité ,
• réutilisabilité ,
• et seulement la dernière représentation .

Ce n'est pas que les performances ne comptent pas: je conçois en pensant aux performances, mais sans aller trop loin (donc si je dois faire des appels à une méthode utilitaire comme StringUtils.isEmpty ou quelque chose comme ça dans le même flux, j'ai gagné '' t esprit). Si des performances sont alors nécessaires (analyse de rentabilisation ou problème d'expérience utilisateur), je choisis une approche différente de celle simple et réutilisable. Être pragmatique.

Curieusement cependant, lors du codage en C, je me soucie beaucoup plus des performances que lors du codage en Java ... Force d'habitude :))

Tant que le problème est résolu de manière efficace, il n'y a pas lieu de s'inquiéter.

Je pense que le graphique est une conception appropriée pour concevoir des jeux pour représenter les décisions \ choix. Gardez juste à l'esprit que cela peut probablement être affiné et rendu plus efficace, et ce n'est peut-être pas la meilleure solution pour d'autres domaines.

Si cela fonctionne, c'est OK.

Si vous craignez de vous fier à une seule technique, essayez comme exercice de trouver des variantes de certains problèmes résolus qui rendraient votre solution irréalisable. Points supplémentaires si vous pouvez généraliser les modifications pour définir l'espace d'applicabilité de votre processus habituel.

Si vous résolvez le problème, c'est bien. Et peu importe de quelle manière jusqu'à ce que cela ne pose plus de problèmes.

"Developer Art" a en fait la bonne réponse si votre objectif est de produire un produit. Et si votre "usine" fabrique des produits qui satisfont alors cool.

Mais...

Si jamais vous voulez apprendre de nouvelles façons de faire (et potentiellement de meilleures), vous devez changer les choses. Cela produira des échecs, mais ce n'est que par l'échec que l'on apprend réellement. Et grâce à ce nouvel apprentissage, vous pourrez peut-être produire un logiciel encore meilleur et plus convaincant.

Ceci est en fait étayé par la recherche neurologique. Alors voilà.