Я удивляюсь, как можно писать о планировании работ, и вообще не упомянуть диаграмму Ганта? То есть, вы планируете, планируете - и даже не представляете, какие у вас зависимости между задачами? И даже не пытаетесь визуализировать, где у вас критический путь? И применить готовый софт типа MS Project, который вполне может учитывать многие упомянутые параметры.
Определить зависимости между стадиями, спланировать параллельную работу с учетом этих зависимостей.
Ну т.е. вот же, прямо оно. Неужели сейчас этому вообще не учат (меня этому учили в институте, причем я учился на инженера)?
Ну я вам так скажу - я работал в МАИ, а сначала учился. Где-то с 1978 года я начал заказывать литературу в магазине. Т.е. ты приходишь в магазин, где тебе дают план выпуска литературы скажем издательства Мир, или там Статистика. Ты его берешь, и переписываешь интересные тебе названия на открытки. И оставляешь эти открытки в магазине. Потом тебе приходит открытка, где написано - можешь получить. Ты идешь после работы в магазин, смотришь эту книгу, и выкупаешь.
Ну т.е. это Москва. Если же ты заранее этим не озаботился, то ты эту книгу в продаже можешь не застать. Ну или как повезет.
Считать ли это, что книги были в достатке? В достатке - нет, не было. Но знаете, когда я сейчас захожу в книжный, то мне там как правило купить ничего не хочется, по крайней мере вот так чтобы "Вах! Я же это давно ищу". То есть, книг стало намного больше, но исходя из моих изменившихся потребностей - лучше не стало. Стало много ширпотребной литературы типа "Excel для чайников", а что-то серьезное не купить. В том числе потому, что далеко не все переводят (да мне не особо и нужно), а книги иностранные если и есть - то в ограниченном непонятном ассортименте, который не ясно, какой странный человек подбирал.
Ну т.е. если чисто субъективно сравнить с условным сетевым книжным магазином Feltrinelli в маленьком итальянском городишке Пиза - так там ассортимент пожалуй что и получше будет.
Ну мы также нанимаем. Поэтому декларации в тексте:
Сегодня поиск работы - это как пройти через лабиринт с огненными кольцами.
сразу вызывают вопросы: а автор откудова это все берет? Каков у него объем выборки, на которой он может это подтвердить? Какова квалификация у людей из этой выборки? На основании чего это обобщается на весь поиск работы, не уточняя ни одного параметра?
Я допускаю, что этот подход может быть применен во время обучения, чтобы через руки до студентов дошло, как надо писать программы.
Ну я где-то выше об этом же говорил. В принципе, попытка написать тест обычно приводит к лучшему пониманию того, что тестируемому компоненту нужно, есть ли у него состояние, как его создавать и инициализировать. Я ничего против такой активности на этапе проектирования не имею, она как правило полезна, студентам - так в особенности. А фанатизм - скорее вреден.
На лыжах в Приэльбрусье это не расслабуха ни разу :) Ну т.е. понятно что в какой-то степени вы можете не напрягаться, но укатанных трасс там в мое время не было вообще, т.е. все катание было внетрассовое. И это могла быть целина, огромные бугры или ледяная корка, иногда одновременно. Не могу сравнить с парапланом, но могу четко сказать, что за два дня катания коленки обычно ноют.
Тут я согласен в целом. И даже больше скажу - в моей практике как правило просто попытка разобраться в баге/странности, и лучше понять код, как правило требует проведения именно изоляции (по сути - это изоляция побочных эффектов в самом общем виде, как в парадигме ФП это называется), тогда то что осталось, чистые функции в идеале, либо легко тестируется, либо мы баг просто вычисляем путем обдумывания.
генерироваться в какой-то функции, и вот именно ее вам и нужно тестировать
Ваш ответ валидный, но он про другое. Вы не уловили сути, я ее плохо описал. Нужно протестировать именно сам запрос и его выполнение. Он может быть вообще не генерируется, и статический.
Но при выполнении у вас даже в простейшем случае два варианта - успешно и нет. Идем дальше - успешно это 0 строк ответа, 1 или много? Оно соответствует ожиданиям? Если неуспешно - то какой код ошибки вернула нам СУБД? Ну и на этом примерно все - как только нам это становится интересно, и мы пытаемся вот это протестировать, мы быстро понимаем, что API или контракт, как ни назовите, СУБД, настолько сложен, что писать под него юнит тесты ну очень муторно. Ну в принципе, потому, что СУБД как правило сильно сложнее нашего типичного прикладного продукта. Т.е. тестировать интеграцию с продуктом, который сложнее нашего, и пытаться это делать юнит тестами - по моему опыту довольно бессмысленно.
замокать функции модуля\коннекшна базы данных
А вы попробуйте как-нибудь на досуге :) Этот модуль в моем случае называется JDBC. И он, скажем прямо, уже как правило сложнее того кода, что пишет большинство миддлов по работе. Я пробовал его мокать/наследоваться. Эта овчинка не стоит выделки.
Но в любом случае, нигде кроме программирования никто не пытается сделать сначала тестовый стенд, а потом изделие под него.
Если вы это все в смысле полезности TDD - то и вопросов нет. Меня слегка изначальная формулировка смутила, что стенды мол не делают. Делают же. Позже (в крайнем случае одновременно) с самим изделием. Раньше - вряд ли. Я бы сказал, что реальные стенды делают тогда, когда это осмысленно. Помнится, когда была широко известная авария Протона в прямом эфире, кто-то позже задавал вопросы, а почему это не проверили на стенде (это - в смысле перевернутый вверх ногами датчик). Ну так потому и не проверили, что стенд, способный покрутить туда-сюда ступень Протона слегка так дорого обходится.
Но при этом - никто в здавом уме и твердой памяти не сказал ни Королеву/Мишину, ни Кузнецову, что еще до создания двигателя надо сделать стенд для его прожига
Знаете что самое смешное? Что мнение о том, что не хватило ресурсов на стенды было когда-то высказано именно Мишиным. Сильно позже, но такой вывод он сделал.
А кто говорит что unit тесты замедляют разработку?
Ну вот я и говорю. Вы еще скажите, что юнит тесты каким-то образом сами создаются, и вы на их создание (и поддержку) не тратите время :)
Даже если их делают нейросети - это все равно ваше время.
Но опять же - я готов согласиться, что ваши проекты не такие как мои, и у вас могут быть другие пропорции, которые делают их более полезными. Я просто приведу пример: вот вы выполняете SQL запрос, SELECT для ясности. Это настолько типовая функция приложения, что типичнее некуда. И при этом она практически не тестируется юнит тестами - только интеграционные, и полноценно покрыть все исходы можно только в фантазиях.
накидать рабочий пример, а дальше они докидают кейсов.
Ну вот давайте, покажите мне как нейросеть накидает мне тестов на интеграцию с керберосом? Я реально с удовольствием на это посмотрю. Ну т.е. я пишу клиента для работы с REST сервисом, который одновременно HTTPS, т.е. нужно настроить сертификаты, и в тоже время - SPNEGO, т.е. нужно керберос тикеты и заголовки.
На Эльбрусе для катания на лыжах (а это в основном ниже 4000) нужна адаптация. Но после пары дней уже все ок. Я катался от Приюта 11 (4050) - вообще никаких ощущений что высоко.
Да дело даже не в одной стоимости. На их разработку нужно время. А это всегда дефицит. Зачастую самый дефицитный. При этом время мы тратим сегодня, а профит как правило если и получаем (например мы упростили рефакторинг) - то позже.
Не вдаваясь в дискуссию - давайте просто посмотрим на другие отрасли, и с удивлением обнаружим, что НИКТО (ни в авиации, ни в медицине, ни где либо еще) - не пытается делать тестовые стенды под еще не готовое изделие!
Простите, но нет. Более того, я слышал например мнение, что советская ракета Н-1 не полетела (в отличие от Аполлона) в частности и потому, что не было денег на тестовые стенды например для двигателей, и их не удалось достаточно отработать до полета.
То есть, их не просто строят, но они зачастую являются решающим фактором успеха или неудачи проекта.
Если бизнес готов тратить деньги на баги и время на их исправление - пожалуйста.
Я еще ни разу не видел бизнес, который бы с радостью потратил деньги на тестирование, а не на новые функции. По крайней мере до тех пор, пока качество его устраивает.
В итоге тратит х10 времени на отладку и проверку
Возможно. Но и функциональность написана раньше, проверена, мы понимаем, что бизнес хотел именно этого, и двигаемся дальше. Ну и не в 10 раз конечно - если вы не можете написать код приемлемого качества без тестов, за сравнимое время - что-то у вас не так с проектом, возможно квалификация в среднем недостаточно высока (ну т.е. часть команды джуны, и без них не справляетесь), или проект слишком новый и незнакомый.
Вот просто для примера - у меня большая часть багов вызвана неопределенностями в интеграциях с другими системами. И снять эти неопределенности путем написания скажем моков - невозможно. И даже интеграционные тесты не на проме проблем зачастую не выявляют.
В общем, ваша позиция имеет право на жизнь, в определенных условиях наверное совершенно правильная - но не универсальная.
И еще она разная. В пределах одной "таблицы". По сути, это и значит, что ее нет - она есть у каждой записи, но у следующей записи она может быть другая.
Знаете, есть такая штука, как Hive. Там нет индексов, нет транзакций, репликацию обеспечивает Hadoop HDFS. При этом в качестве хранилища данных поддерживается любой разумный формат файлов, какой можно преобразовать в колонки таблицы. Включая и CSV, само собой. Единственное ограничение - что формат этот один на таблицу/партицию. И все это вполне себе работает с терабайтами.
Конечно, правильнее было бы сказать, что ACID там уже появился, но в тоже время, много-много лет многие пользователи (включая меня) работали с этим как с промышленной СУБД, при некоторых ограничениях, само собой.
Ну т.е. я к чему - все эти свойства, они в общем случае не обязательны.
чтобы был мощный бэкхенд нужно удар начинать с ног.
Вы точно понимаете, что такое бэкхенд в настольном теннисе? Там ноги вообще почти не участвуют, в основном пресс. Для форхенда - соглашусь, потому что там амплитуда сильно больше, а тут просто амплитуда движения маленькая, поэтому ноги выполняют в основном функцию "подвести тело в точку удара". Разумеется, без ног никуда, если вы попробуете выполнить удар скажем в полете или неустойчивом положении - вы скорее всего и промажете, и удар будет слабый. То есть, опора конечно же нужна, а опора это ноги.
Но роль ног именно в бэкхенде вы преувеличиваете. Скручивание корпуса, пресс и т.п. гораздо важнее, и в современном теннисе гораздо полезнее, уже давно никто не играет слева в левосторонней стойке - хотя она позволяет ногами как раз вложиться куда мощнее - но это и намного медленнее.
Я удивляюсь, как можно писать о планировании работ, и вообще не упомянуть диаграмму Ганта? То есть, вы планируете, планируете - и даже не представляете, какие у вас зависимости между задачами? И даже не пытаетесь визуализировать, где у вас критический путь? И применить готовый софт типа MS Project, который вполне может учитывать многие упомянутые параметры.
Ну т.е. вот же, прямо оно. Неужели сейчас этому вообще не учат (меня этому учили в институте, причем я учился на инженера)?
Ну я вам так скажу - я работал в МАИ, а сначала учился. Где-то с 1978 года я начал заказывать литературу в магазине. Т.е. ты приходишь в магазин, где тебе дают план выпуска литературы скажем издательства Мир, или там Статистика. Ты его берешь, и переписываешь интересные тебе названия на открытки. И оставляешь эти открытки в магазине. Потом тебе приходит открытка, где написано - можешь получить. Ты идешь после работы в магазин, смотришь эту книгу, и выкупаешь.
Ну т.е. это Москва. Если же ты заранее этим не озаботился, то ты эту книгу в продаже можешь не застать. Ну или как повезет.
Считать ли это, что книги были в достатке? В достатке - нет, не было. Но знаете, когда я сейчас захожу в книжный, то мне там как правило купить ничего не хочется, по крайней мере вот так чтобы "Вах! Я же это давно ищу". То есть, книг стало намного больше, но исходя из моих изменившихся потребностей - лучше не стало. Стало много ширпотребной литературы типа "Excel для чайников", а что-то серьезное не купить. В том числе потому, что далеко не все переводят (да мне не особо и нужно), а книги иностранные если и есть - то в ограниченном непонятном ассортименте, который не ясно, какой странный человек подбирал.
Ну т.е. если чисто субъективно сравнить с условным сетевым книжным магазином Feltrinelli в маленьком итальянском городишке Пиза - так там ассортимент пожалуй что и получше будет.
В 1991 в СССР? Ну формально да, в 1990 ФИДО появился, а фактически скорее чуть попозже.
Ну и потом, фактически первый сайт, к созданию которого я непосредственно приложил руки, появился в 1995. И ФИДО тогда уже точно есть.
Ну мы также нанимаем. Поэтому декларации в тексте:
сразу вызывают вопросы: а автор откудова это все берет? Каков у него объем выборки, на которой он может это подтвердить? Какова квалификация у людей из этой выборки? На основании чего это обобщается на весь поиск работы, не уточняя ни одного параметра?
Ну я где-то выше об этом же говорил. В принципе, попытка написать тест обычно приводит к лучшему пониманию того, что тестируемому компоненту нужно, есть ли у него состояние, как его создавать и инициализировать. Я ничего против такой активности на этапе проектирования не имею, она как правило полезна, студентам - так в особенности. А фанатизм - скорее вреден.
На лыжах в Приэльбрусье это не расслабуха ни разу :) Ну т.е. понятно что в какой-то степени вы можете не напрягаться, но укатанных трасс там в мое время не было вообще, т.е. все катание было внетрассовое. И это могла быть целина, огромные бугры или ледяная корка, иногда одновременно. Не могу сравнить с парапланом, но могу четко сказать, что за два дня катания коленки обычно ноют.
Тут я согласен в целом. И даже больше скажу - в моей практике как правило просто попытка разобраться в баге/странности, и лучше понять код, как правило требует проведения именно изоляции (по сути - это изоляция побочных эффектов в самом общем виде, как в парадигме ФП это называется), тогда то что осталось, чистые функции в идеале, либо легко тестируется, либо мы баг просто вычисляем путем обдумывания.
Ваш ответ валидный, но он про другое. Вы не уловили сути, я ее плохо описал. Нужно протестировать именно сам запрос и его выполнение. Он может быть вообще не генерируется, и статический.
Но при выполнении у вас даже в простейшем случае два варианта - успешно и нет. Идем дальше - успешно это 0 строк ответа, 1 или много? Оно соответствует ожиданиям? Если неуспешно - то какой код ошибки вернула нам СУБД? Ну и на этом примерно все - как только нам это становится интересно, и мы пытаемся вот это протестировать, мы быстро понимаем, что API или контракт, как ни назовите, СУБД, настолько сложен, что писать под него юнит тесты ну очень муторно. Ну в принципе, потому, что СУБД как правило сильно сложнее нашего типичного прикладного продукта. Т.е. тестировать интеграцию с продуктом, который сложнее нашего, и пытаться это делать юнит тестами - по моему опыту довольно бессмысленно.
А вы попробуйте как-нибудь на досуге :) Этот модуль в моем случае называется JDBC. И он, скажем прямо, уже как правило сложнее того кода, что пишет большинство миддлов по работе. Я пробовал его мокать/наследоваться. Эта овчинка не стоит выделки.
Если вы это все в смысле полезности TDD - то и вопросов нет. Меня слегка изначальная формулировка смутила, что стенды мол не делают. Делают же. Позже (в крайнем случае одновременно) с самим изделием. Раньше - вряд ли. Я бы сказал, что реальные стенды делают тогда, когда это осмысленно. Помнится, когда была широко известная авария Протона в прямом эфире, кто-то позже задавал вопросы, а почему это не проверили на стенде (это - в смысле перевернутый вверх ногами датчик). Ну так потому и не проверили, что стенд, способный покрутить туда-сюда ступень Протона слегка так дорого обходится.
Знаете что самое смешное? Что мнение о том, что не хватило ресурсов на стенды было когда-то высказано именно Мишиным. Сильно позже, но такой вывод он сделал.
Ну вот я и говорю. Вы еще скажите, что юнит тесты каким-то образом сами создаются, и вы на их создание (и поддержку) не тратите время :)
Даже если их делают нейросети - это все равно ваше время.
Но опять же - я готов согласиться, что ваши проекты не такие как мои, и у вас могут быть другие пропорции, которые делают их более полезными. Я просто приведу пример: вот вы выполняете SQL запрос, SELECT для ясности. Это настолько типовая функция приложения, что типичнее некуда. И при этом она практически не тестируется юнит тестами - только интеграционные, и полноценно покрыть все исходы можно только в фантазиях.
Ну вот давайте, покажите мне как нейросеть накидает мне тестов на интеграцию с керберосом? Я реально с удовольствием на это посмотрю. Ну т.е. я пишу клиента для работы с REST сервисом, который одновременно HTTPS, т.е. нужно настроить сертификаты, и в тоже время - SPNEGO, т.е. нужно керберос тикеты и заголовки.
На Эльбрусе для катания на лыжах (а это в основном ниже 4000) нужна адаптация. Но после пары дней уже все ок. Я катался от Приюта 11 (4050) - вообще никаких ощущений что высоко.
Да дело даже не в одной стоимости. На их разработку нужно время. А это всегда дефицит. Зачастую самый дефицитный. При этом время мы тратим сегодня, а профит как правило если и получаем (например мы упростили рефакторинг) - то позже.
Простите, но нет. Более того, я слышал например мнение, что советская ракета Н-1 не полетела (в отличие от Аполлона) в частности и потому, что не было денег на тестовые стенды например для двигателей, и их не удалось достаточно отработать до полета.
То есть, их не просто строят, но они зачастую являются решающим фактором успеха или неудачи проекта.
Я еще ни разу не видел бизнес, который бы с радостью потратил деньги на тестирование, а не на новые функции. По крайней мере до тех пор, пока качество его устраивает.
Возможно. Но и функциональность написана раньше, проверена, мы понимаем, что бизнес хотел именно этого, и двигаемся дальше. Ну и не в 10 раз конечно - если вы не можете написать код приемлемого качества без тестов, за сравнимое время - что-то у вас не так с проектом, возможно квалификация в среднем недостаточно высока (ну т.е. часть команды джуны, и без них не справляетесь), или проект слишком новый и незнакомый.
Вот просто для примера - у меня большая часть багов вызвана неопределенностями в интеграциях с другими системами. И снять эти неопределенности путем написания скажем моков - невозможно. И даже интеграционные тесты не на проме проблем зачастую не выявляют.
В общем, ваша позиция имеет право на жизнь, в определенных условиях наверное совершенно правильная - но не универсальная.
И еще она разная. В пределах одной "таблицы". По сути, это и значит, что ее нет - она есть у каждой записи, но у следующей записи она может быть другая.
Знаете, есть такая штука, как Hive. Там нет индексов, нет транзакций, репликацию обеспечивает Hadoop HDFS. При этом в качестве хранилища данных поддерживается любой разумный формат файлов, какой можно преобразовать в колонки таблицы. Включая и CSV, само собой. Единственное ограничение - что формат этот один на таблицу/партицию. И все это вполне себе работает с терабайтами.
Конечно, правильнее было бы сказать, что ACID там уже появился, но в тоже время, много-много лет многие пользователи (включая меня) работали с этим как с промышленной СУБД, при некоторых ограничениях, само собой.
Ну т.е. я к чему - все эти свойства, они в общем случае не обязательны.
Вы точно понимаете, что такое бэкхенд в настольном теннисе? Там ноги вообще почти не участвуют, в основном пресс. Для форхенда - соглашусь, потому что там амплитуда сильно больше, а тут просто амплитуда движения маленькая, поэтому ноги выполняют в основном функцию "подвести тело в точку удара". Разумеется, без ног никуда, если вы попробуете выполнить удар скажем в полете или неустойчивом положении - вы скорее всего и промажете, и удар будет слабый. То есть, опора конечно же нужна, а опора это ноги.
Но роль ног именно в бэкхенде вы преувеличиваете. Скручивание корпуса, пресс и т.п. гораздо важнее, и в современном теннисе гораздо полезнее, уже давно никто не играет слева в левосторонней стойке - хотя она позволяет ногами как раз вложиться куда мощнее - но это и намного медленнее.
Ради объективности, ракетка для настольного тенниса тоже под 200 грамм.
Я вам назвал четверых, однако вы почему-то сконцентрировались лишь на одном. Еще раз уже с фамилиями:
1 (1). Ван Чуцин (Китай) - 8020
2 (2). Фан Чжэндон (Китай) - 5788
3 (3). Лян Цзинкунь (Китай) - 3955
4 (4). Ма Лон (Китай) - 3660
5 (5). Феликс Лебрен (Франция) - 3132
6 (6). Линь Юньжу (Китайский Тайбей) - 3106
7 (7). Лин Гаойян (Китай) - 2525
8 (8). Уго Кальдерано (Бразилия) - 1965
9 (9). Томокадзу Харимото (Япония) - 1790
10 (10). Данг Цю (Германия) - 1580
Вот эти выделенные четверо ни разу не похожи на тяжелоатлетов. И пожалуй только Фан как раз на такого похож. А это мировая десятка.
Или возьмем Ма Лонга:
Рост 175 см Вес 70 кг - вы это называете "тяжелоатлет"?