Leave a comment

Comments 16

levgem June 12 2010, 06:04:00 UTC
Чем-то напомнило ситуацию с erlyvideo. Его развитие осложняется отсутствием заранее юзкейсов в силу тотальной закрытости всех протоколов и реализаций.

Т.е. пробуем что-то делать, пока байты не начинают идти в нужном порядке, потом думаем как отрефакторить. Приходит новая задача, думаем какие ещё могут быть, рефакторим так, что бы им тоже удовлетворить.

Reply


alexis_m June 12 2010, 20:31:12 UTC
«PoC прототипов»?

Reply

gaperton June 12 2010, 20:51:44 UTC
Proof of the Concept прототипов.

Reply


nikaan June 13 2010, 09:42:26 UTC
а правда ли что итоговая картинка собирается в голове только у одного человека - который и является ответственным далее за дизайн? Т.е. обсуждают-то все, но итогом является один человек, который всё понимает.

Reply

gaperton June 15 2010, 10:33:48 UTC
Если ничего специально не предпринимать - так и получится.

И это - очень плохо. Ибо, практически сводит все на дерьмо. Люди не смогут хорошо реализовать то, что они толком не понимают.

Общее видение несложно донести до группы людей посредством семинаров. Большая группа не может эффективно придумывать одну штуку. Зато - она в состоянии эффективно находить косяки в придуманном.

Поэтому проектирование подсистемы хорошо поручать паре инженеров (два человека в состоянии эффективно общаться, и могут быть вместе продуктивнее, чем поодиночке) , введа групповые design review в формате семинара, на которых широкая аудитория будет находить проблемы.

Таким образом, можно обеспечить и эффективность процесса проектирования, и поиск ошибок, и - знакомство с концепциями широкой аудитории.

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

Здесь особо ничего изобретать не надо - все, в общем, украдено до нас.

Reply

nikaan June 15 2010, 22:08:33 UTC
"И это - очень плохо. Ибо, практически сводит все на дерьмо. Люди не смогут хорошо реализовать то, что они толком не понимают ( ... )

Reply

gaperton June 15 2010, 22:57:05 UTC
> По крайней мере у математиков всё по-другому. Работа преимущественно индивидуальная. И нет такого, что кто-то главнее и кто-то что-то кому-то должен объяснить ( ... )

Reply


ekr June 13 2010, 18:01:48 UTC
>Также, хорошей проверкой является попытка закодировать непонятный кусок кода в соответствии с дизайном.

Если идею развить, это не TDD случаем?

Reply

gaperton June 15 2010, 10:37:32 UTC
Нет конечно. TDD предполагает написание тестов вперед. Как минимум - _проектирование_ тестов вперед (т.е. разработка программы и методики испытаний) - это очень хорошая и полезная практика.

Но предварительного проектирования она заменяет. Как пример - TDD является существенным компонентом XP, которое в принципе игнорирует предварительное проектирование. Оно целиком построенно на посылке, что переделать потом дешевле, чем подумать наперед.

Reply

ekr June 15 2010, 15:00:06 UTC
Что такое TDD, думаю, более-менее все себе представляют.
Я хотел своим вопросом уточнить Вашу идею - мне показалась схожесть с TDD в том, что test-first заставляет заранее (до кодирования реализации) проектировать API этого кода, что частично коррелирует с задачей:

>в ходе его печатания будут выявлены ошибки дизайна

Исчерпывающий ответ получен. Спасибо ))

Reply

gaperton June 15 2010, 10:39:44 UTC
И кроме того, в цитируемом абзаце я предлагаю писать набросок кода, и ни в коем случае его не тестировать и не отлаживать. Потому, что он пишется для нахождения ошибок дизайна.

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

Reply


shashwat_isenh July 10 2010, 01:50:21 UTC
gaperton; фигасе

Reply

gaperton July 10 2010, 16:29:09 UTC
Ась?

Reply


Leave a comment

Up