Ну всмысле как? Ведущий выбирает из двух дверей, какую открыть. Он не открывает дверь, на которую показал игрок.
Две двери, ведущий выбирает из них пустую. Сознательно. Зная, где коза. У двух дверей раньше была вероятность 2/3. Теперь вероятность для них осталась такой же, но из двух дверей закрыта только одна.
Шучу, серьёзный ответ будет: "а так же, как и всем остальным"
И про комментарии в корне не согласен. Если человек не может перевести "save_period", то пусть идёт в дворники. Тот, кто пишет комментарий "период сохранения" тоже пусть в дворники идёт. Комментарий должен быть "Период сохранения в секундах после последнего действия пользователя".
80% - лажа гопоты, 20% - моя лажа. Ну примерно так. В расчёте на строчку кода гопота лажает намного чаще, тесты находят у меня так много ошибок просто потому, что я знаю, что именно надо тестировать.
Если вы не знаете что тестировать значит либо не поняли задачу, либо вам её плохо поставили
Вы наверное работали только в ролях исполнителя, когда вам приносят уже разжёванную задачу. Как бы так вам сказать... Эту задачу нужно ещё создать, порезать на таски и этим тоже кто-то занимается. Потому что бизнес как правило приходит не с задачами, а с проблемами. А ещё есть ресёрч. А ещё есть дискоммуникация.
Поэтому у вас сейчас всё просто. Не надо абсолютизма. TDD - не волшебная пилюля, у него есть границы применимости. Если вы не видите их - значит вы просто слепо верите в TDD.
TDD занимается вопросами как надо писать код, как не надо изучает психиатрия
когда вы уже готовитесь писать решение, но не знаете какая у вас бизнес проблема
Проблема как раз известна. Мне нужно дать решение. Каким оно будет - я пока не знаю. Мне нужно сделать ресёрч. Нужно накидать прототип, проверить, как он решает проблему. Потом переписать, потому что пришла в голову идея получше. Оно сразу не получается найти это решение.
Я не спорю, есть задачи (как правило сильно мельче и сильно детерминированнее), которые можно и нужно делать через TDD. Но у меня вот так. Когда я решаю проблемы конкретных людей, а не железяк, мне нужно показывать прототип конкретным людям и получать фидбек. Мне никакие тесты не скажут, решил я проблему или нет.
У меня такое работает. Но есть нюанс. Код пишу я сам, а тесты пишет гопота. А потом, когда это с треском падает, я иду разбираться, что же не работает - тесты или код. А падает оно примерно всегда.
Когда я начинаю писать функционал, я понятия не имею, как он будет выглядеть. И понятия не имею, как его тестировать. За время разработки функционала его архитектура может поменяться десять раз. Если начинать с тестов, то в каждой итерации надо будет и тесты переделывать. А в конце всё равно окажется, что тестируют они не то и не так.
Я для себя нашёл тот этап, когда наиболее разумно писать тесты. Это когда сложный функционал готов, работает, но ещё не отлажен. Вот тогда можно и подумать, а что и как лучше протестировать. Но это уже ни разу не TDD.
Я вам сказал, что конкретно в этом месте вы говорите неправду. Вы же делаете вывод о моих личных качествах. Здесь есть существенная разница и я прошу больше так не делать. Больше никаких шуток про лечащего врача, ок?
И давайте напомню, с чего началось. Вы сказали, что способ, который я предложил, не годится. И долго доставали аргументы из кармана.
В остатке ваш аргумент: это ИНОГДА не годится, потому что, возможно, вы не согласовали это с ответственными лицами. А может быть вы вообще работаете по контракту с государством и повязаны анусокарательными мерами безопасности.
Тем не менее, я говорил про себя и свою компанию. И я не понимаю, почему большинство компаний не делает техзадачи на основе своей кодобазы. Им ничего не мешает. Взяли кусок, рассмотрели, утвердили для показа кандидатам. В этом нет ничего сложного.
С точки зрения безопасности это лучше. Потому что показанный кусок полностью подконтрольный (да и что кандидат с ним сделает, ну серьёзно?), а когда он станет работником, вам ПРИДЁТСЯ дать ему весь код.
Давайте я вообще вашу логику до абсурда доведу. Есть такой приём. Я говорю, что я люблю шашлык. Что в этом такого?
А вы можете меня обвинить в каннибализме. Потому что ситуации разные бывают и я мог оказаться на острове без животных с тремя товарищами.
Например в нашей. Если конечно данное действие сочтут госизменой.
Или в странах где действует английское право и есть жесткие законы об интеллектуальной собственности.
Вы врёте. Или просто за два раза так и не прочитали вопрос. Давайте ещё раз: я написал код, я владею всеми правами на него, в какой стране меня посадят за его показ? Ну если там не было цп в комментах.
А большинство (если не все) сотрудников этих компаний не уполномочены принимать решения
Когда я принимаю кого-то на работу, я делаю это от лица компании. Компания может выбирать стратегию набора персонала и методы отсеивания кандидатов. Конечно, грузчик не имеет права раскрывать коммерческую тайну, но набор персонала - это то, что управляется теми лицами, которые могут принимать решение.
Дело в том что вы не "показываете код кандидату" а передаете чужую интеллектуальную собственность (или даже возможно объект государственной тайны) третьему лицу.
Повторяю вопрос: в какой стране я получу 25 лет за показ своего кода кандидату.
В прошлом сообщении я писал, что вы подменяете тезисы. Большинство компаний на айти рынке труда являются собственниками кода. Они могут решать, показывать ли его для приёма на собеседование. И никакие 25 лет никому не грозят.
А в какой стране я получу 25 лет за показ своего кода кандидату?
Вы сейчас не очень ловко превратили мой тезис "я бы так делал" в тезис "есть случаи, когда это не подходит". И вместо реальных последствий показываете юридические.
неподходящий и некомпетентный - разные вещи
В данном случае это неважно. Последствия одни и те же.
Вы уж меня простите, уважаемый автор, но у меня конформность отбита на всю голову. На меня фраза "не принято" действует как красная тряпка на быка.
Так что ни разу не ок. Мне нужно подробное объяснение, чем это грозит и почему утечка куска кода через экран - это ужасно, а взять некомпетентного или просто неподходящего человека с риском утечки ВСЕГО кода в цифровом виде - это ок.
Если система принадлежит вашей компании то происходит утечка интеллектуальной собственности и нарушение трудового договора, не надо так делать.
ой, ладно вам, какая ещё утечка, ну он что, втихаря на мобильник кусок кода сфотографирует? а зачем?
Это достаточно спорная практика, из серии "выкинуть в океане и посмотреть научится ли плавать".
Так его всё равно туда кидать. И потом уже за ним, только взятым на работу, смотреть, научится плавать или нет. И увольнять, если что, с потерей финансов на обучение и с утечкой ВСЕГО исходного кода.
Автор, ну мысли же банальные, всё давно уже пережёвано. Да и надменные эйчары всё равно не прочитают этот текст (но плюс я всё равно поставил).
Я бы следующим образом проводил интервью: я бы взял программера, дал бы ему ноут с куском существующей системы и сказал бы: расскажите, что вообще тут происходит.
А дальше уже наблюдал, может ли он читать код. Какие шаги предпринимает, какие вопросы задаёт.
Если человек может прочитать код, с которым ему предстоит работать - такой человек скорее всего сможет и писать его.
Для этого нужно, чтобы saving был отглагольным существительным. Нужно указать, что именно оно сейвит. Как существительное само по себе - это экономия.
Ну всмысле как? Ведущий выбирает из двух дверей, какую открыть. Он не открывает дверь, на которую показал игрок.
Две двери, ведущий выбирает из них пустую. Сознательно. Зная, где коза. У двух дверей раньше была вероятность 2/3. Теперь вероятность для них осталась такой же, но из двух дверей закрыта только одна.
Зачем? Медтермины обычно на латыни, пусть в латыни и остаются. Это общепризнанный общемировой формат
нет, у saving другая семантика. Это слово обозначает экономию
Я в курсе. И назвал бы переменную SaveDelayAfterLastActionSec, ой, простите, тут питоний, значит save_delay_after_last_action_sec
И вообще бы вынес нахер в константы в начало файла. Соответственно, капсом.
Вопрос: а нужен ли мне после этого вообще комментарий?
А никак, бгггг
Шучу, серьёзный ответ будет: "а так же, как и всем остальным"
И про комментарии в корне не согласен. Если человек не может перевести "save_period", то пусть идёт в дворники. Тот, кто пишет комментарий "период сохранения" тоже пусть в дворники идёт. Комментарий должен быть "Период сохранения в секундах после последнего действия пользователя".
Вероятность перебежала с открытой двери на не открытую?
Потому что ведущий открывает одну из двух дверей. Причём ту, которая пустая. Вероятность перетекает в тот момент, когда ведущий ВЫБИРАЕТ пустую дверь.
80% - лажа гопоты, 20% - моя лажа. Ну примерно так. В расчёте на строчку кода гопота лажает намного чаще, тесты находят у меня так много ошибок просто потому, что я знаю, что именно надо тестировать.
Вы наверное работали только в ролях исполнителя, когда вам приносят уже разжёванную задачу. Как бы так вам сказать... Эту задачу нужно ещё создать, порезать на таски и этим тоже кто-то занимается. Потому что бизнес как правило приходит не с задачами, а с проблемами. А ещё есть ресёрч. А ещё есть дискоммуникация.
Поэтому у вас сейчас всё просто. Не надо абсолютизма. TDD - не волшебная пилюля, у него есть границы применимости. Если вы не видите их - значит вы просто слепо верите в TDD.
Нет
Проблема как раз известна. Мне нужно дать решение. Каким оно будет - я пока не знаю. Мне нужно сделать ресёрч. Нужно накидать прототип, проверить, как он решает проблему. Потом переписать, потому что пришла в голову идея получше. Оно сразу не получается найти это решение.
Я не спорю, есть задачи (как правило сильно мельче и сильно детерминированнее), которые можно и нужно делать через TDD. Но у меня вот так. Когда я решаю проблемы конкретных людей, а не железяк, мне нужно показывать прототип конкретным людям и получать фидбек. Мне никакие тесты не скажут, решил я проблему или нет.
У меня такое работает. Но есть нюанс. Код пишу я сам, а тесты пишет гопота. А потом, когда это с треском падает, я иду разбираться, что же не работает - тесты или код. А падает оно примерно всегда.
Когда я начинаю писать функционал, я понятия не имею, как он будет выглядеть. И понятия не имею, как его тестировать. За время разработки функционала его архитектура может поменяться десять раз. Если начинать с тестов, то в каждой итерации надо будет и тесты переделывать. А в конце всё равно окажется, что тестируют они не то и не так.
Я для себя нашёл тот этап, когда наиболее разумно писать тесты. Это когда сложный функционал готов, работает, но ещё не отлажен. Вот тогда можно и подумать, а что и как лучше протестировать. Но это уже ни разу не TDD.
Я вам сказал, что конкретно в этом месте вы говорите неправду. Вы же делаете вывод о моих личных качествах. Здесь есть существенная разница и я прошу больше так не делать. Больше никаких шуток про лечащего врача, ок?
И давайте напомню, с чего началось. Вы сказали, что способ, который я предложил, не годится. И долго доставали аргументы из кармана.
В остатке ваш аргумент: это ИНОГДА не годится, потому что, возможно, вы не согласовали это с ответственными лицами. А может быть вы вообще работаете по контракту с государством и повязаны анусокарательными мерами безопасности.
Тем не менее, я говорил про себя и свою компанию. И я не понимаю, почему большинство компаний не делает техзадачи на основе своей кодобазы. Им ничего не мешает. Взяли кусок, рассмотрели, утвердили для показа кандидатам. В этом нет ничего сложного.
С точки зрения безопасности это лучше. Потому что показанный кусок полностью подконтрольный (да и что кандидат с ним сделает, ну серьёзно?), а когда он станет работником, вам ПРИДЁТСЯ дать ему весь код.
Давайте я вообще вашу логику до абсурда доведу. Есть такой приём. Я говорю, что я люблю шашлык. Что в этом такого?
А вы можете меня обвинить в каннибализме. Потому что ситуации разные бывают и я мог оказаться на острове без животных с тремя товарищами.
Вы врёте. Или просто за два раза так и не прочитали вопрос. Давайте ещё раз: я написал код, я владею всеми правами на него, в какой стране меня посадят за его показ? Ну если там не было цп в комментах.
Когда я принимаю кого-то на работу, я делаю это от лица компании. Компания может выбирать стратегию набора персонала и методы отсеивания кандидатов. Конечно, грузчик не имеет права раскрывать коммерческую тайну, но набор персонала - это то, что управляется теми лицами, которые могут принимать решение.
Повторяю вопрос: в какой стране я получу 25 лет за показ своего кода кандидату.
В прошлом сообщении я писал, что вы подменяете тезисы. Большинство компаний на айти рынке труда являются собственниками кода. Они могут решать, показывать ли его для приёма на собеседование. И никакие 25 лет никому не грозят.
А в какой стране я получу 25 лет за показ своего кода кандидату?
Вы сейчас не очень ловко превратили мой тезис "я бы так делал" в тезис "есть случаи, когда это не подходит". И вместо реальных последствий показываете юридические.
В данном случае это неважно. Последствия одни и те же.
Вы уж меня простите, уважаемый автор, но у меня конформность отбита на всю голову. На меня фраза "не принято" действует как красная тряпка на быка.
Так что ни разу не ок. Мне нужно подробное объяснение, чем это грозит и почему утечка куска кода через экран - это ужасно, а взять некомпетентного или просто неподходящего человека с риском утечки ВСЕГО кода в цифровом виде - это ок.
ой, ладно вам, какая ещё утечка, ну он что, втихаря на мобильник кусок кода сфотографирует? а зачем?
Так его всё равно туда кидать. И потом уже за ним, только взятым на работу, смотреть, научится плавать или нет. И увольнять, если что, с потерей финансов на обучение и с утечкой ВСЕГО исходного кода.
Автор, ну мысли же банальные, всё давно уже пережёвано. Да и надменные эйчары всё равно не прочитают этот текст (но плюс я всё равно поставил).
Я бы следующим образом проводил интервью: я бы взял программера, дал бы ему ноут с куском существующей системы и сказал бы: расскажите, что вообще тут происходит.
А дальше уже наблюдал, может ли он читать код. Какие шаги предпринимает, какие вопросы задаёт.
Если человек может прочитать код, с которым ему предстоит работать - такой человек скорее всего сможет и писать его.