Меня всегда несколько удивляет подобная аргументация: смотрите, как было, значит, так же и будет! Ну не смогли ERwin или SQL заменить разработчиков, это факт, но почему Вы так уверены, что с нейронками ситуация повторится? Вы умеете предсказывать будущее?
Сам я, если что, ни "за", ни "против", я просто не знаю будущего, поэтому ничего утверждать не могу.
Никакого снобизма и клоунады, всё абсолютно искренне.
сам собой приходит из ООП
Большинство разработчиков уровня джун/мидл, с которыми мне приходилось сталкиваться, не знали ничего про SOLID и в результате писали говнокод. После обучения становилось сильно лучше. Так что не надо про "сам собой".
что вы в очевидных вещах оперируете придуманными аббревиатурами, для знания которых мне нужно дополнительно что-то прочитать
Ещё раз - если Вы сами дошли до открытия этих принципов - Вы молодец (без сарказма), но таковые далеко не все. Но даже в Вашем случае допустимо не знать эти аббревиатуры, только если Вы работаете в полном одиночестве.
Знание всех этих аббревиатур, а также паттернов разработки, в первую очередь полезно тем, что создаёт для всех единый язык разработки. Если два человека знают принципы, но не знают эту терминологию, они очень долго будут друг другу объяснять, что же имеют в виду.
То, что Вы называете "зазубривание", очень облегчает общение между разработчиками.
Фразу "посмотрите мой ПР, я там интерфейсы разбил ради ISP" можно, конечно, и по-другому сформулировать, но получится значительно длиннее и не факт, что понятно будет.
Мне тут минусов накидали: я правильно понимаю, что соблюдать принцип единственной ответственности - это зло? Хм, странно. Весь мой опыт показывает, что несоблюдение этого принципа гарантировано приводит к проблемам, так же, как и несоблюдение DRY. Ну ОК, возможно, некоторые любят боль...
В моей Вселенной для поиска ошибок придумали отладку (debug). Искать причину баги глазами по коду??? Увольте.
производительность и эффективность на первом месте
Ну значит у Вас вот такие специфические системы в разработке. Такие, как я уже писал выше, есть, но, с моей точки зрения их меньшинство. Наверное потому, что сам я тоже в разработке много лет и ни разу такое создавать не приходилось.
Он пишет что нужно сделать, а как это сделать наиболее эффективным способом - это уже задача разработчика.
Конечно, именно это и есть роли аналитика (написать требования) и разработчика (написать код). Но почему при этом надо требования (ТЗ) запихивать в код в виде комментариев - мне решительно непонятно. Если при чтении кода у меня возникнет вопрос, почему используются именно A, B, C и не используются D, E, F - я открою постановку и прочитаю там. Замусоривать код лишней информацией вообще ни к чему.
По своему личному опыту (ни в коем случае не намекаю на Вас, я Вас не знаю и выводов никаких делать не могу) – комментарии тянет писать тех разработчиков, которые не умеют в нормальный нейминг и декомпозицию. Не удалось выразить свои намерения через код - пишем комменты.
На одном из проектов, где я техлидил, комментарии были просто запрещены (с парой исключений), и при этом никто не страдал, в том числе новички, код был ясен и понятен.
Когда пишется что-то реально объемное и реально сложное, каждые 2-3 строки в метод выносить - только запутывать код
Неправда. Если вы даёте методам осмысленные, качественные имена, код становится сильно понятнее.
Не говоря уже о том, что это снижение производительности
Производительность и качество кода (понятность, сопровождаемость и т.д.) – вещи чаще всего взаимоисключающие, либо быстрый код, либо понятный.
К счастью, производительность требуется достаточно редко – я не говорю о каких-то крайних применениях ПО - управление производством, геймдев и т.д., а об "обычных" системах. Поэтому при написании кода обязательно стараемся соблюдать его качество, о производительности не думаем – пока не прилетит соответствующая задача :).
И всегда останется вопрос - почему в методе needClientSendNotification эта самая необходимость проверяется именно по признакам А, Б и В именно в этой таблице, на не признакам Г, Д и Е в другой таблице (потому что можно и так и этак).
Ну т.е. Вы предлагаете в код в виде комментариев вносить требования (ТЗ)? Ну это такое.
Требования всегда есть в виде отдельной документации, именно туда надо ходить и смотреть – почему это устроено именно так, а не иначе.
Подсвечиваю: странная любовь к запятым, в первых трёх абзацах штук восемь лишних. Хотя нескольких не хватает, так что любовь ли это?
Никогда не работал с "проверялками", но мне кажется, что вряд ли они смогут за Вас выбрать правильный вариант из "смирится"/"смириться", т.к. оба эти слова есть в русском языке. Но используются в разных случаях.
Я не знаю. Именно потому, что задачи, которые я решаю, не требуют ручной оптимизации.
И когда я написал "требует оптимизации на уровне регистров и кеша процессора", я имел в виду усилия со стороны программиста. Если компилятор там чего-то оптимизирует автоматически, без моего участия - да пожалуйста.
Я под него подстраиваться и писать код так, чтоб он соптимизировал, не буду. Пока, конечно, не придут такие требования со стороны бизнеса.
До сих пор это не требовалось никогда, несмотря на то, что я в профессии не один год. И очень сильно подозреваю, что таких задач - подавляющее большинство. Именно поэтому я и написал про "1%". А требовать от меня каких-то формул или методики подсчёта процентов может только человек, который никогда не сталкивался с понятием "образное выражение".
P.S. На самом деле я подозреваю, что таких задач сильно меньше одного процента. Но Вы, конечно, имеете полное право придерживаться иной точки зрения.
От силы 1% кода, который пишется, требует оптимизации на уровне регистров и кеша процессора. При этом 100% кода читается и модифицируется.
Так что критерии читабельности и поддерживаемости значительно превалируют.
И часто критична (ну или хотя бы очень важна) скорость написания кода. Что быстрее – воткнуть один if или анализировать вызовы функции на предмет "отфильтровать/поделить" и затем заниматься изменением дизайна кода?
Может, я неправильно понял. Есть функция с одним if, которая вызывается 15 раз. Предлагается этот if вынести в вызывающий код, и у нас станет 15 if вместо одного?
Ну если бы фраза применялась в этом узком контексте (стать владельцем бизнеса), то да, согласен. Но ведь очень часто её употребляют, когда речь идёт о повышении (в должности, в зарплате и т.д.), о карьерных перспективах вообще.
Эту фразу, к моему большому изумлению, приводят очень часто, хотя она совершенно дурацкая – лошадь в принципе не может стать председателем колхоза, независимо от её модели поведения.
Я согласен, что нет прямой зависимости "много и хорошо работаешь => будешь иметь карьерный рост", но изобретите какой-нибудь другой, более правдоподобный, мем, оставьте бедную лошадь в покое...
Упомянутое Вами «уметь объяснять» - вот это как раз и есть педагогический талант, далеко не каждому дано. (И при чём здесь мудак/не мудак? Вещи ортогональные.) Я за четверть века преподавания всяких насмотрелся, поверьте.
Конечно, «замотивированный» и «1-на-1» задачу упрощает, но и в такой ситуации не каждый справится.
Передёргиваете :)
Если что-то (например, восход Солнца) повторяется сотни и тысячи раз каждый день, то вероятность, что это произойдёт снова, очень велика.
Если что-то произошло пару раз и с интервалом в 10-20-30 лет, то уверенности, что это обязательно случится и в третий раз, нет никакой.
Меня всегда несколько удивляет подобная аргументация: смотрите, как было, значит, так же и будет! Ну не смогли ERwin или SQL заменить разработчиков, это факт, но почему Вы так уверены, что с нейронками ситуация повторится? Вы умеете предсказывать будущее?
Сам я, если что, ни "за", ни "против", я просто не знаю будущего, поэтому ничего утверждать не могу.
Никакого снобизма и клоунады, всё абсолютно искренне.
Большинство разработчиков уровня джун/мидл, с которыми мне приходилось сталкиваться, не знали ничего про SOLID и в результате писали говнокод. После обучения становилось сильно лучше. Так что не надо про "сам собой".
Ещё раз - если Вы сами дошли до открытия этих принципов - Вы молодец (без сарказма), но таковые далеко не все. Но даже в Вашем случае допустимо не знать эти аббревиатуры, только если Вы работаете в полном одиночестве.
Знание всех этих аббревиатур, а также паттернов разработки, в первую очередь полезно тем, что создаёт для всех единый язык разработки. Если два человека знают принципы, но не знают эту терминологию, они очень долго будут друг другу объяснять, что же имеют в виду.
То, что Вы называете "зазубривание", очень облегчает общение между разработчиками.
Фразу "посмотрите мой ПР, я там интерфейсы разбил ради ISP" можно, конечно, и по-другому сформулировать, но получится значительно длиннее и не факт, что понятно будет.
Мне тут минусов накидали: я правильно понимаю, что соблюдать принцип единственной ответственности - это зло? Хм, странно. Весь мой опыт показывает, что несоблюдение этого принципа гарантировано приводит к проблемам, так же, как и несоблюдение DRY.
Ну ОК, возможно, некоторые любят боль...
Если для Вас SOLID - это просто набор букв, представляю, какой говнокод Вы пишите.
В моей Вселенной для поиска ошибок придумали отладку (debug). Искать причину баги глазами по коду??? Увольте.
Ну значит у Вас вот такие специфические системы в разработке. Такие, как я уже писал выше, есть, но, с моей точки зрения их меньшинство. Наверное потому, что сам я тоже в разработке много лет и ни разу такое создавать не приходилось.
Конечно, именно это и есть роли аналитика (написать требования) и разработчика (написать код). Но почему при этом надо требования (ТЗ) запихивать в код в виде комментариев - мне решительно непонятно. Если при чтении кода у меня возникнет вопрос, почему используются именно A, B, C и не используются D, E, F - я открою постановку и прочитаю там. Замусоривать код лишней информацией вообще ни к чему.
По своему личному опыту (ни в коем случае не намекаю на Вас, я Вас не знаю и выводов никаких делать не могу) – комментарии тянет писать тех разработчиков, которые не умеют в нормальный нейминг и декомпозицию. Не удалось выразить свои намерения через код - пишем комменты.
На одном из проектов, где я техлидил, комментарии были просто запрещены (с парой исключений), и при этом никто не страдал, в том числе новички, код был ясен и понятен.
Неправда. Если вы даёте методам осмысленные, качественные имена, код становится сильно понятнее.
Производительность и качество кода (понятность, сопровождаемость и т.д.) – вещи чаще всего взаимоисключающие, либо быстрый код, либо понятный.
К счастью, производительность требуется достаточно редко – я не говорю о каких-то крайних применениях ПО - управление производством, геймдев и т.д., а об "обычных" системах. Поэтому при написании кода обязательно стараемся соблюдать его качество, о производительности не думаем – пока не прилетит соответствующая задача :).
Ну т.е. Вы предлагаете в код в виде комментариев вносить требования (ТЗ)? Ну это такое.
Требования всегда есть в виде отдельной документации, именно туда надо ходить и смотреть – почему это устроено именно так, а не иначе.
Хм, так вот ты какое - Замкадье!
Расстояние от Москвы до Калининграда по прямой - 1089 км. Если "несколько тысяч на запад", то это Атлантика.
Stamina и VerseQ.
Я, как стопроцентный жаворонок, надеюсь, что Вы пошутили.
Подсвечиваю: странная любовь к запятым, в первых трёх абзацах штук восемь лишних. Хотя нескольких не хватает, так что любовь ли это?
Никогда не работал с "проверялками", но мне кажется, что вряд ли они смогут за Вас выбрать правильный вариант из "смирится"/"смириться", т.к. оба эти слова есть в русском языке. Но используются в разных случаях.
Теперь и в FireFox.
Я не знаю. Именно потому, что задачи, которые я решаю, не требуют ручной оптимизации.
И когда я написал "требует оптимизации на уровне регистров и кеша процессора", я имел в виду усилия со стороны программиста. Если компилятор там чего-то оптимизирует автоматически, без моего участия - да пожалуйста.
Я под него подстраиваться и писать код так, чтоб он соптимизировал, не буду. Пока, конечно, не придут такие требования со стороны бизнеса.
До сих пор это не требовалось никогда, несмотря на то, что я в профессии не один год. И очень сильно подозреваю, что таких задач - подавляющее большинство. Именно поэтому я и написал про "1%".
А требовать от меня каких-то формул или методики подсчёта процентов может только человек, который никогда не сталкивался с понятием "образное выражение".
P.S. На самом деле я подозреваю, что таких задач сильно меньше одного процента. Но Вы, конечно, имеете полное право придерживаться иной точки зрения.
Вопрос: если я пишу бекенд на Python, я какой процент кода оптимизирую на уровне регистров и кеша процессора?
Вы резко сузили кейс (от "весь код" до "игра на C++") - и что этим пытаетесь доказать?
От силы 1% кода, который пишется, требует оптимизации на уровне регистров и кеша процессора. При этом 100% кода читается и модифицируется.
Так что критерии читабельности и поддерживаемости значительно превалируют.
И часто критична (ну или хотя бы очень важна) скорость написания кода. Что быстрее – воткнуть один
ifили анализировать вызовы функции на предмет "отфильтровать/поделить" и затем заниматься изменением дизайна кода?Может, я неправильно понял.
Есть функция с одним
if, которая вызывается 15 раз.Предлагается этот
ifвынести в вызывающий код, и у нас станет 15ifвместо одного?Ну если бы фраза применялась в этом узком контексте (стать владельцем бизнеса), то да, согласен.
Но ведь очень часто её употребляют, когда речь идёт о повышении (в должности, в зарплате и т.д.), о карьерных перспективах вообще.
Эту фразу, к моему большому изумлению, приводят очень часто, хотя она совершенно дурацкая – лошадь в принципе не может стать председателем колхоза, независимо от её модели поведения.
Я согласен, что нет прямой зависимости "много и хорошо работаешь => будешь иметь карьерный рост", но изобретите какой-нибудь другой, более правдоподобный, мем, оставьте бедную лошадь в покое...
Упомянутое Вами «уметь объяснять» - вот это как раз и есть педагогический талант, далеко не каждому дано. (И при чём здесь мудак/не мудак? Вещи ортогональные.) Я за четверть века преподавания всяких насмотрелся, поверьте.
Конечно, «замотивированный» и «1-на-1» задачу упрощает, но и в такой ситуации не каждый справится.