Чем-то напомнило ситуацию с erlyvideo. Его развитие осложняется отсутствием заранее юзкейсов в силу тотальной закрытости всех протоколов и реализаций.
Т.е. пробуем что-то делать, пока байты не начинают идти в нужном порядке, потом думаем как отрефакторить. Приходит новая задача, думаем какие ещё могут быть, рефакторим так, что бы им тоже удовлетворить.
а правда ли что итоговая картинка собирается в голове только у одного человека - который и является ответственным далее за дизайн? Т.е. обсуждают-то все, но итогом является один человек, который всё понимает.
Если ничего специально не предпринимать - так и получится.
И это - очень плохо. Ибо, практически сводит все на дерьмо. Люди не смогут хорошо реализовать то, что они толком не понимают.
Общее видение несложно донести до группы людей посредством семинаров. Большая группа не может эффективно придумывать одну штуку. Зато - она в состоянии эффективно находить косяки в придуманном.
Поэтому проектирование подсистемы хорошо поручать паре инженеров (два человека в состоянии эффективно общаться, и могут быть вместе продуктивнее, чем поодиночке) , введа групповые design review в формате семинара, на которых широкая аудитория будет находить проблемы.
Таким образом, можно обеспечить и эффективность процесса проектирования, и поиск ошибок, и - знакомство с концепциями широкой аудитории.
Примерно так организованы исследовательские спецсеминары у ученых. И любой человек, обучавшийся в университетах и защитивший диплом, с этой системой должен быть знаком.
Здесь особо ничего изобретать не надо - все, в общем, украдено до нас.
> По крайней мере у математиков всё по-другому. Работа преимущественно индивидуальная. И нет такого, что кто-то главнее и кто-то что-то кому-то должен объяснить
( ... )
Нет конечно. TDD предполагает написание тестов вперед. Как минимум - _проектирование_ тестов вперед (т.е. разработка программы и методики испытаний) - это очень хорошая и полезная практика.
Но предварительного проектирования она заменяет. Как пример - TDD является существенным компонентом XP, которое в принципе игнорирует предварительное проектирование. Оно целиком построенно на посылке, что переделать потом дешевле, чем подумать наперед.
Что такое TDD, думаю, более-менее все себе представляют. Я хотел своим вопросом уточнить Вашу идею - мне показалась схожесть с TDD в том, что test-first заставляет заранее (до кодирования реализации) проектировать API этого кода, что частично коррелирует с задачей:
>в ходе его печатания будут выявлены ошибки дизайна
И кроме того, в цитируемом абзаце я предлагаю писать набросок кода, и ни в коем случае его не тестировать и не отлаживать. Потому, что он пишется для нахождения ошибок дизайна.
Общее правило - если вы можете без проблем написать кусок кода до конца - его не надо даже пытаться писать на этапе дизайна. Чтобы поймать ошибку дизайна - надо попытаться закодировать то, что не особо понятно, как вообще выглядеть будет.
Comments 16
Т.е. пробуем что-то делать, пока байты не начинают идти в нужном порядке, потом думаем как отрефакторить. Приходит новая задача, думаем какие ещё могут быть, рефакторим так, что бы им тоже удовлетворить.
Reply
Reply
Reply
Reply
И это - очень плохо. Ибо, практически сводит все на дерьмо. Люди не смогут хорошо реализовать то, что они толком не понимают.
Общее видение несложно донести до группы людей посредством семинаров. Большая группа не может эффективно придумывать одну штуку. Зато - она в состоянии эффективно находить косяки в придуманном.
Поэтому проектирование подсистемы хорошо поручать паре инженеров (два человека в состоянии эффективно общаться, и могут быть вместе продуктивнее, чем поодиночке) , введа групповые design review в формате семинара, на которых широкая аудитория будет находить проблемы.
Таким образом, можно обеспечить и эффективность процесса проектирования, и поиск ошибок, и - знакомство с концепциями широкой аудитории.
Примерно так организованы исследовательские спецсеминары у ученых. И любой человек, обучавшийся в университетах и защитивший диплом, с этой системой должен быть знаком.
Здесь особо ничего изобретать не надо - все, в общем, украдено до нас.
Reply
Reply
Reply
Если идею развить, это не TDD случаем?
Reply
Но предварительного проектирования она заменяет. Как пример - TDD является существенным компонентом XP, которое в принципе игнорирует предварительное проектирование. Оно целиком построенно на посылке, что переделать потом дешевле, чем подумать наперед.
Reply
Я хотел своим вопросом уточнить Вашу идею - мне показалась схожесть с TDD в том, что test-first заставляет заранее (до кодирования реализации) проектировать API этого кода, что частично коррелирует с задачей:
>в ходе его печатания будут выявлены ошибки дизайна
Исчерпывающий ответ получен. Спасибо ))
Reply
Общее правило - если вы можете без проблем написать кусок кода до конца - его не надо даже пытаться писать на этапе дизайна. Чтобы поймать ошибку дизайна - надо попытаться закодировать то, что не особо понятно, как вообще выглядеть будет.
Reply
Reply
Reply
Leave a comment