Я думаю, это вопрос, который может заинтересовать многих, поэтому, пожалуйста, обсудите! :-)Объяснение концепции: показывает ли код раньше, чтобы он стал понятнее?
Теперь представьте, что вы хотите показать людям, с которыми вы работаете, концепцию будущего развития (например, новый продукт или новую технологию, которую вы хотите представить).
Имеет ли смысл показывать код раньше или вы бы сначала пошли с PPT? Или что бы вы порекомендовали?
+1 к Stijn, потому что действительно, это все, что имеет значение.
Но это действительно зависит от того, что вы делаете. Какова ваша «концепция»?
Показать код API, не тратьте время на людей с кодом реализации, это не важно - «эй, посмотри, как я перебираю ваш вход, это так умно!». Неа. Никто не заботится. Если ваш API замечательный, он будет использоваться, никто не заботится о том, насколько жестоко это сделать, чтобы заставить его работать.
Показать код? Никто не заботится. Даже фейсбуки не заботятся (если они это сделали, зачем им использовать php? Я, малыш!). Ударьте свой ум демо-версией полуполного прототипа, который делает несколько вещей плохо, но показывает, насколько это здорово.
std::sort)?Многим людям может быть интересно увидеть внутренности. Особенно люди на SO. Итак, опубликуйте код или технический документ, когда вы получите что-то работающее. Это не «мой твитер-клон, который будет милым, посмотрите, как классная моя функция TruncateTo140Chars()!». С другой стороны, вы можете быстро получить отзывы о своем подходе к новой реализации, указав свой алгоритм (в коде или псевдокоде). Вы можете показать тесты, которые лучше, чем «этот код должен быть быстрее, потому что я делаю меньше сравнения с нулем».
Пожалуйста, только прототип, получить что-то demo'd, что ваши пользователи будут уход о. Только беспокоитесь о коде, если это то, что ваши пользователи хотят видеть (обычно это не так).
Мне нравится подход без доказательств к концепции. Просто сдуйте их с ног и докажите, что это работает.
Это зависит от аудитории и характера продукта. Если аудитория и/или продукт считаются «техническими», чем рассматривать представление кода. Однако вы должны сделать его неотъемлемой частью презентации, а не всего.
Я не верю, что это очень полезно, чтобы показать свой код раньше. «Наши» технические люди всегда с гордостью демонстрируют наши новые технические детали и идеи. Тем не менее, люди, использующие продукты и технологии, интересуются только тем, что они могут с этим сделать. Они часто не разделяют ваш энтузиазм методов, в этом случае код.
Мой совет - придерживаться более общего подхода, объяснить, почему он полезен и как он улучшит свою жизнь. Чтобы добавить автомобиль-аналогию: люди хотят знать, сколько лошадиных сил у него есть, а не как работает двигатель внутреннего сгорания!
Эти детали реализации, однако, могут быть интересны вашим коллегам!
Если это действительно не технологические люди, то я обнаружил, что бумажные модели отлично работают. Люди боятся критиковать, когда они были закодированы, гораздо проще (и дешевле) отказаться от бумажной модели, а затем и реальной.
Когда показывающая концепцию сайта/приложение к не технологиям, рисовать различные страницы, Логин диалоги и т.д.
При показе концепции к разработчику собрата (если он просто не получить) нарисовать разные классы на бумаге и показать отношения. UML может быть полезен здесь, если вы знаете синтаксис.
Иначе, если у вас есть время, я бы сказал, взорвать их прочь с полной реализацией :-)
Я согласен с rtalbot. Если аудитория нетехническая, возможно, будущие пользователи или ваш босс, я бы пошел с некоторыми диаграммами. Возможно использование случаев. Покажите им, что вы можете с этим сделать. Если он маленький, а ваши друзья боятся, подпишите демо-версию дыма и зеркал.
Покажите клиентам/держателям акций прототипы на ранней стадии и затем просмотрите код среди сверстников.
Держатели ставок контролируют, какую функциональность вы хотите доставить (обнаружение этого на раннем этапе является ключом к доставке чего-то прибыльного/полезного).
Но для повышения качества кода, обзоры кода чрезвычайно эффективны, если сделать это в нужное время. Мой опыт заключался в том, что выполнение этого к концу итерации обеспечивает большую часть банка для доллара. Ваш пробег может варьироваться в зависимости от оптимального времени для выполнения проверки кода (младшие разработчики должны просматривать ранние и часто, старшие разработчики обычно хорошо до конца).
Ох, но не код 'производства'. :/ – rtalbot
А? Если вы собираетесь представить код, почему бы не представить материал, который находится в производстве? – Stephen
Потому что это «концепция» для «будущего развития». Вызов этого «производства» означает, что он закончен. Даже если у вас есть код и показать его - не называйте его производством. Это по-прежнему концепция по причине, верно? Если вы являетесь «издательским» кодом, тогда определенно покажите этот код, но это немного другой сценарий, чем представлен OP. – rtalbot