Девушка, Вы живёте в волшебной стране под названием «ВозможноВсё»? Вот Вам кейс (и таких я могу привести десятки): некая женщина получает удовольствие от того, что возится с малышами, и потому работает воспитателем в детском саду. Расскажите, пожалуйста, как ей зарабатывать много, сохраняя удовольствие от работы? И не забудьте, что этот способ должен быть масштабируемым, т.к. в России сотни тысяч педагогов дошкольного образования. Передавайте привет единорогам :)
Если работа по призванию приносит денег в три раза меньше, чем текущая (мучительная), а у тебя семья/ипотека -- Вы предлагаете двигаться за удовольствием? Ну-ну.
Три месяца решали мою проблему, при этом каждый сеанс общения в чате с техподдержкой оставлял после себя полную уверенность, что у них главный KPI – как можно больше издеваться над пользователями. Ответы на все вопросы – абстрактные фразы ни о чём, причём одни и те же – явно берутся из текстовика и копируются в чат. Причём так как список фраз не очень большой, то очень скоро общение уходит на второй круг, а можно и до третьего добраться в рамках одной сессии общения. Хоть сколько-нибудь полезной информации вообще не было.
И так каждый раз, когда я пытался прояснить ситуацию.
Ну и в качестве вишенки на торте – раз в месяц присылали сообщение "Поздравляем! Ваша задача взята в работу!" – оценка десять из десяти по дисциплине "Издевательство".
Меня всегда несколько удивляет подобная аргументация: смотрите, как было, значит, так же и будет! Ну не смогли ERwin или SQL заменить разработчиков, это факт, но почему Вы так уверены, что с нейронками ситуация повторится? Вы умеете предсказывать будущее?
Сам я, если что, ни "за", ни "против", я просто не знаю будущего, поэтому ничего утверждать не могу.
Никакого снобизма и клоунады, всё абсолютно искренне.
сам собой приходит из ООП
Большинство разработчиков уровня джун/мидл, с которыми мне приходилось сталкиваться, не знали ничего про SOLID и в результате писали говнокод. После обучения становилось сильно лучше. Так что не надо про "сам собой".
что вы в очевидных вещах оперируете придуманными аббревиатурами, для знания которых мне нужно дополнительно что-то прочитать
Ещё раз - если Вы сами дошли до открытия этих принципов - Вы молодец (без сарказма), но таковые далеко не все. Но даже в Вашем случае допустимо не знать эти аббревиатуры, только если Вы работаете в полном одиночестве.
Знание всех этих аббревиатур, а также паттернов разработки, в первую очередь полезно тем, что создаёт для всех единый язык разработки. Если два человека знают принципы, но не знают эту терминологию, они очень долго будут друг другу объяснять, что же имеют в виду.
То, что Вы называете "зазубривание", очень облегчает общение между разработчиками.
Фразу "посмотрите мой ПР, я там интерфейсы разбил ради ISP" можно, конечно, и по-другому сформулировать, но получится значительно длиннее и не факт, что понятно будет.
Мне тут минусов накидали: я правильно понимаю, что соблюдать принцип единственной ответственности - это зло? Хм, странно. Весь мой опыт показывает, что несоблюдение этого принципа гарантировано приводит к проблемам, так же, как и несоблюдение DRY. Ну ОК, возможно, некоторые любят боль...
В моей Вселенной для поиска ошибок придумали отладку (debug). Искать причину баги глазами по коду??? Увольте.
производительность и эффективность на первом месте
Ну значит у Вас вот такие специфические системы в разработке. Такие, как я уже писал выше, есть, но, с моей точки зрения их меньшинство. Наверное потому, что сам я тоже в разработке много лет и ни разу такое создавать не приходилось.
Он пишет что нужно сделать, а как это сделать наиболее эффективным способом - это уже задача разработчика.
Конечно, именно это и есть роли аналитика (написать требования) и разработчика (написать код). Но почему при этом надо требования (ТЗ) запихивать в код в виде комментариев - мне решительно непонятно. Если при чтении кода у меня возникнет вопрос, почему используются именно A, B, C и не используются D, E, F - я открою постановку и прочитаю там. Замусоривать код лишней информацией вообще ни к чему.
По своему личному опыту (ни в коем случае не намекаю на Вас, я Вас не знаю и выводов никаких делать не могу) – комментарии тянет писать тех разработчиков, которые не умеют в нормальный нейминг и декомпозицию. Не удалось выразить свои намерения через код - пишем комменты.
На одном из проектов, где я техлидил, комментарии были просто запрещены (с парой исключений), и при этом никто не страдал, в том числе новички, код был ясен и понятен.
Когда пишется что-то реально объемное и реально сложное, каждые 2-3 строки в метод выносить - только запутывать код
Неправда. Если вы даёте методам осмысленные, качественные имена, код становится сильно понятнее.
Не говоря уже о том, что это снижение производительности
Производительность и качество кода (понятность, сопровождаемость и т.д.) – вещи чаще всего взаимоисключающие, либо быстрый код, либо понятный.
К счастью, производительность требуется достаточно редко – я не говорю о каких-то крайних применениях ПО - управление производством, геймдев и т.д., а об "обычных" системах. Поэтому при написании кода обязательно стараемся соблюдать его качество, о производительности не думаем – пока не прилетит соответствующая задача :).
И всегда останется вопрос - почему в методе needClientSendNotification эта самая необходимость проверяется именно по признакам А, Б и В именно в этой таблице, на не признакам Г, Д и Е в другой таблице (потому что можно и так и этак).
Ну т.е. Вы предлагаете в код в виде комментариев вносить требования (ТЗ)? Ну это такое.
Требования всегда есть в виде отдельной документации, именно туда надо ходить и смотреть – почему это устроено именно так, а не иначе.
Подсвечиваю: странная любовь к запятым, в первых трёх абзацах штук восемь лишних. Хотя нескольких не хватает, так что любовь ли это?
Никогда не работал с "проверялками", но мне кажется, что вряд ли они смогут за Вас выбрать правильный вариант из "смирится"/"смириться", т.к. оба эти слова есть в русском языке. Но используются в разных случаях.
Девушка, Вы живёте в волшебной стране под названием «ВозможноВсё»?
Вот Вам кейс (и таких я могу привести десятки): некая женщина получает удовольствие от того, что возится с малышами, и потому работает воспитателем в детском саду. Расскажите, пожалуйста, как ей зарабатывать много, сохраняя удовольствие от работы?
И не забудьте, что этот способ должен быть масштабируемым, т.к. в России сотни тысяч педагогов дошкольного образования.
Передавайте привет единорогам :)
Смешно.
Если работа по призванию приносит денег в три раза меньше, чем текущая (мучительная), а у тебя семья/ипотека -- Вы предлагаете двигаться за удовольствием? Ну-ну.
А ссылку на курс можно? В списке бесплатных не видать.
НН – Неискусственный Неинтелект.
Техподдержка в Okko – это абсолютное дно.
Три месяца решали мою проблему, при этом каждый сеанс общения в чате с техподдержкой оставлял после себя полную уверенность, что у них главный KPI – как можно больше издеваться над пользователями. Ответы на все вопросы – абстрактные фразы ни о чём, причём одни и те же – явно берутся из текстовика и копируются в чат. Причём так как список фраз не очень большой, то очень скоро общение уходит на второй круг, а можно и до третьего добраться в рамках одной сессии общения. Хоть сколько-нибудь полезной информации вообще не было.
И так каждый раз, когда я пытался прояснить ситуацию.
Ну и в качестве вишенки на торте – раз в месяц присылали сообщение "Поздравляем! Ваша задача взята в работу!" – оценка десять из десяти по дисциплине "Издевательство".
Что такое "точка сталкивания"?
/режим душнилы on
Оклад 268 308 руб.
Моё высшее математическое категорически не согласно.
/режим душнилы off
Перевод этой статьи уже был недавно: https://habr.com/ru/articles/948072/
Передёргиваете :)
Если что-то (например, восход Солнца) повторяется сотни и тысячи раз каждый день, то вероятность, что это произойдёт снова, очень велика.
Если что-то произошло пару раз и с интервалом в 10-20-30 лет, то уверенности, что это обязательно случится и в третий раз, нет никакой.
Меня всегда несколько удивляет подобная аргументация: смотрите, как было, значит, так же и будет! Ну не смогли ERwin или SQL заменить разработчиков, это факт, но почему Вы так уверены, что с нейронками ситуация повторится? Вы умеете предсказывать будущее?
Сам я, если что, ни "за", ни "против", я просто не знаю будущего, поэтому ничего утверждать не могу.
Никакого снобизма и клоунады, всё абсолютно искренне.
Большинство разработчиков уровня джун/мидл, с которыми мне приходилось сталкиваться, не знали ничего про SOLID и в результате писали говнокод. После обучения становилось сильно лучше. Так что не надо про "сам собой".
Ещё раз - если Вы сами дошли до открытия этих принципов - Вы молодец (без сарказма), но таковые далеко не все. Но даже в Вашем случае допустимо не знать эти аббревиатуры, только если Вы работаете в полном одиночестве.
Знание всех этих аббревиатур, а также паттернов разработки, в первую очередь полезно тем, что создаёт для всех единый язык разработки. Если два человека знают принципы, но не знают эту терминологию, они очень долго будут друг другу объяснять, что же имеют в виду.
То, что Вы называете "зазубривание", очень облегчает общение между разработчиками.
Фразу "посмотрите мой ПР, я там интерфейсы разбил ради ISP" можно, конечно, и по-другому сформулировать, но получится значительно длиннее и не факт, что понятно будет.
Мне тут минусов накидали: я правильно понимаю, что соблюдать принцип единственной ответственности - это зло? Хм, странно. Весь мой опыт показывает, что несоблюдение этого принципа гарантировано приводит к проблемам, так же, как и несоблюдение DRY.
Ну ОК, возможно, некоторые любят боль...
Если для Вас SOLID - это просто набор букв, представляю, какой говнокод Вы пишите.
В моей Вселенной для поиска ошибок придумали отладку (debug). Искать причину баги глазами по коду??? Увольте.
Ну значит у Вас вот такие специфические системы в разработке. Такие, как я уже писал выше, есть, но, с моей точки зрения их меньшинство. Наверное потому, что сам я тоже в разработке много лет и ни разу такое создавать не приходилось.
Конечно, именно это и есть роли аналитика (написать требования) и разработчика (написать код). Но почему при этом надо требования (ТЗ) запихивать в код в виде комментариев - мне решительно непонятно. Если при чтении кода у меня возникнет вопрос, почему используются именно A, B, C и не используются D, E, F - я открою постановку и прочитаю там. Замусоривать код лишней информацией вообще ни к чему.
По своему личному опыту (ни в коем случае не намекаю на Вас, я Вас не знаю и выводов никаких делать не могу) – комментарии тянет писать тех разработчиков, которые не умеют в нормальный нейминг и декомпозицию. Не удалось выразить свои намерения через код - пишем комменты.
На одном из проектов, где я техлидил, комментарии были просто запрещены (с парой исключений), и при этом никто не страдал, в том числе новички, код был ясен и понятен.
Неправда. Если вы даёте методам осмысленные, качественные имена, код становится сильно понятнее.
Производительность и качество кода (понятность, сопровождаемость и т.д.) – вещи чаще всего взаимоисключающие, либо быстрый код, либо понятный.
К счастью, производительность требуется достаточно редко – я не говорю о каких-то крайних применениях ПО - управление производством, геймдев и т.д., а об "обычных" системах. Поэтому при написании кода обязательно стараемся соблюдать его качество, о производительности не думаем – пока не прилетит соответствующая задача :).
Ну т.е. Вы предлагаете в код в виде комментариев вносить требования (ТЗ)? Ну это такое.
Требования всегда есть в виде отдельной документации, именно туда надо ходить и смотреть – почему это устроено именно так, а не иначе.
Хм, так вот ты какое - Замкадье!
Расстояние от Москвы до Калининграда по прямой - 1089 км. Если "несколько тысяч на запад", то это Атлантика.
Stamina и VerseQ.
Я, как стопроцентный жаворонок, надеюсь, что Вы пошутили.
Подсвечиваю: странная любовь к запятым, в первых трёх абзацах штук восемь лишних. Хотя нескольких не хватает, так что любовь ли это?
Никогда не работал с "проверялками", но мне кажется, что вряд ли они смогут за Вас выбрать правильный вариант из "смирится"/"смириться", т.к. оба эти слова есть в русском языке. Но используются в разных случаях.