В моей Вселенной для поиска ошибок придумали отладку (debug). Искать причину баги глазами по коду??? Увольте.
производительность и эффективность на первом месте
Ну значит у Вас вот такие специфические системы в разработке. Такие, как я уже писал выше, есть, но, с моей точки зрения их меньшинство. Наверное потому, что сам я тоже в разработке много лет и ни разу такое создавать не приходилось.
Он пишет что нужно сделать, а как это сделать наиболее эффективным способом - это уже задача разработчика.
Конечно, именно это и есть роли аналитика (написать требования) и разработчика (написать код). Но почему при этом надо требования (ТЗ) запихивать в код в виде комментариев - мне решительно непонятно. Если при чтении кода у меня возникнет вопрос, почему используются именно A, B, C и не используются D, E, F - я открою постановку и прочитаю там. Замусоривать код лишней информацией вообще ни к чему.
По своему личному опыту (ни в коем случае не намекаю на Вас, я Вас не знаю и выводов никаких делать не могу) – комментарии тянет писать тех разработчиков, которые не умеют в нормальный нейминг и декомпозицию. Не удалось выразить свои намерения через код - пишем комменты.
На одном из проектов, где я техлидил, комментарии были просто запрещены (с парой исключений), и при этом никто не страдал, в том числе новички, код был ясен и понятен.
Когда пишется что-то реально объемное и реально сложное, каждые 2-3 строки в метод выносить - только запутывать код
Неправда. Если вы даёте методам осмысленные, качественные имена, код становится сильно понятнее.
Не говоря уже о том, что это снижение производительности
Производительность и качество кода (понятность, сопровождаемость и т.д.) – вещи чаще всего взаимоисключающие, либо быстрый код, либо понятный.
К счастью, производительность требуется достаточно редко – я не говорю о каких-то крайних применениях ПО - управление производством, геймдев и т.д., а об "обычных" системах. Поэтому при написании кода обязательно стараемся соблюдать его качество, о производительности не думаем – пока не прилетит соответствующая задача :).
И всегда останется вопрос - почему в методе needClientSendNotification эта самая необходимость проверяется именно по признакам А, Б и В именно в этой таблице, на не признакам Г, Д и Е в другой таблице (потому что можно и так и этак).
Ну т.е. Вы предлагаете в код в виде комментариев вносить требования (ТЗ)? Ну это такое.
Требования всегда есть в виде отдельной документации, именно туда надо ходить и смотреть – почему это устроено именно так, а не иначе.
Подсвечиваю: странная любовь к запятым, в первых трёх абзацах штук восемь лишних. Хотя нескольких не хватает, так что любовь ли это?
Никогда не работал с "проверялками", но мне кажется, что вряд ли они смогут за Вас выбрать правильный вариант из "смирится"/"смириться", т.к. оба эти слова есть в русском языке. Но используются в разных случаях.
Я не знаю. Именно потому, что задачи, которые я решаю, не требуют ручной оптимизации.
И когда я написал "требует оптимизации на уровне регистров и кеша процессора", я имел в виду усилия со стороны программиста. Если компилятор там чего-то оптимизирует автоматически, без моего участия - да пожалуйста.
Я под него подстраиваться и писать код так, чтоб он соптимизировал, не буду. Пока, конечно, не придут такие требования со стороны бизнеса.
До сих пор это не требовалось никогда, несмотря на то, что я в профессии не один год. И очень сильно подозреваю, что таких задач - подавляющее большинство. Именно поэтому я и написал про "1%". А требовать от меня каких-то формул или методики подсчёта процентов может только человек, который никогда не сталкивался с понятием "образное выражение".
P.S. На самом деле я подозреваю, что таких задач сильно меньше одного процента. Но Вы, конечно, имеете полное право придерживаться иной точки зрения.
От силы 1% кода, который пишется, требует оптимизации на уровне регистров и кеша процессора. При этом 100% кода читается и модифицируется.
Так что критерии читабельности и поддерживаемости значительно превалируют.
И часто критична (ну или хотя бы очень важна) скорость написания кода. Что быстрее – воткнуть один if или анализировать вызовы функции на предмет "отфильтровать/поделить" и затем заниматься изменением дизайна кода?
Может, я неправильно понял. Есть функция с одним if, которая вызывается 15 раз. Предлагается этот if вынести в вызывающий код, и у нас станет 15 if вместо одного?
Ну если бы фраза применялась в этом узком контексте (стать владельцем бизнеса), то да, согласен. Но ведь очень часто её употребляют, когда речь идёт о повышении (в должности, в зарплате и т.д.), о карьерных перспективах вообще.
Эту фразу, к моему большому изумлению, приводят очень часто, хотя она совершенно дурацкая – лошадь в принципе не может стать председателем колхоза, независимо от её модели поведения.
Я согласен, что нет прямой зависимости "много и хорошо работаешь => будешь иметь карьерный рост", но изобретите какой-нибудь другой, более правдоподобный, мем, оставьте бедную лошадь в покое...
Упомянутое Вами «уметь объяснять» - вот это как раз и есть педагогический талант, далеко не каждому дано. (И при чём здесь мудак/не мудак? Вещи ортогональные.) Я за четверть века преподавания всяких насмотрелся, поверьте.
Конечно, «замотивированный» и «1-на-1» задачу упрощает, но и в такой ситуации не каждый справится.
Я сильно подозреваю, что у Вас нет высшего филологического (судя по тому, что Вы пишите комментарии на айти-ресурсе), что совсем не мешает Вам писать грамотно.
Поэтому давайте не будем передёргивать, для того, чтобы писать грамотно, совершенно не обязательно иметь высшее филологическое – достаточно иметь хотя бы каплю уважения к своим читателям.
В первом абзаце из восьми запятых присутствует только три, такой текст читать ну оооочень больно.
Ладно, я понимаю, что сам ты безграмотный бездарь и не способен писать грамотно, но сейчас вокруг стотыщмиллионов нейронок – неужели нельзя скормить свой текст какой-нибудь из них для корректировки???
Не удивлён, что у автора проблемы в профессиональной сфере 😑.
В моей Вселенной для поиска ошибок придумали отладку (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» задачу упрощает, но и в такой ситуации не каждый справится.
Понятно, что опечатка, но вот какая? "Людей собесил" или "людей бесил"? 😊
Я сильно подозреваю, что у Вас нет высшего филологического (судя по тому, что Вы пишите комментарии на айти-ресурсе), что совсем не мешает Вам писать грамотно.
Поэтому давайте не будем передёргивать, для того, чтобы писать грамотно, совершенно не обязательно иметь высшее филологическое – достаточно иметь хотя бы каплю уважения к своим читателям.
В первом абзаце из восьми запятых присутствует только три, такой текст читать ну оооочень больно.
Ладно, я понимаю, что сам ты безграмотный бездарь и не способен писать грамотно, но сейчас вокруг стотыщмиллионов нейронок – неужели нельзя скормить свой текст какой-нибудь из них для корректировки???
Не удивлён, что у автора проблемы в профессиональной сфере 😑.
Ага, нашёл, хотя и не без труда.
Но лучше бы ссылка была в тексте :)
А как можно лицезреть первую часть? В тексте ссылки не видать, в профиле единственная публикация – эта.