Lorsque vous faites du prototypage rapide pour les fonctionnalités, vous devez vraiment vous soucier de la qualité du code & optimisation ?.Dois-je me concentrer sur la qualité du code pendant le prototypage rapide?
Je voudrais mettre l'accent sur la clarté.
Oui à la qualité. Non à l'optimisation. Cette question devrait être wiki communautaire.
En repensant au nombre de fois qu'un «prototype» a fini par devenir le produit, la réponse serait oui. N'oubliez pas que vous ne faites pas que prototyper la fonction, vous prototypez également la conception.
Si la qualité et l'optimisation sont des exigences pour le prototype alors oui. Si non, alors non. Tout simplement parce que vous faites du prototypage rapide, vous n'abandonnez pas les procédures d'exploitation standard comme la programmation à une spécification, le contrôle de code source, les tests, etc. Il est peut-être relativement inhabituel qu'une haute performance soit requise pour un prototype rapidement développé. mais c'est une autre affaire.
Oui. Mettre l'accent sur la qualité, la clarté et la simplicité ET les commentaires pour expliquer ce qu'il fait et pourquoi (ne pas déranger avec le comment, à moins que ce soit vraiment compliqué, c'est ce que le code est pour).
À peu près tout le travail que nous faisons ici commence comme un quoi? Et si cela fonctionne, nous continuons avec cela.
Nous écrivons des commentaires décrivant ce qui doit se passer avant d'écrire le code, puis nous écrivons le code correspondant aux commentaires. Écrire les commentaires vous oblige d'abord à réfléchir à la façon dont vous allez tout structurer. Nous avons constaté que cela évite beaucoup de fausses hypothèses et rend le développement plus rapide.
Cela rend également la réutilisation lorsque vous y revenez beaucoup plus facilement - vous n'avez pas besoin de lire le code et de le comprendre, il suffit de lire les commentaires. N'y allez pas pour le non-sens du code auto-documenté, tout ce que fait c'est auto-documenter les bugs, vous n'avez rien à vérifier pour voir si le code correspond aux commentaires/documentation du tout.
Vous pouvez vous soucier de l'optimisation plus tard - voir cette description d'un huge win J'ai obtenu en changeant de MFC CMaps en STL lorsque vous travaillez sur un projet passe-temps d'analyse des fichiers journaux Apache. Cela a été fait après que j'ai eu le concept initial de travail et seulement quand il est devenu évident qu'il y avait un problème de performance.
Je suis d'accord. Si pour rien d'autre le faire pour la pratique. –
Peut-être que si c'est un prototype officiel, mais si vous êtes en train de baiser avec des idées juste pour partager avec des collègues, Comme je blog sur [ici] (http://www.opensourceconnections.com/2013/01/11/code-quality -is-a-dial-too /) Je ne suis pas si sûr que ça compte. Il est vraiment facile de s'énerver sur la qualité du code et de perdre de vue l'idée que vous essayez de prouver à vous-même/autres. –