…
— Нет, я не издеваюсь. Просто прошлый раз под «что-нибудь» я понимал целые числа, а вы думали про все подряд. Потом пришлось переделывать.
— Ну это же просто здравый смысл взять все числа!
— Здравый смысл как оказывается у каждого свой, да еще и склонен меняться. Давайте пару примеров накидаем и так все будет проще.
В том, что между этими переделками вы можете в любой момент времени, сделав изменение в любом месте, понять что все работает как должно работать. А если что-то поломается, то это будет видно и заказчику и вам и всем заинтересованным лицам.
Так тут как раз все отлично! Полгода вы контролировали автоматически что она грузит данные из одного места. Потом перед тем как изменить поменяли тест. Он не проходит. Реализовали загрузку из другого места и вуаля! Все продолжает работать. Называется это ATDD — Acceptance Test Driven Development. :)
Рефакторинг — последовательность изменений, которая изменяет внутреннюю структуру программы без изменения ее внешнего поведения.
При рефакторинге тесты не меняются. Более того, без них невозможно убедиться, что внешнее поведение не изменилось, а значит называть это рефакторингом. :)
1. Его не надо заставлять ничего писать. Вопросов «а как вы проверите, что это работает», «а давайте рассмотрим на примерах», «а как это будет использоваться» в умелых руках достаточно, чтобы получить набор тестов.
2. Тут вы точно подметили, надо считать. Это решение логически верное, но может быть физически невыгодным в определенных условиях. Например, при краткосрочном проекте или очень сложным пользовательским интерфейсом, который почти нереально покрыть автотестами.
3. Ничего страшного, тесты дописываются в момент нахождения таких моментов. Главное, сразу же подумать как не допустить такого в будущем.
Для того, чтобы все учитывать и не забывать, надо мыслить малым. Именно в этом помогают итерации и фокусировка на ограниченном небольшом куске функциональности.
Вы правы — не все легко покрыть автотестами. Но из моего опыта, люди зачастую просто не знают, не хотят, не умеют этого делать. Для веб проектов есть Selenium, для совершенно произвольных есть Sikuli. А еще уйма инструментов специализированных. Если не получается протестировать через конечный пользовательский UI, то можно тестировать API бизнес логики.
Речь идет о работе над требованиями на очень короткий срок — обычно одна итерация. Если он не может на такой срок сформулировать требования во всех деталях и ответить на все вопросы, то у вас уже проблемы. :)
К сожалению, вы читаете сквозь строки и не хотите прислушаться к тому, что я вам пытаюсь донести. Аспекты независимые, но каждый из них отнимает определенное время. Решение = уровень первого аспекта + уровень второго аспекта. Вот и идет речь о балансе, когда не надо в обоих аспектах добиваться максимума.
Если для вас чистота кода = длина методов, то тут я могу вас заверить, что это больше здравый смысл и он применяется даже в прототипе. Я веду речь о разделении кода на классы, построении правильной ООП модели, разделении ответственности, применении дизайн паттернов. На это уходит время. Банально хотя бы на то, чтобы подумать над дизайном, а потом его применить.
С кодом прототипа никто работать не будет. В этом и особенность. Именно поэтому и открывается возможность снизить планку качества кода на нем. В вашем примере, если коллега попросит сменить СУБД и повторить эксперимент, то я вынесу эти методы автоматизированными рефакторингами моей IDE. А если не попросит? Зачем тратить на это время? Алгоритм прост: сделал чтобы работало -> проверил идею -> задумался будут ли доработки -> выбросил код или привел в порядок. :)
Простите, вы хотите сказать, что чистый код менее работоспособный, или работоспособный — менее чистый? Это ведь бред.
Это два независимых аспекта кода. Я как раз это и написал.
Почему? Попробуйте писать чистый код, и Вы увидите, что писать стало БЫСТРЕЕ (а ведь мы хотим писать прототипы быстрее). Ошибки (которые надо устранять и в прототипах) — исправляются много быстрее.
Дело в том, что часто для проверки какой-то идеи не надо создавать хорошего, поддерживаемого дизайна, использовать шаблоны проектирования, следить за размером методов и классов. Можно даже использовать не рекомендуемые в обычной жизни вещи: статику, прямое обращение к файловой системе, базе данных и т.д. И это будет реально быстрее.
Каждый раз, когда Вы пишете грязный код, Вы гадите себе в проф. качества. Да, в данном конкретном случае Ваш код не помешал. Но на подсознательном отложилась возможность писать кривой код. И это ОБЯЗАТЕЛЬНО вылезет Вам боком. Так что чистый код — писать нужно в любом случае.
Я как раз сторонник чистого кода. Уже 6 лет работаю строго по TDD, на каждом проекте применяется 100% ревью кода, парное программирование на сложных задачах и статические анализаторы (очень грамотно настроенный Sonar). Но ничего не мешает мне пробовать идеи без всех этих техник, чтобы потом выбросить этот код и написать хорошее решение. Нет смысла вкладывать в качество того, что может не справиться с задачей, поставленной требованиями.
У кода есть два аспекта: чистота и работоспособность. Другими словами, надо стремиться к «чистому коду, который работает правильно». От баланса между этими двумя аспектами и зависит подход к разработке. Когда пишутся прототипы, то основная цель — сделать работающий код. Чистота его на тот момент не нужна. Но для поддержки кода в будущем, исправления найденных в нем дефектов, адаптации его под новые задачи без огромных затрат времени нужно заботиться и об аспекте чистоты.
В XP (eXtreme Programming) специально выделяется практика написания spike. Это специальный формат задачи (технической истории), цель которой уменьшить неопределенность и технологические риски при реализации основной задачи. По правилам код, написанный во время реализации spike, не может быть перенесен в основную ветку. Поэтому его можно писать, не заботясь о поддержке в будущем.
В целом, от баланса между указанными двумя аспектами и зависит решение, стоит ли писать чистый код в том или ином случае. Но люди, которые привыкли писать чистый код, потом просто не могут иначе… :)
— Нет, я не издеваюсь. Просто прошлый раз под «что-нибудь» я понимал целые числа, а вы думали про все подряд. Потом пришлось переделывать.
— Ну это же просто здравый смысл взять все числа!
— Здравый смысл как оказывается у каждого свой, да еще и склонен меняться. Давайте пару примеров накидаем и так все будет проще.
При рефакторинге тесты не меняются. Более того, без них невозможно убедиться, что внешнее поведение не изменилось, а значит называть это рефакторингом. :)
1. Его не надо заставлять ничего писать. Вопросов «а как вы проверите, что это работает», «а давайте рассмотрим на примерах», «а как это будет использоваться» в умелых руках достаточно, чтобы получить набор тестов.
2. Тут вы точно подметили, надо считать. Это решение логически верное, но может быть физически невыгодным в определенных условиях. Например, при краткосрочном проекте или очень сложным пользовательским интерфейсом, который почти нереально покрыть автотестами.
3. Ничего страшного, тесты дописываются в момент нахождения таких моментов. Главное, сразу же подумать как не допустить такого в будущем.
Для того, чтобы все учитывать и не забывать, надо мыслить малым. Именно в этом помогают итерации и фокусировка на ограниченном небольшом куске функциональности.
Если для вас чистота кода = длина методов, то тут я могу вас заверить, что это больше здравый смысл и он применяется даже в прототипе. Я веду речь о разделении кода на классы, построении правильной ООП модели, разделении ответственности, применении дизайн паттернов. На это уходит время. Банально хотя бы на то, чтобы подумать над дизайном, а потом его применить.
С кодом прототипа никто работать не будет. В этом и особенность. Именно поэтому и открывается возможность снизить планку качества кода на нем. В вашем примере, если коллега попросит сменить СУБД и повторить эксперимент, то я вынесу эти методы автоматизированными рефакторингами моей IDE. А если не попросит? Зачем тратить на это время? Алгоритм прост: сделал чтобы работало -> проверил идею -> задумался будут ли доработки -> выбросил код или привел в порядок. :)
Это два независимых аспекта кода. Я как раз это и написал.
Дело в том, что часто для проверки какой-то идеи не надо создавать хорошего, поддерживаемого дизайна, использовать шаблоны проектирования, следить за размером методов и классов. Можно даже использовать не рекомендуемые в обычной жизни вещи: статику, прямое обращение к файловой системе, базе данных и т.д. И это будет реально быстрее.
Я как раз сторонник чистого кода. Уже 6 лет работаю строго по TDD, на каждом проекте применяется 100% ревью кода, парное программирование на сложных задачах и статические анализаторы (очень грамотно настроенный Sonar). Но ничего не мешает мне пробовать идеи без всех этих техник, чтобы потом выбросить этот код и написать хорошее решение. Нет смысла вкладывать в качество того, что может не справиться с задачей, поставленной требованиями.
В XP (eXtreme Programming) специально выделяется практика написания spike. Это специальный формат задачи (технической истории), цель которой уменьшить неопределенность и технологические риски при реализации основной задачи. По правилам код, написанный во время реализации spike, не может быть перенесен в основную ветку. Поэтому его можно писать, не заботясь о поддержке в будущем.
В целом, от баланса между указанными двумя аспектами и зависит решение, стоит ли писать чистый код в том или ином случае. Но люди, которые привыкли писать чистый код, потом просто не могут иначе… :)