Тестовое задание я могу списать, или дать решить другому человеку,
Можете. Но на вопросы по коду вы не заучите ответы. Не могу исключить, что где-то это прокатит, но в среднем вы засыплетесь на первом-втором вопросе: "а нахрена вы вот так тут написали".
Не, я согласен что я слегка упрощаю. Да, упрощаю - чтобы яснее продемонстрировать мысль. На самом деле в оригинале же написано просто - почему HR могут так точно измерять производительность? При этом практически ничего не сказано о том, как они ее измеряют, и какова на самом деле точность. Я призываю, если угодно, таким вот утверждениям без доказательства не верить. Вполне возможно, что у HR простой KPI, и они его скажем так, "взломали". Поэтому у них все красиво. Или наоборот - программисты наловчились взламывать все KPI, которые придумывают для измерения их производительности, и поэтому все попытки измерения проваливаются - KPI растет, а работа стоит.
Таким же образом можно замерять эффективность любой сколь-либо повторяемой и стандартизируемой работы.
Конечно. Вся проблема в той части разработчиков, которые занимаются другой работой.
Во-первых, перевод этого текста тут уже был. А во-вторых, вот смотрите:
Почему продажи и HR могут так точно измерять производительность?
Представим себе, что HR заняты наймом программистов. В чем измеряется производительность HR в этом случае? Если авторы измеряют ее в штуках нанятых программистов в единицу времени, то у меня для них неприятные новости - они могли нанять совсем не тех людей, какие были нужны (я понимаю, что это не целиком их ответственность, но все же).
То есть, чтобы как следует измерить производительность HR, мы должны оценить качество тех самых программистов, что они наняли. Таким образом задача практически сводится к предыдущей, и мы понимаем, что никакой простой оценки производительности HR в чуть менее тривиальном случае не существует. Количественно их работу оценить можно, а вот качественно - фиг.
В ФП выделяется побочный эффект в самом общем виде, и к нему относятся и кафка, и база, и любое другое взаимодействие. Но если вам привычнее или удобнее формулировки типа SRP - ну можно и так назвать. Как по мне - это одни и те же идеи, по большому счету. Какие-то более абстрактные, какие-то для более частного случая.
Я вам больше скажу - то что вы предлагаете, называется разделение кода на чистые функции и IO. Что широко практикуется в функциональном программировании.
И оно имеет в том числе те очевидные плюсы, что вы только что описали - некий метод (функция) создания объекта, или его обработки, не зависит ни от какой кафки и ни от какой базы - и поэтому нормально тестируется. А те методы (функции), которые зависят от кафки или базы - не содержат никакой логики.
Primary key — это не поле и не набор полей, это ограничение таблицы (constraint)
И еще их может быть несколько (unique). И еще оно может быть выключено. Из чего автоматически следует, что значения в колонках не будут уникальными, и потом при включении constraint произойдет что-либо типа валидации.
Это как-то противоречит тому, что я написал? Хотелки - они могут эволюционировать как угодно, я лишь говорю о том, что так как (или потому что) вы хотелки бизнеса предсказать не можете, все ваши прогнозы как разработчика сроков и стоимости гроша ломаного не стоят. И из этого даже не следует, что вы плохо прогнозируете сроки, или заказчик такой плохой - оба нормальные, просто потребности бизнеса быстро развиваются.
Ну то есть, когда вам заказали первую деревянную лодочку, вы не сможете заказчику сразу сказать "а вот контейнеровоз вам будет стоить столько-то" - в том числе и потому, что вы вероятно никогда не строили контейнеровозы-то.
Ну он не всегда понимает, что заплатит, и сколько. Заплатить позже - это как раз хорошо, плохо что оценить эти завтрашние траты сложно. Никто ему не скажет скорее всего, что вот щас мы напишем говнокод, который ты завтра выкинешь. Если же скажут, и это будет сознательное решение - то говнокод сегодня и затраты на рефакторинг завтра - вполне себе решение.
Я бы сказал что в РФ на сегодня для программиста 9 миллионов это где-то на грани возможного. Ну т.е. если хочется больше - то из программистов все равно нужно уходить.
А кто-то любит такие статьи? Как по мне, значительная доля таких статей - это антинаучный бред опровергателей физики, аэродинамики, что там у нас еще опровергали? Я не хочу сказать, что они не нужны, но они выбиваются из общего стиля.
Ну чтоб далеко не ходить: "Дорожная карта основных HR-исследований" - уже упоминали. Этот корпоративный блог характерен тем, что там числится с десяток (по-моему штук 13) авторов (при том что про компанию написано, что в ней менее 10 человек ;), но при этом стиль всех без исключения статей - ну прямо бюрократический 10 из 10. И одинаковый.
Вообще, когда меня учили делать презентации, как раз рекомендовали повторять тезисы. Т.е. минимум пару раз, чтобы лучше дошло и запомнилось. Так что три - это не так уж и много :) А два по некоторым критериям считается полезным.
Понятно что мнение реально разное, но и такое есть. К сожалению, довольно часто впечатление от статей (а особенно новостей) публикуемых сотрудниками Хабра именно что неотличимо от продукта нейросетей. Ну т.е. может оно и написано человеком, а результат тот же. И я даже подозреваю, почему - по той же причине, по которой статьи обычных авторов (на интересную автору тему, которую он знает хорошо) отличаются от статей корпоративных блогов, у авторов которых нет темы, и которые (авторы) по сути т.н. копирайтеры.
Да не, я немного не про то. Я лишь утверждаю, что обобщение конкретных фактов на все ИТ компании (а автор никак не ограничивает свое обобщение) некорректно. Ну т.е. выдумки не то что в Яндексе собеседования стрессовые, а в том что у остальных так же. При этом российское ИТ вообще вот ни разу не ограничено тремя упомянутыми.
То есть, я ваше утверждение, что есть нормальные компании, вообще не опровергаю. У меня в команде такое же собеседование - одно. Со мной, как техлидом, кем-то из команды, в присутствии HR. И все - решение принимается на нем же, в крайнем случае - после него.
Пардон, но этот опыт нельзя распространять на всех. А там между прочим многоточие - т.е. автор утверждает, что это везде так. Я вот даже про те компании, где работал, не возьмусь обобщать, потому что собеседовался я всегда в проект, и никаких стандартов собеседования никогда в глаза не видел. Т.е. конечно можно верить, что у всех как у Яндекса, но реально такая вера основана только на тех фактах, что вы сами видели или слышали из первых уст.
Я вот тоже работаю в российской ИТ компании, что вы можете сказать про наши собеседования? Подозреваю что не зная про наш проект - ничего. Вот я просто призываю не обобщать так.
Не хуже чем что? Вот смотрите сюда, цитата из этого вот текста:
При устройстве аналитиком в российские IT-компании (Яндекс, Авито, Тинькофф, ...) количество технических собеседований может варьироваться (по нашим оценкам от 2 до 7), но минимум два по алгоритмам и математике пройти придётся.
Так я вам не скажу за все компании, но я практически уверен, что это вот выдумки. Просто потому, что автору такую (правдивую) информацию взять негде.
Зачем понадобилось писать велосипед, когда уже существуют Maven и Gradle? Конкретной причины нет, мне просто нравится писать код.
Это, кстати, вернейший путь к провалу проекта. Ничего не имею против попытки создать сборщик, ни один из существующих не идеален, но потребности должны быть учтены в первую очередь.
Скажем, мы хотим файл проекта как у мавена, т.е. статический, но более читабельный для человека, и чтобы писать было проще. Чтобы его можно было обрабатывать любым инструментом, и не требовалось выполнять код сборщика, чтобы получить скажем список зависимостей.
Насколько это реально полезно - вопрос второй, но сразу возникает вопрос первый - вот команда мавена в свое время (причем очень давно) сделала проект полиглот, с теми же примерно целями. И много вы видели файлов, написанных в синтаксисе, отличном от штатного pom.xml? Я - ни одного. То есть, даже если такая потребность и была, она настолько несущественна, что никто этим не пользуется.
Можете. Но на вопросы по коду вы не заучите ответы. Не могу исключить, что где-то это прокатит, но в среднем вы засыплетесь на первом-втором вопросе: "а нахрена вы вот так тут написали".
Не, я согласен что я слегка упрощаю. Да, упрощаю - чтобы яснее продемонстрировать мысль. На самом деле в оригинале же написано просто - почему HR могут так точно измерять производительность? При этом практически ничего не сказано о том, как они ее измеряют, и какова на самом деле точность. Я призываю, если угодно, таким вот утверждениям без доказательства не верить. Вполне возможно, что у HR простой KPI, и они его скажем так, "взломали". Поэтому у них все красиво. Или наоборот - программисты наловчились взламывать все KPI, которые придумывают для измерения их производительности, и поэтому все попытки измерения проваливаются - KPI растет, а работа стоит.
Конечно. Вся проблема в той части разработчиков, которые занимаются другой работой.
Во-первых, перевод этого текста тут уже был. А во-вторых, вот смотрите:
Представим себе, что HR заняты наймом программистов. В чем измеряется производительность HR в этом случае? Если авторы измеряют ее в штуках нанятых программистов в единицу времени, то у меня для них неприятные новости - они могли нанять совсем не тех людей, какие были нужны (я понимаю, что это не целиком их ответственность, но все же).
То есть, чтобы как следует измерить производительность HR, мы должны оценить качество тех самых программистов, что они наняли. Таким образом задача практически сводится к предыдущей, и мы понимаем, что никакой простой оценки производительности HR в чуть менее тривиальном случае не существует. Количественно их работу оценить можно, а вот качественно - фиг.
В ФП выделяется побочный эффект в самом общем виде, и к нему относятся и кафка, и база, и любое другое взаимодействие. Но если вам привычнее или удобнее формулировки типа SRP - ну можно и так назвать. Как по мне - это одни и те же идеи, по большому счету. Какие-то более абстрактные, какие-то для более частного случая.
Ну, строго говоря, некоторые и не такие уж новые. Скажем, упомянутый в тексте нитинол это 1963 год. Т.е. мне про него еще в институте рассказывали.
Я вам больше скажу - то что вы предлагаете, называется разделение кода на чистые функции и IO. Что широко практикуется в функциональном программировании.
И оно имеет в том числе те очевидные плюсы, что вы только что описали - некий метод (функция) создания объекта, или его обработки, не зависит ни от какой кафки и ни от какой базы - и поэтому нормально тестируется. А те методы (функции), которые зависят от кафки или базы - не содержат никакой логики.
И еще их может быть несколько (unique). И еще оно может быть выключено. Из чего автоматически следует, что значения в колонках не будут уникальными, и потом при включении constraint произойдет что-либо типа валидации.
Это как-то противоречит тому, что я написал? Хотелки - они могут эволюционировать как угодно, я лишь говорю о том, что так как (или потому что) вы хотелки бизнеса предсказать не можете, все ваши прогнозы как разработчика сроков и стоимости гроша ломаного не стоят. И из этого даже не следует, что вы плохо прогнозируете сроки, или заказчик такой плохой - оба нормальные, просто потребности бизнеса быстро развиваются.
Ну то есть, когда вам заказали первую деревянную лодочку, вы не сможете заказчику сразу сказать "а вот контейнеровоз вам будет стоить столько-то" - в том числе и потому, что вы вероятно никогда не строили контейнеровозы-то.
Ну он не всегда понимает, что заплатит, и сколько. Заплатить позже - это как раз хорошо, плохо что оценить эти завтрашние траты сложно. Никто ему не скажет скорее всего, что вот щас мы напишем говнокод, который ты завтра выкинешь. Если же скажут, и это будет сознательное решение - то говнокод сегодня и затраты на рефакторинг завтра - вполне себе решение.
Это он щас доволен. А завтра он придет и попросит еще фичи. И это говнище вылезет ему боком. Не бывает чтобы все всегда просто.
Я бы сказал что в РФ на сегодня для программиста 9 миллионов это где-то на грани возможного. Ну т.е. если хочется больше - то из программистов все равно нужно уходить.
Ну я согласен, без текста это не особо имеет смысл.
А кто-то любит такие статьи? Как по мне, значительная доля таких статей - это антинаучный бред опровергателей физики, аэродинамики, что там у нас еще опровергали? Я не хочу сказать, что они не нужны, но они выбиваются из общего стиля.
Ну чтоб далеко не ходить: "Дорожная карта основных HR-исследований" - уже упоминали. Этот корпоративный блог характерен тем, что там числится с десяток (по-моему штук 13) авторов (при том что про компанию написано, что в ней менее 10 человек ;), но при этом стиль всех без исключения статей - ну прямо бюрократический 10 из 10. И одинаковый.
Вообще, когда меня учили делать презентации, как раз рекомендовали повторять тезисы. Т.е. минимум пару раз, чтобы лучше дошло и запомнилось. Так что три - это не так уж и много :) А два по некоторым критериям считается полезным.
Понятно что мнение реально разное, но и такое есть. К сожалению, довольно часто впечатление от статей (а особенно новостей) публикуемых сотрудниками Хабра именно что неотличимо от продукта нейросетей. Ну т.е. может оно и написано человеком, а результат тот же. И я даже подозреваю, почему - по той же причине, по которой статьи обычных авторов (на интересную автору тему, которую он знает хорошо) отличаются от статей корпоративных блогов, у авторов которых нет темы, и которые (авторы) по сути т.н. копирайтеры.
Да не, я немного не про то. Я лишь утверждаю, что обобщение конкретных фактов на все ИТ компании (а автор никак не ограничивает свое обобщение) некорректно. Ну т.е. выдумки не то что в Яндексе собеседования стрессовые, а в том что у остальных так же. При этом российское ИТ вообще вот ни разу не ограничено тремя упомянутыми.
То есть, я ваше утверждение, что есть нормальные компании, вообще не опровергаю. У меня в команде такое же собеседование - одно. Со мной, как техлидом, кем-то из команды, в присутствии HR. И все - решение принимается на нем же, в крайнем случае - после него.
Пардон, но этот опыт нельзя распространять на всех. А там между прочим многоточие - т.е. автор утверждает, что это везде так. Я вот даже про те компании, где работал, не возьмусь обобщать, потому что собеседовался я всегда в проект, и никаких стандартов собеседования никогда в глаза не видел. Т.е. конечно можно верить, что у всех как у Яндекса, но реально такая вера основана только на тех фактах, что вы сами видели или слышали из первых уст.
Я вот тоже работаю в российской ИТ компании, что вы можете сказать про наши собеседования? Подозреваю что не зная про наш проект - ничего. Вот я просто призываю не обобщать так.
Не хуже чем что? Вот смотрите сюда, цитата из этого вот текста:
Так я вам не скажу за все компании, но я практически уверен, что это вот выдумки. Просто потому, что автору такую (правдивую) информацию взять негде.
Возможно я что-то не так понял, но чисто интуитивно, разве отсутствие такого предела не означало бы нарушение закона сохранения энергии?
Во втором абзаце:
Это, кстати, вернейший путь к провалу проекта. Ничего не имею против попытки создать сборщик, ни один из существующих не идеален, но потребности должны быть учтены в первую очередь.
Скажем, мы хотим файл проекта как у мавена, т.е. статический, но более читабельный для человека, и чтобы писать было проще. Чтобы его можно было обрабатывать любым инструментом, и не требовалось выполнять код сборщика, чтобы получить скажем список зависимостей.
Насколько это реально полезно - вопрос второй, но сразу возникает вопрос первый - вот команда мавена в свое время (причем очень давно) сделала проект полиглот, с теми же примерно целями. И много вы видели файлов, написанных в синтаксисе, отличном от штатного pom.xml? Я - ни одного. То есть, даже если такая потребность и была, она настолько несущественна, что никто этим не пользуется.