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