Объяснение концепции: делает ли код на раннем этапе его понятнее? - PullRequest
3 голосов
/ 09 июля 2010

Думаю, это вопрос, который может заинтересовать многих, поэтому, пожалуйста, обсудите!: -)

Теперь представьте, что вы хотите показать людям, с которыми вы работаете, с концепцией будущего развития (например, новым продуктом или новой технологией, которую вы хотите внедрить).

Имеет ли смыслчтобы показать код рано или вы бы сначала пошли с PPT?Или что бы вы порекомендовали?

Ответы [ 7 ]

4 голосов
/ 09 июля 2010

+ 1 для Стейна, потому что на самом деле это все, что имеет значение.

Но это действительно зависит от того, что вы делаете.Какова ваша «концепция»?

  • API (например, mapreduce)?

Покажите код API, не тратьте время людей на реализацию кода,это не важно - «эй, посмотри, как я перебираю твой ввод! это так умно!».Нету.Никому нет дела.Если ваш API замечательный, он привыкнет, никого не волнует, насколько хитрым является код, чтобы заставить его работать.

  • Продукт (например, facebook)?

Показатькод?Никому нет дела.Даже Facebook не заботится (если они это сделали, зачем им использовать php? Я шучу!).Удивите их демонстрацией полузаполненного прототипа, который делает несколько вещей плохо, но показывает, насколько он хорош.

  • Сама реализация (например, новая подпрограмма std::sort)?

Многим людям может быть интересно увидеть внутренности.Особенно люди на ТАК.Итак, опубликуйте код или технический документ, когда у вас что-то получится.Это не «мой клон в твиттере будет милым, посмотри, насколько крута моя TruncateTo140Chars() функция!».С другой стороны, вы можете получить быстрый отзыв о подходе вашей новой реализации, показав свой алгоритм (в коде или псевдокоде).Вы можете показать тесты, которые лучше, чем «этот код должен быть быстрее, потому что я делаю на один меньше сравнения с нулем».


Пожалуйста, просто прототип, получите что-то демонстрационное, что ваши пользователи будут забота о.Заботьтесь о коде, только если это то, что хотят видеть ваши пользователи (обычно это не так).

3 голосов
/ 09 июля 2010

Мне нравится бездарный подход доказательства концепции. Просто сбросьте их с ног и докажите, что это работает.

1 голос
/ 09 июля 2010

Покажите клиентам / заинтересованным сторонам прототипы на ранних этапах и позже просмотрите код среди коллег.

Владельцы кола контролируют, какую функциональность вы хотите предоставить (раннее выяснение этого является ключом к получению чего-то выгодного / полезного).

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

1 голос
/ 09 июля 2010

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

1 голос
/ 09 июля 2010

Если это действительно не технические люди, то я обнаружил, что бумажные модели прекрасно работают. Люди боятся критиковать, когда они закодированы, гораздо проще (и дешевле) отказаться от бумажной модели, чем от реальной вещи.

Когда вы показываете концепцию веб-сайта / приложения для не технаря, рисуйте разные страницы, диалоги входа и т. Д.

Когда вы показываете концепцию коллеге-разработчику (если он просто его не понимает), нарисуйте разные классы на бумаге и покажите отношения. Здесь может быть полезен UML, если вы оба знаете синтаксис.

Иначе, если бы у вас было время, я бы сказал, сразите их полной реализацией: -)

1 голос
/ 09 июля 2010

Я не верю, что очень полезно показывать ваш код раньше.«Мы» технические специалисты всегда рады показать наши новые технические детали и идеи.Тем не менее, люди, использующие продукты и технологии, заинтересованы только в том, что они могут сделать с ним.Они часто не разделяют ваш энтузиазм в отношении техник, в данном случае кода.

Мой совет - придерживаться более общего подхода, объяснить, почему он полезен и как он сделает их жизнь лучше.Чтобы добавить автомобильную аналогию: люди хотят знать, сколько у него лошадиных сил, а не как работает двигатель внутреннего сгорания!

Эти детали реализации могут быть интересны вашим коллегам!

1 голос
/ 09 июля 2010

Это зависит от аудитории и характера продукта.Если аудитория и / или продукт считаются «техническими», подумайте о представлении кода.Тем не менее, вы должны сделать это неотъемлемой частью презентации, а не всей.

...