Ну, я предлагаю разделить всю эту тему на три разных вопроса: 1) что даёт TDD; 2) зачем формальные тесты и 3) что вообще тестировать.
"Не тестируем тривиальные вещи" или "не тестируем GUI/CSS/одноразовый код" -- это про (3). Пункт (2) сразу про две вещи: код (на уровне компонентов) гарантированно работает как заявлено в соответствии с указанным входом-выходом и про некую "живую" документацию, позволяющую понять, как этим кодом можно пользоваться, что важно для меня будущего или других участников, но неактуально для кода вида "написал и забыл". А вот (1) ещё про то, что вы на выходе получаете архитектуру, обладающая рядом свойств, среди которых есть "тестируемость".
То что вы называете архитектуру обладающую любыми свойствами кроме "можно написать юнит тесты" плохой
Это не я называю, это мнение автора исходного поста, а также ряда других авторов. Слово "плохой" здесь слишком обобщающее и абстрактное, но я думаю, что невозможность протестировать отдельные компоненты системы никак не может считаться достоинством, так что да, это изъян архитектуры, как ни крути. Вы можете с ним мириться или считать в своей работе несущественным, конечно.
А возможность написать юнит тесты не так важна.
Ну, получается, что и нет предмета спора. Вы не считаете невозможность протестировать компоненты достоинством? Нет, вы просто полагаете, что этот недостаток в данном случае не очень важен. Я не вижу способа доказать или опровергнуть это утверждение, тут мы уже переходим в область мнений и оценок.
У меня совершенно не радикальные воззрения, это вы, как мне кажется, юлите. Я же задал простой вопрос: вы согласны с тем, что архитектура, которую нельзя протестировать -- плохая? Если не согласны, тогда чего мы обсуждаем? А если согласны, то с чем спорим?
Вопрос о том, держится ли бизнес Кликхауса на системе, состоящей из непротестированных компонентов, не является предметом мнения. Это фактический вопрос, и ответ на него либо "да", либо "нет". Причём "нет" ещё не трагедия -- ну вот так, и что? Живём же.
Архитектура и бизнес -- это в принципе вещи связанные, но разные. Можно иметь идеальную архитектуру и ноль доходов и наоборот, поэтому странно обсуждать эти штуки в одном абзаце. А что касается юнит-тестов -- мы вообще обсуждаем не их, а TDD как методику, by design позволяющую получить тестируемый код. Если получение тестируемого кода не считается достойной целью -- ну флаг в руки, я же не пытаюсь переделать весь мир, но говорить о свойствах кода и архитектуры с заказчиком и командой же можно открыто?
Ещё раз, давайте отталкиваться от совместного понимания. Либо вы согласны с мнением выше ("нетестируемая архитектура плоха"), либо нет. Если согласны, то ваша реплика звучит так: "у меня плохая архитектура в проекте везде, но так надо". Хорошо, надо так надо.
Если нетестируемый юнит тестами быстрый код экономит бизнесу миллион долларов в месяц на железе, то это хорошая архитектура или нет?
Аналогично, давайте эту фразу переформулируем так: "на сегодняшний день у меня бизнес держится на системе, состоящей из непротестированных компонентов без формализованных примеров входа-выхода, и пока это работает".
Я на текущее обсуждение смотрю не как на поиск серебряной пули или единственно верного подхода, а на желание выложить на стол все карты. Вот вы заказчику так и говорите: я верю, что смогу сделать систему быстрее, и работать она будет шустрее, но при этом состоять она будет из сильно связанных и непротестированных компонентов. А там пусть заказчик уже и думает, нравится ему такое или нет.
Это все совсем не синонимы. И в разных местам может быть нужно разное.
Ну я ссылаюсь на текст выше, в котором сказано, что тестируемость есть необходимое, но недостаточное условие хорошей архитектуры. При этом автор не просто мнение высказывает, он повторяет то, что неоднократно сказано другими. Отсюда прямо следует, что если код плохо тестируем, он имеет плохую архитектуру.
Плохая архитектура может быть лучше с точки зрения производительности, читабельности и проч., но разумно предположить, что это будет касаться отдельных модулей, а не всего вместе. Таким образом, можно, например, начать с TDD, а для непокрытых участков писать прямо в комментарии, что тут плохая архитектура потому-то и потому-то, мы в курсе.
Фаззинг тесты не пробовали?
Собираюсь, но пока нет. По-хорошему всё делать надо, конечно :) Тема TDD интересна тем, что она прямо влияет на процесс и архитектуру, а не только решает вопросы на этапе QA.
но примерно через год-два работы с TDD вы будете намного глубже видеть как плюсы, так и минусы этого подхода. Потому что у вас будет с чем сравнивать.
Вероятно. На нынешнем этапе я пытаюсь исходить из минимального количества аксиом, которые мне представляются необходимыми при любом раскладе. Например, как вам такая логика:
Если я создаю некий компонент, то не проверить его работоспособность -- это попросту непрофессионально. Ну не знаю, "у меня компилируется, а там трава не расти", "я всё сделал по рецепту и сварил суп, а вкусный или нет -- не пробовал". Соответственно, я его тестирую. Если я его тестирую, нет никакой причины не протестировать его не руками, а автоматом.
Далее, если компонент меняется, то (см. выше) я всё равно его должен протестировать, иначе как мне убедиться, что ничего не сломалось. Поэтому, да, тест тоже придётся подправить. Но я в любом случае буду его тестировать. Тут важна гранулярность, конечно, я не тестирую private-методы, потому что это не API.
Если тест написать сложно, я могу его не писать и не тестировать (мы же не догматики и не перфекционисты), но отсутствие теста -- это сигнал, что тут код тяжело тестируется, а значит, архитектура данного компонента так себе, и по возможности требуется рефакторинг.
Если мы говорим об интеграционных или приёмочных тестах -- ну как бы я двумя руками за, понятно, что они нужны. Но наша программа -- это дискретная система с миллионами состояний, проверить которые я не могу. Изменился компонент A, приёмочный тест говорит, что всё ОК. Юнит-тесты ненадёжны, но приёмочные тоже ненадёжны, потому что из миллионов вариантов будет тестироваться меньше процента. Соответственно, я хотя бы должен убедиться, что компонент сам по себе работает (иначе непрофессионально, см. пункт 1, что возвращает к самому началу).
Вот, это самые общие соображения, в которых нет никакого фанатизма или попытки продавить конкретный подход к чему бы то ни было.
Это разумное соображение, оно пересекается с другой цитатой с MSDN: "after code reviews, smoke testing is the most cost effective method for identifying and fixing defects in software". Это, правда, мнение, доказательств нет.
Собственно, в первой реплике я же сразу упомянул, что "обеспечение качества" для меня тут не на первом месте. На первом месте именно архитектура, заточенная под тестирование, потому что она отсекает массу плохих архитектур.
Так ровно это же написано в оригинальном посте, который мы тут обсуждаем: "общепризнанно, что хорошо спроектированный код также поддается тестированию". Да, это необходимо, но недостаточно.
Но по личному опыту (своего кода и кода, с которым приходится иметь дело) могу сказать, что к среднему обычному коду не очень просто прикрутить тесты (без обилия моков и вот этого всего), что означает, что он не спроектирован хорошо. Иными словами, мне кажется, что без фактического тестирования очень трудно заставить себя писать легко тестируемый код. Гипотетически можно, на практике далеко не всегда видно, где тестируемость ломается.
Я не уверен, что вы можете этим ракету заправить, но да, продаётся 灯油 (перевода кроме "керосин" я не знаю), и заливается это дело вот в такого типа агрегаты.
Да нет, у меня масса самого разного опыта за плечами, если я "перехожу на TDD", это не значит, что я перехожу с "hello, world", ну честно.
Собственно, ровно по причинам, о которых вы говорите, у меня всегда случался какой-то затык, и приходилось плюнуть на тесты. Но я стараюсь делать выводы и подходить к TDD, скажем так, с обновлённым набором предпосылок. Ну об этом можно подробнее поговорить, конечно.
проект становится Легаси через два месяца от старта разработки.
Это утверждение занятным образом пересекается с известным определением Майкла Фезерса: "To me, legacy code is simply code without tests."
Не соглашусь. Я сам медленно и тяжело перехожу на TDD, но это, наверно, и хорошо, т.к. выскажусь не как фанбой.
Если у вас тесты увеличивают трудозатраты, то это ведь не потому, что ты пишете пару строк теста? Всё равно вам надо как-то тестировать написанное. Причина, вероятно, в том, что написанный код автотестировать по какой-либо причине трудно.
А если тестировать трудно, значит, он не очень хорошо написан, и, скорее всего, в нём хромает соответствие single responsibility principle. Для меня ценность TDD в основном в том, что эта методология заставляет писать такой код, который легко тестировать (и не увеличивать трудозатраты). То есть у меня изначально отнимают целый ряд плохих вариантов структуры программы.
Уже нет. Я застал когда-то все эти раскладушки типа Sharp, которые были завязаны на местных операторов и на стандарт CDMA. Но это уже был последний вздох, потом iPhone победил всех. Сейчас по факту либо iPhone, либо Galaxy, либо что-то дешёвое, выданное оператором (под своим брендом, но это просто шильдик, и залоченный).
Да жить в комфорте -- это не совсем про Японию, если честно. Попробуйте, например, пожить сезон без центрального отопления, таская с автозаправки керосин для горелки. Ну потому что это дешевле и теплее кондиционера с обогревом.
Отставание тоже имеется, достаточно вспомнить популярный японский софт... которого нет. На эту тему даже статьи писали. В целом причина -- упор на "железячную" индустрию, которая уже менее заметна, чем в 80х, но до сих пор связанные с софтом отрасли на втором плане.
Тут, конечно, немного о другом говорится, но это связанные вещи, как мне кажется.
Это немного разговор ни о чём. Понятно, что есть ошибки первого и второго типа (ложноположительные и ложноотрицательные). Задача системы состоит в оптимизации "в целом", а не в полном искоренении ошибок обоих типов, что невозможно. Если же сосредоточиться только на минимизации ложноотрицательных, т.е. поощрять людей вызывать скорую при любом чихе, то просто будут умирать другие люди, до которых не доехали.
1) По поводу разделения "комнат" и "абстрактных комнат" -- верно, тут обманка бытового языка. "Выход ведёт из комнаты А в комнату Б" -- это неточная формулировка, потому что если её реализовывать ровно как сказано, то получится рекурсивная зависимость. Как разработчик я это понимаю, но в рамках упражнения мне было интересно аккуратно перевести русский на Python и посмотреть, что получится. А когда не получилось, стало интересно, почему не получилось.
2) По поводу "создать экземпляры, а потом соединить" -- это ровно та же история. Конечно, можно сделать комнату, а потом соединить комнаты коридорами. Но в описании на русском было не так.
Собственно, это и есть круг интересных вопросов. Мы понимаем, как написать программу, и мы понимаем, как её сформулировать на русском так, чтобы результат "склеился" хорошо ("создаём комнату А, создаём комнату Б, создаём коридор"). Интереснее обсудить, почему альтернативное описание (на первый взгляд ничем не уступающее) оказывается негодным.
Я думаю, важный момент состоит в том, что эти соображения в идеале не должны играть роли. Ну то есть у меня в голове комнаты и выходы, у вас -- коридоры в центре, а третья опция -- перегородки. В принципе, любое из этих представлений соответствует исходному описанию задачи, поэтому универсальная методология моделирования должна сработать для любой картины в голове, при условии, что она непротиворечива и точно сформулирована. Понятно, что можно попробовать придумать десять способом представления задачи, написать десять программ и убедиться, что не все они одинаково хороши. Но нет же способа узнать заранее, какое представление приведёт к более лаконичному коду.
Например я не уверен, что понимаю, как мой мозг строит модель реальности
Ну я на это не претендую. Мы говорим о модели физического мира (комнатах и коридорах), а как оно у нас в голове -- это отдельная история.
Я не уверен, что на 100% уловил вашу мысль, но мне кажется, что это имеет вполне разумное объяснение, так как мы можем оперировать лишь ограниченным числом элементов, а тем более не можем представить их все в деталях.
Да, именно так. Если представить себе, что гипотетическая оптимальная архитектура -- это клубок из 25 компонентов и 100 связей между ними, то вряд ли мы сможем её придумать, наша голова на такое не рассчитана.
Было бы интересно услышать мнения большего количества людей.
Спасибо. Да, я в целом согласен с этим подходом. Наверно, надо отделять реальный мир от того, который мы создаём в коде. В данном случае, однако, эксперимент получается довольно чистым, т.к. эти концепции очень хорошо друг на друга ложатся.
В целом перспектива выбросить/провести рефакторинг/переписать меня не смущает. Смущает то, что вот когда задача маленькая, мы можем прикинуть себе хорошую архитектуру (т.к. всё в голове помещается). А вот если в системе много элементов, не исключено, что гипотетическое оптимальное решение уже и не увидеть.
Может, это чисто умозрительная проблема. А может, и нет, если взять массу классических алгоритмов "из книжки", там нередко самая разная магия происходит, которую трудно концептуально свести к сущностям, связям и протоколам общения.
Бесплатного стало мало в относительных юнитах. Ищите в фидо-эхах потому, что современные медиумы и реддиты заполнены стапятистами унылыми хелловорлдами по js,
Согласен! Но это же неизбежно. Как говорится, с появлением фейсбука и комментов на ютюбе мы узнали, о чём же, собственно, думает среднестатистический обыватель. Я не представляю, как может сложиться иначе. Не запрещать же писать блоги без сдачи экзамена.
Так в других странах вас просто сразу само государство накажет — например
...
Тут багаж не какой-то специфичный культурный, а куда более глубокий.
Ну так тоже соглашусь, это не какие-то специфические айти-заморочки в рамках злых корпораций или государства из "1984". Это болезни очередного этапа развития человечества. Лучше чем приколы первой половины ХХ века, например, но ещё далеко не рай.
Ну, я предлагаю разделить всю эту тему на три разных вопроса: 1) что даёт TDD; 2) зачем формальные тесты и 3) что вообще тестировать.
"Не тестируем тривиальные вещи" или "не тестируем GUI/CSS/одноразовый код" -- это про (3). Пункт (2) сразу про две вещи: код (на уровне компонентов) гарантированно работает как заявлено в соответствии с указанным входом-выходом и про некую "живую" документацию, позволяющую понять, как этим кодом можно пользоваться, что важно для меня будущего или других участников, но неактуально для кода вида "написал и забыл". А вот (1) ещё про то, что вы на выходе получаете архитектуру, обладающая рядом свойств, среди которых есть "тестируемость".
Это вопрос цены и целесообразности. Выше же написали:
С текстом далее я не согласен, но вот этот симптом же не про плохой фреймворк, а про то, что вся эта деятельность становится нудной и бессмысленной.
Это не я называю, это мнение автора исходного поста, а также ряда других авторов. Слово "плохой" здесь слишком обобщающее и абстрактное, но я думаю, что невозможность протестировать отдельные компоненты системы никак не может считаться достоинством, так что да, это изъян архитектуры, как ни крути. Вы можете с ним мириться или считать в своей работе несущественным, конечно.
Ну, получается, что и нет предмета спора. Вы не считаете невозможность протестировать компоненты достоинством? Нет, вы просто полагаете, что этот недостаток в данном случае не очень важен. Я не вижу способа доказать или опровергнуть это утверждение, тут мы уже переходим в область мнений и оценок.
У меня совершенно не радикальные воззрения, это вы, как мне кажется, юлите. Я же задал простой вопрос: вы согласны с тем, что архитектура, которую нельзя протестировать -- плохая? Если не согласны, тогда чего мы обсуждаем? А если согласны, то с чем спорим?
Вопрос о том, держится ли бизнес Кликхауса на системе, состоящей из непротестированных компонентов, не является предметом мнения. Это фактический вопрос, и ответ на него либо "да", либо "нет". Причём "нет" ещё не трагедия -- ну вот так, и что? Живём же.
Архитектура и бизнес -- это в принципе вещи связанные, но разные. Можно иметь идеальную архитектуру и ноль доходов и наоборот, поэтому странно обсуждать эти штуки в одном абзаце. А что касается юнит-тестов -- мы вообще обсуждаем не их, а TDD как методику, by design позволяющую получить тестируемый код. Если получение тестируемого кода не считается достойной целью -- ну флаг в руки, я же не пытаюсь переделать весь мир, но говорить о свойствах кода и архитектуры с заказчиком и командой же можно открыто?
Ещё раз, давайте отталкиваться от совместного понимания. Либо вы согласны с мнением выше ("нетестируемая архитектура плоха"), либо нет. Если согласны, то ваша реплика звучит так: "у меня плохая архитектура в проекте везде, но так надо". Хорошо, надо так надо.
Аналогично, давайте эту фразу переформулируем так: "на сегодняшний день у меня бизнес держится на системе, состоящей из непротестированных компонентов без формализованных примеров входа-выхода, и пока это работает".
Я на текущее обсуждение смотрю не как на поиск серебряной пули или единственно верного подхода, а на желание выложить на стол все карты. Вот вы заказчику так и говорите: я верю, что смогу сделать систему быстрее, и работать она будет шустрее, но при этом состоять она будет из сильно связанных и непротестированных компонентов. А там пусть заказчик уже и думает, нравится ему такое или нет.
Ну я ссылаюсь на текст выше, в котором сказано, что тестируемость есть необходимое, но недостаточное условие хорошей архитектуры. При этом автор не просто мнение высказывает, он повторяет то, что неоднократно сказано другими. Отсюда прямо следует, что если код плохо тестируем, он имеет плохую архитектуру.
Плохая архитектура может быть лучше с точки зрения производительности, читабельности и проч., но разумно предположить, что это будет касаться отдельных модулей, а не всего вместе. Таким образом, можно, например, начать с TDD, а для непокрытых участков писать прямо в комментарии, что тут плохая архитектура потому-то и потому-то, мы в курсе.
Собираюсь, но пока нет. По-хорошему всё делать надо, конечно :) Тема TDD интересна тем, что она прямо влияет на процесс и архитектуру, а не только решает вопросы на этапе QA.
Вероятно. На нынешнем этапе я пытаюсь исходить из минимального количества аксиом, которые мне представляются необходимыми при любом раскладе. Например, как вам такая логика:
Если я создаю некий компонент, то не проверить его работоспособность -- это попросту непрофессионально. Ну не знаю, "у меня компилируется, а там трава не расти", "я всё сделал по рецепту и сварил суп, а вкусный или нет -- не пробовал". Соответственно, я его тестирую. Если я его тестирую, нет никакой причины не протестировать его не руками, а автоматом.
Далее, если компонент меняется, то (см. выше) я всё равно его должен протестировать, иначе как мне убедиться, что ничего не сломалось. Поэтому, да, тест тоже придётся подправить. Но я в любом случае буду его тестировать. Тут важна гранулярность, конечно, я не тестирую private-методы, потому что это не API.
Если тест написать сложно, я могу его не писать и не тестировать (мы же не догматики и не перфекционисты), но отсутствие теста -- это сигнал, что тут код тяжело тестируется, а значит, архитектура данного компонента так себе, и по возможности требуется рефакторинг.
Если мы говорим об интеграционных или приёмочных тестах -- ну как бы я двумя руками за, понятно, что они нужны. Но наша программа -- это дискретная система с миллионами состояний, проверить которые я не могу. Изменился компонент A, приёмочный тест говорит, что всё ОК. Юнит-тесты ненадёжны, но приёмочные тоже ненадёжны, потому что из миллионов вариантов будет тестироваться меньше процента. Соответственно, я хотя бы должен убедиться, что компонент сам по себе работает (иначе непрофессионально, см. пункт 1, что возвращает к самому началу).
Вот, это самые общие соображения, в которых нет никакого фанатизма или попытки продавить конкретный подход к чему бы то ни было.
Это разумное соображение, оно пересекается с другой цитатой с MSDN: "after code reviews, smoke testing is the most cost effective method for identifying and fixing defects in software". Это, правда, мнение, доказательств нет.
Собственно, в первой реплике я же сразу упомянул, что "обеспечение качества" для меня тут не на первом месте. На первом месте именно архитектура, заточенная под тестирование, потому что она отсекает массу плохих архитектур.
Так ровно это же написано в оригинальном посте, который мы тут обсуждаем: "общепризнанно, что хорошо спроектированный код также поддается тестированию". Да, это необходимо, но недостаточно.
Но по личному опыту (своего кода и кода, с которым приходится иметь дело) могу сказать, что к среднему обычному коду не очень просто прикрутить тесты (без обилия моков и вот этого всего), что означает, что он не спроектирован хорошо. Иными словами, мне кажется, что без фактического тестирования очень трудно заставить себя писать легко тестируемый код. Гипотетически можно, на практике далеко не всегда видно, где тестируемость ломается.
Я не уверен, что вы можете этим ракету заправить, но да, продаётся 灯油 (перевода кроме "керосин" я не знаю), и заливается это дело вот в такого типа агрегаты.
Да нет, у меня масса самого разного опыта за плечами, если я "перехожу на TDD", это не значит, что я перехожу с "hello, world", ну честно.
Собственно, ровно по причинам, о которых вы говорите, у меня всегда случался какой-то затык, и приходилось плюнуть на тесты. Но я стараюсь делать выводы и подходить к TDD, скажем так, с обновлённым набором предпосылок. Ну об этом можно подробнее поговорить, конечно.
Это утверждение занятным образом пересекается с известным определением Майкла Фезерса: "To me, legacy code is simply code without tests."
Не соглашусь. Я сам медленно и тяжело перехожу на TDD, но это, наверно, и хорошо, т.к. выскажусь не как фанбой.
Если у вас тесты увеличивают трудозатраты, то это ведь не потому, что ты пишете пару строк теста? Всё равно вам надо как-то тестировать написанное. Причина, вероятно, в том, что написанный код автотестировать по какой-либо причине трудно.
А если тестировать трудно, значит, он не очень хорошо написан, и, скорее всего, в нём хромает соответствие single responsibility principle. Для меня ценность TDD в основном в том, что эта методология заставляет писать такой код, который легко тестировать (и не увеличивать трудозатраты). То есть у меня изначально отнимают целый ряд плохих вариантов структуры программы.
Уже нет. Я застал когда-то все эти раскладушки типа Sharp, которые были завязаны на местных операторов и на стандарт CDMA. Но это уже был последний вздох, потом iPhone победил всех. Сейчас по факту либо iPhone, либо Galaxy, либо что-то дешёвое, выданное оператором (под своим брендом, но это просто шильдик, и залоченный).
Да жить в комфорте -- это не совсем про Японию, если честно. Попробуйте, например, пожить сезон без центрального отопления, таская с автозаправки керосин для горелки. Ну потому что это дешевле и теплее кондиционера с обогревом.
Отставание тоже имеется, достаточно вспомнить популярный японский софт... которого нет. На эту тему даже статьи писали. В целом причина -- упор на "железячную" индустрию, которая уже менее заметна, чем в 80х, но до сих пор связанные с софтом отрасли на втором плане.
Тут, конечно, немного о другом говорится, но это связанные вещи, как мне кажется.
Планетарные бои тоже по-своему ностальгичны и интересны. Это же ремейк Nether Earth 1987 года со Спектрума.
Это немного разговор ни о чём. Понятно, что есть ошибки первого и второго типа (ложноположительные и ложноотрицательные). Задача системы состоит в оптимизации "в целом", а не в полном искоренении ошибок обоих типов, что невозможно. Если же сосредоточиться только на минимизации ложноотрицательных, т.е. поощрять людей вызывать скорую при любом чихе, то просто будут умирать другие люди, до которых не доехали.
Да, в целом согласен.
1) По поводу разделения "комнат" и "абстрактных комнат" -- верно, тут обманка бытового языка. "Выход ведёт из комнаты А в комнату Б" -- это неточная формулировка, потому что если её реализовывать ровно как сказано, то получится рекурсивная зависимость. Как разработчик я это понимаю, но в рамках упражнения мне было интересно аккуратно перевести русский на Python и посмотреть, что получится. А когда не получилось, стало интересно, почему не получилось.
2) По поводу "создать экземпляры, а потом соединить" -- это ровно та же история. Конечно, можно сделать комнату, а потом соединить комнаты коридорами. Но в описании на русском было не так.
Собственно, это и есть круг интересных вопросов. Мы понимаем, как написать программу, и мы понимаем, как её сформулировать на русском так, чтобы результат "склеился" хорошо ("создаём комнату А, создаём комнату Б, создаём коридор"). Интереснее обсудить, почему альтернативное описание (на первый взгляд ничем не уступающее) оказывается негодным.
Я думаю, важный момент состоит в том, что эти соображения в идеале не должны играть роли. Ну то есть у меня в голове комнаты и выходы, у вас -- коридоры в центре, а третья опция -- перегородки. В принципе, любое из этих представлений соответствует исходному описанию задачи, поэтому универсальная методология моделирования должна сработать для любой картины в голове, при условии, что она непротиворечива и точно сформулирована. Понятно, что можно попробовать придумать десять способом представления задачи, написать десять программ и убедиться, что не все они одинаково хороши. Но нет же способа узнать заранее, какое представление приведёт к более лаконичному коду.
Ну я на это не претендую. Мы говорим о модели физического мира (комнатах и коридорах), а как оно у нас в голове -- это отдельная история.
Да, именно так. Если представить себе, что гипотетическая оптимальная архитектура -- это клубок из 25 компонентов и 100 связей между ними, то вряд ли мы сможем её придумать, наша голова на такое не рассчитана.
Мне тоже :) Ну, ещё не вечер.
Спасибо. Да, я в целом согласен с этим подходом. Наверно, надо отделять реальный мир от того, который мы создаём в коде. В данном случае, однако, эксперимент получается довольно чистым, т.к. эти концепции очень хорошо друг на друга ложатся.
В целом перспектива выбросить/провести рефакторинг/переписать меня не смущает. Смущает то, что вот когда задача маленькая, мы можем прикинуть себе хорошую архитектуру (т.к. всё в голове помещается). А вот если в системе много элементов, не исключено, что гипотетическое оптимальное решение уже и не увидеть.
Может, это чисто умозрительная проблема. А может, и нет, если взять массу классических алгоритмов "из книжки", там нередко самая разная магия происходит, которую трудно концептуально свести к сущностям, связям и протоколам общения.
Согласен! Но это же неизбежно. Как говорится, с появлением фейсбука и комментов на ютюбе мы узнали, о чём же, собственно, думает среднестатистический обыватель. Я не представляю, как может сложиться иначе. Не запрещать же писать блоги без сдачи экзамена.
Ну так тоже соглашусь, это не какие-то специфические айти-заморочки в рамках злых корпораций или государства из "1984". Это болезни очередного этапа развития человечества. Лучше чем приколы первой половины ХХ века, например, но ещё далеко не рай.