Должен ли я сосредоточиться на качестве кода при быстром прототипировании? - PullRequest
3 голосов
/ 11 марта 2010

Когда вы занимаетесь быстрым созданием прототипов для функций, стоит ли вам действительно беспокоиться о качестве и оптимизации кода?

Ответы [ 5 ]

5 голосов
/ 11 марта 2010

Если вспомнить, сколько раз «прототип» становился продуктом, ответ был бы «да».

Не забывайте, что вы не только создаете прототип, но и разрабатываете макет.

2 голосов
/ 11 марта 2010

Да к качеству. Нет оптимизации. Этот вопрос должен составить сообщество вики.

0 голосов
/ 12 марта 2010

Да. Сосредоточьтесь на качестве, ясности и простоте И комментариях, чтобы объяснить, что он делает и почему (не беспокойтесь о том, как, если это действительно сложно, для этого и нужен код).

Практически вся наша работа здесь начинается с того, что если? И если это работает, мы продолжаем с этим.

Мы пишем комментарии, описывающие, что должно произойти, прежде чем писать код, затем пишем код, соответствующий комментариям. Написание комментариев сначала заставляет задуматься о том, как вы все это структурируете. Мы обнаружили, что это предотвращает множество ложных предположений и фактически ускоряет разработку.

Это также значительно упрощает повторное использование, когда вы возвращаетесь к нему - вам не нужно читать код и понимать его, просто читайте комментарии. Не занимайтесь бессмысленным самодокументированным кодом, все, что делает, это самодокументирует ошибки, вам нечего проверять, соответствует ли код комментариям / документации.

Вы можете позаботиться об оптимизации позже - посмотрите это описание огромного выигрыша , который я получил, переключившись с MFC CMaps на STL при работе над хобби-проектом, анализирующим некоторые файлы журнала Apache. Это было сделано после того, как у меня была начальная концепция, и только когда стало очевидно, что есть проблема с производительностью.

0 голосов
/ 11 марта 2010

Если качество и оптимизация являются требованиями к прототипу, тогда да. Если нет, то нет. Просто потому, что вы делаете быстрое создание прототипа, вы не оставляете стандартные рабочие процедуры, такие как программирование, на спецификацию, используя контроль исходного кода, тестирование и т. Д. Возможно, для высокопроизводительной системы довольно необычно быть требованием для быстро развивающегося прототипа, но это другое дело.

0 голосов
/ 11 марта 2010

Я бы сосредоточился на ясности.

...