По-моему это обычное дело, когда заказчик выдвигает абстрактные требования. У него есть какая-то проблема, он не знает как её решить (скажем, потому что не обладает нужными компетенциями), но очень хочет и для этого обращается к разработчику.
Естественно, что заказчик описывает проблему абстрактно: в меру собственного понимания, каких-то ощущений и эмоций. Задача разработчика как раз и состоит в том, чтобы выявить «паталогию», придумать решение и реализовать.
Когда разработчик, не разобравшись в проблеме и не придумав решение, бросается «кодить» — это клиника — такую ситуацию, думаю, можно не рассматривать.
Если ваш заказчик берет на себя функцию принятия технических решений (например, размер шрифта), это скорее всего означает, что в ваших отношениях с ним что-то не так. И вам нужно, в первую очередь, решить этот вопрос. Ведь заказчик менее компетентен в сфере разрботки, нежели вы, и его действия вполне ожидаемо будут неверными. (в таком случае, он тупо будет учиться, на собтсвенных ошибках, — которые скорее всего будут выдаваться за ваши).
Может быть он вам не доверяет? В этом случае постарайтесь доказать свою компетенцию, чтобы у него не было сомнений. А может быть вы сами снимаете с себя ответственность за выработку решений? Тогда естественно эту функцию он будет брать на себя и станет выдумывать решение сам (ведь больше не кому).
в Vista, по умолчанию установлено 96dpi. у меня экран 129dpi и поэтому текст выглядит очень мелко. если выставить в настройках эти самые 129dpi, то текст во многих приложениях перестает помещаться в отведенную ему место.
ага) в принципе, многие телики уже комплектуются ethernet входом/wifi и софтом для просмотра контента из сети, в том числе видеохостингов типа youtube. например samsung C6540
from itertools import permutations
source = "jibw ji jp bw jibw"
words = source.split()
answer = min("".join(combination) for combination in permutations(words))
согласен. но чтобы быть практически значимой, философия решения задачи должна поддерживаться фичами языка.
то, что в python называется поддержкой ФП, в реальности является лишь синтаксическим сахаром, имитацией этой самой парадигмы. например, вот такой ФП-подобный код на «мультипарадигменном» python выглядит вполне органично:
>>> f = lambda (x, y): x + y
>>> a = (1, 2)
>>> f(a)
3
но по сути, он чужеродный, ведь работает очень не эффективно. в процессе выполнения такой программы, в самом деле, создаются переменные, а лямбда распаковывает кортеж в пару локальных объектов. в «настоящих» функциональных языках картина совсем иная, т.к. там нет переменных.
некоторое количество кода, пользующегося хаком в виде разбора стектрейса для доступа к рантайм значениям переменных в вызывающем коде, перестанет работать.
и поделом =) «вызывающий код» для рекурсивной функции это та же самая функция. в этом случае есть более очевидные способы передать значения переменных, нежели стектрейс. :)
Да, так и есть: другое решение, нужно описывать заново — я периодически попадаю в такие ситуации. По-моему, это в порядке вещей — все равно нормальное решение получается лишь с третьего раза. :)
Отнюдь не претендую на абсолютную истинность или новизну суждений — просто мнение, которое у меня сложилось к данному моменту. Я занимаюсь web-программированием и активно использую автоматические тесты лишь последние пол. года. Раз уж согласились с тезисом о требованиях, может быть проясните и спорный момент с проектированием? =)
Я рассуждаю так. Допустим, есть некоторая задача, которая стоит того, чтобы её решить. Допустим — найти ответ на Главный вопрос жизни, вселенной и всего такого. Задача сложная и как писать код вообще совсем не понятно. Однако, это уже какая-то информация. Данные факты — то, что задача уже поставлена, и то, что непонятно как писать код — можно записать в виде теста на всем понятном языке:
void testShouldAnswerToTheUltimateQuestionOfLifeTheUniverseAndEverything() {
throw new SkipTest()
}
Профит в том, что данная конструкция уже одним своим существованием будет напоминать о необходимости что-то так-и родить, при каждом запуске тестов. Можно пойти дальше, и сочинить сценарий решения, например с участием суперкомпьютера и удивительным ответом в конце:
И так, реализации ещё нет, но тест уже есть. Все в рамках ТДД. Вот только не поняно — я все правильно спроектировал, или нет? Может быть решатель нужно было представить в виде простой функции, а не объекта с методом? И не на с++ а на lisp? Верен-ли ответ? Как проверить?
Получается, что тесты являются лишь способом записи решений, принятых в процессе проектирования. Но каким образом они устраняют ошибки проектирования? — Мне не понятно.
Тесты, это такой хитрый способ записи требований, который одновременно понятен и нормальному человеку (не программисту) и машине. В идеале — с первого раза ни у кого не получается. ;) Поэтому тесты в ТДД пишутся раньше, чем код, как blueprint того, что ты должен сделать.
Покрытие кода тестами это, по сути, реверс-инжениринг требований по имеющейся реализации. Это не основная практика ТДД. Такими вещами обычно занимаются провинившиеся — из-за разгильдяйства на предыдущих этапах разработки, или там от безысходности — постфактум. ;)
Что должен делать «Бункер»? Обработать нажатие мыши — требование раз. Сохранить себя в xml — требование два,… Записать это на языке тестов не составит труда. А после этого, их можно запускать — в любом количестве, в любое время, вручную поштучно и автоматически по over 9k за раз, на всем протяжении жизни проекта. Что там еще было? — не открывать внутренней информации другим классам — хрень, а не требование, оно не формализуется. Есть расхожее мнение, мол ТДД обеспечивает правильность проектирования — это миф. Тесты сами — по себе, проектирование — само по себе.
в самом деле, удобно. но функциональность CapsLock иногда нужна. можно-ли повесить её на другое сочетание клавиш (например, одновременное нажатие левого и правого Shift)?
плохо спроектированный код почти невозможно автоматически тестировать, и наоборот — намерение тестировать код вынуждает более грамотно проектировать архитектуру
Кажется, это очередной миф. Формально, тест работает с реализацией как с черным ящиком: для теста все равно — хоть там архитектурное чудо, хоть путанное-перепутанное «спагетти».
К слову, ГОСТ 34.601-90 «техническое задание» идет аж 3-м пунктом. До ТЗ есть ещё 2 равноценные стадии: «формирование требований» и «разработка концепции», а после — «эскизный проект», «технический проект» и т.п. ТЗ составляется совместно с заказчиком. А в 34.003-90 перечисляются отдельные компоненты. Например (2.9) как раз призвано решать проблему с лексиконом.
Нет, я не предлагаю оформлять отношения с заказчиком по ГОСТам. Просто хочу отметить тот факт, что на ТЗ свет клином не сошёлся. В простых случаях, отдельные стадии создания можно совмещать или даже пропускать целиком. Но чем крупнее проект, тем лучше обращать внимание на чужой опыт. Все-таки автоматизированные системы, тоже сложные штуки, и закономерно полагать, что разработчики на все эти грабли уже наступали, и выработали какую-то стратегию для достижения результата.
Естественно, что заказчик описывает проблему абстрактно: в меру собственного понимания, каких-то ощущений и эмоций. Задача разработчика как раз и состоит в том, чтобы выявить «паталогию», придумать решение и реализовать.
Когда разработчик, не разобравшись в проблеме и не придумав решение, бросается «кодить» — это клиника — такую ситуацию, думаю, можно не рассматривать.
Если ваш заказчик берет на себя функцию принятия технических решений (например, размер шрифта), это скорее всего означает, что в ваших отношениях с ним что-то не так. И вам нужно, в первую очередь, решить этот вопрос. Ведь заказчик менее компетентен в сфере разрботки, нежели вы, и его действия вполне ожидаемо будут неверными. (в таком случае, он тупо будет учиться, на собтсвенных ошибках, — которые скорее всего будут выдаваться за ваши).
Может быть он вам не доверяет? В этом случае постарайтесь доказать свою компетенцию, чтобы у него не было сомнений. А может быть вы сами снимаете с себя ответственность за выработку решений? Тогда естественно эту функцию он будет брать на себя и станет выдумывать решение сам (ведь больше не кому).
выдает bwjibwjibwjijp
последний пример (на си?) тоже императивный функциональный?
то, что в python называется поддержкой ФП, в реальности является лишь синтаксическим сахаром, имитацией этой самой парадигмы. например, вот такой ФП-подобный код на «мультипарадигменном» python выглядит вполне органично:
но по сути, он чужеродный, ведь работает очень не эффективно. в процессе выполнения такой программы, в самом деле, создаются переменные, а лямбда распаковывает кортеж в пару локальных объектов. в «настоящих» функциональных языках картина совсем иная, т.к. там нет переменных.
и поделом =) «вызывающий код» для рекурсивной функции это та же самая функция. в этом случае есть более очевидные способы передать значения переменных, нежели стектрейс. :)
Я рассуждаю так. Допустим, есть некоторая задача, которая стоит того, чтобы её решить. Допустим — найти ответ на Главный вопрос жизни, вселенной и всего такого. Задача сложная и как писать код вообще совсем не понятно. Однако, это уже какая-то информация. Данные факты — то, что задача уже поставлена, и то, что непонятно как писать код — можно записать в виде теста на всем понятном языке:
Профит в том, что данная конструкция уже одним своим существованием будет напоминать о необходимости что-то так-и родить, при каждом запуске тестов. Можно пойти дальше, и сочинить сценарий решения, например с участием суперкомпьютера и удивительным ответом в конце:
И так, реализации ещё нет, но тест уже есть. Все в рамках ТДД. Вот только не поняно — я все правильно спроектировал, или нет? Может быть решатель нужно было представить в виде простой функции, а не объекта с методом? И не на с++ а на lisp? Верен-ли ответ? Как проверить?
Получается, что тесты являются лишь способом записи решений, принятых в процессе проектирования. Но каким образом они устраняют ошибки проектирования? — Мне не понятно.
Покрытие кода тестами это, по сути, реверс-инжениринг требований по имеющейся реализации. Это не основная практика ТДД. Такими вещами обычно занимаются провинившиеся — из-за разгильдяйства на предыдущих этапах разработки, или там от безысходности — постфактум. ;)
Что должен делать «Бункер»? Обработать нажатие мыши — требование раз. Сохранить себя в xml — требование два,… Записать это на языке тестов не составит труда. А после этого, их можно запускать — в любом количестве, в любое время, вручную поштучно и автоматически по over 9k за раз, на всем протяжении жизни проекта. Что там еще было? — не открывать внутренней информации другим классам — хрень, а не требование, оно не формализуется. Есть расхожее мнение, мол ТДД обеспечивает правильность проектирования — это миф. Тесты сами — по себе, проектирование — само по себе.
Кажется, это очередной миф. Формально, тест работает с реализацией как с черным ящиком: для теста все равно — хоть там архитектурное чудо, хоть путанное-перепутанное «спагетти».
Нет, я не предлагаю оформлять отношения с заказчиком по ГОСТам. Просто хочу отметить тот факт, что на ТЗ свет клином не сошёлся. В простых случаях, отдельные стадии создания можно совмещать или даже пропускать целиком. Но чем крупнее проект, тем лучше обращать внимание на чужой опыт. Все-таки автоматизированные системы, тоже сложные штуки, и закономерно полагать, что разработчики на все эти грабли уже наступали, и выработали какую-то стратегию для достижения результата.