Size: a a a

2021 January 31

PV

Peter V in pro.js
Oleg Junior
да
И тогда ты знаешь что определения в договоре идут в начале
источник

RS

Roman Sergeevich in pro.js
В целом можно и стрелочные, просто всю логику кидать в конец.

Смотря как в целом по проекту заведено.

Конкретно этот вариант - да, хорошо описан, да, сразу видно примерную логику 👍
источник

PV

Peter V in pro.js
Ну и в целом микрофункции типо checkExact и titleContainsWords я бы не делал.
источник

OJ

Oleg Junior in pro.js
Roman Sergeevich
В целом можно и стрелочные, просто всю логику кидать в конец.

Смотря как в целом по проекту заведено.

Конкретно этот вариант - да, хорошо описан, да, сразу видно примерную логику 👍
я раньше так писал, как ты написал. но меня парило что чтобы логику увидеть, мне эти стрелочные подфункции нужно "пропустить" и внизу логику посмотреть. потом стал писать как здесь. это не на работе, а в своем пет-проекте. я хотел посоветоваться очень или не очень или нормально если я также на работе буду писать.
источник

RS

Roman Sergeevich in pro.js
Oleg Junior
я раньше так писал, как ты написал. но меня парило что чтобы логику увидеть, мне эти стрелочные подфункции нужно "пропустить" и внизу логику посмотреть. потом стал писать как здесь. это не на работе, а в своем пет-проекте. я хотел посоветоваться очень или не очень или нормально если я также на работе буду писать.
Я бы пятерку поставил
источник

OJ

Oleg Junior in pro.js
Peter V
Ну и в целом микрофункции типо checkExact и titleContainsWords я бы не делал.
я хотел как-бы выделить более абстрактную логику, чтобы то что в зеленом квадрате описывало более коротко как функция работает. а если не выделять, то получилась бы каша, которую труднее читать. но в целом да, как правило кашу по 100 - 200 строк и правда пишут, но я все же считаю что это неправильно
источник

RS

Roman Sergeevich in pro.js
Oleg Junior
я раньше так писал, как ты написал. но меня парило что чтобы логику увидеть, мне эти стрелочные подфункции нужно "пропустить" и внизу логику посмотреть. потом стал писать как здесь. это не на работе, а в своем пет-проекте. я хотел посоветоваться очень или не очень или нормально если я также на работе буду писать.
Ты же объяснил, почему так. Я согласеню. По описанию удобнее.

Я, признаться, не могу судить насколько больше времени отнимать альтернативный подход. Если ты привыкштк и юзаешь хоткис для сворачивания блоков, перехода к концу/начала скоупа
источник

PV

Peter V in pro.js
Oleg Junior
я хотел как-бы выделить более абстрактную логику, чтобы то что в зеленом квадрате описывало более коротко как функция работает. а если не выделять, то получилась бы каша, которую труднее читать. но в целом да, как правило кашу по 100 - 200 строк и правда пишут, но я все же считаю что это неправильно
Дык у тебя и функция то не очень сложная по сути ее работы. Верхнеуровневое представление о том что происходит даёт имя переменной. А так получается запутаннее
источник

OJ

Oleg Junior in pro.js
Peter V
Ну и в целом микрофункции типо checkExact и titleContainsWords я бы не делал.
вот небольшой фрагмент из видео. я руководсвовался этими соображениями что и автор в видео рассказывает. https://youtu.be/EEq1wdM2M2w?t=678
YouTube
Кирилл Мокевнин - Ментальное программирование
http://2013.happydev.ru/report/10.html

Качество кода в проекте напрямую влияет на его поддерживаемость, настроение команды и скорость ввода новых фич. Как часто вы слышали предложение или сами предлагали переписать все с нуля? Комментарии в коде “работает не трогай”, условия с магическими цифрами, функции с неговорящими названиями, в коде которых без поллитра не разобраться - все это преследует нас каждый день.

При этом существует большое количество практик, известных и не очень, которые позволяют сделать код чище, проще и понятнее без особых усилий. За последний год я был на страже качества множества проектов, создаваемых десятками разработчиков. За это время были проверены на прочность многие существующие практики и подходы, а также выработаны собственные паттерны и антипаттерны. В своем докладе я расскажу про "самодокументируемый код", принцип су-ха-ри, о контекстах, контрактах, декларативном программировании, зависимостях и многом другом.
источник

PV

Peter V in pro.js
Oleg Junior
вот небольшой фрагмент из видео. я руководсвовался этими соображениями что и автор в видео рассказывает. https://youtu.be/EEq1wdM2M2w?t=678
YouTube
Кирилл Мокевнин - Ментальное программирование
http://2013.happydev.ru/report/10.html

Качество кода в проекте напрямую влияет на его поддерживаемость, настроение команды и скорость ввода новых фич. Как часто вы слышали предложение или сами предлагали переписать все с нуля? Комментарии в коде “работает не трогай”, условия с магическими цифрами, функции с неговорящими названиями, в коде которых без поллитра не разобраться - все это преследует нас каждый день.

При этом существует большое количество практик, известных и не очень, которые позволяют сделать код чище, проще и понятнее без особых усилий. За последний год я был на страже качества множества проектов, создаваемых десятками разработчиков. За это время были проверены на прочность многие существующие практики и подходы, а также выработаны собственные паттерны и антипаттерны. В своем докладе я расскажу про "самодокументируемый код", принцип су-ха-ри, о контекстах, контрактах, декларативном программировании, зависимостях и многом другом.
Извини, не буду час смотреть. Дай таймкод где докладчик говорит про то что надо нахуярить десяток не переиспользуемых микрофункций?
источник

OJ

Oleg Junior in pro.js
Peter V
Извини, не буду час смотреть. Дай таймкод где докладчик говорит про то что надо нахуярить десяток не переиспользуемых микрофункций?
там ссылка с таймкодом где именно про такое автор рассказывает
источник

PV

Peter V in pro.js
Про длинное неочевидное условие?
источник

OJ

Oleg Junior in pro.js
вот еще более точная ссылка с таймкодом. я первый раз немного с таймкодом промахнулся. https://youtu.be/EEq1wdM2M2w?t=549
YouTube
Кирилл Мокевнин - Ментальное программирование
http://2013.happydev.ru/report/10.html

Качество кода в проекте напрямую влияет на его поддерживаемость, настроение команды и скорость ввода новых фич. Как часто вы слышали предложение или сами предлагали переписать все с нуля? Комментарии в коде “работает не трогай”, условия с магическими цифрами, функции с неговорящими названиями, в коде которых без поллитра не разобраться - все это преследует нас каждый день.

При этом существует большое количество практик, известных и не очень, которые позволяют сделать код чище, проще и понятнее без особых усилий. За последний год я был на страже качества множества проектов, создаваемых десятками разработчиков. За это время были проверены на прочность многие существующие практики и подходы, а также выработаны собственные паттерны и антипаттерны. В своем докладе я расскажу про "самодокументируемый код", принцип су-ха-ри, о контекстах, контрактах, декларативном программировании, зависимостях и многом другом.
источник

PV

Peter V in pro.js
Oleg Junior
вот еще более точная ссылка с таймкодом. я первый раз немного с таймкодом промахнулся. https://youtu.be/EEq1wdM2M2w?t=549
YouTube
Кирилл Мокевнин - Ментальное программирование
http://2013.happydev.ru/report/10.html

Качество кода в проекте напрямую влияет на его поддерживаемость, настроение команды и скорость ввода новых фич. Как часто вы слышали предложение или сами предлагали переписать все с нуля? Комментарии в коде “работает не трогай”, условия с магическими цифрами, функции с неговорящими названиями, в коде которых без поллитра не разобраться - все это преследует нас каждый день.

При этом существует большое количество практик, известных и не очень, которые позволяют сделать код чище, проще и понятнее без особых усилий. За последний год я был на страже качества множества проектов, создаваемых десятками разработчиков. За это время были проверены на прочность многие существующие практики и подходы, а также выработаны собственные паттерны и антипаттерны. В своем докладе я расскажу про "самодокументируемый код", принцип су-ха-ри, о контекстах, контрактах, декларативном программировании, зависимостях и многом другом.
Это ситуацию я бы описал как перестарался. Чувак дал очень размытый пример.
источник

OJ

Oleg Junior in pro.js
Peter V
Это ситуацию я бы описал как перестарался. Чувак дал очень размытый пример.
я нашел еще более подходящий фрагмент. там тоже немного минут 5ть он про это рассказывает. https://youtu.be/vkUTX1hruF8?t=945
источник

PV

Peter V in pro.js
Oleg Junior
я нашел еще более подходящий фрагмент. там тоже немного минут 5ть он про это рассказывает. https://youtu.be/vkUTX1hruF8?t=945
Бро, он рассказывает не про то, что надо нахуярить десяток микрофункций на двадцати строчную функцю
источник

OJ

Oleg Junior in pro.js
Peter V
Бро, он рассказывает не про то, что надо нахуярить десяток микрофункций на двадцати строчную функцю
ну да не про это. но логика я думаю понятна.
источник

PV

Peter V in pro.js
Oleg Junior
ну да не про это. но логика я думаю понятна.
ну ты именно этим и аргументировал, мол посмотрел чувака, а он говорит, чтобы сделать ваш код хорошим нахуярьте десяток функций. а чувак говорил собственно о том что надо делать код простым и логичным, и я с ним абсолютно согласен
источник

OJ

Oleg Junior in pro.js
Peter V
ну ты именно этим и аргументировал, мол посмотрел чувака, а он говорит, чтобы сделать ваш код хорошим нахуярьте десяток функций. а чувак говорил собственно о том что надо делать код простым и логичным, и я с ним абсолютно согласен
просто тот пример это из кода, который я давно писал. я тогда еще баланса не чувствовал между "нахуярить" и писать императивную кашу.
источник

ИУ

Иван Усенков... in pro.js
Peter V
ну ты именно этим и аргументировал, мол посмотрел чувака, а он говорит, чтобы сделать ваш код хорошим нахуярьте десяток функций. а чувак говорил собственно о том что надо делать код простым и логичным, и я с ним абсолютно согласен
Ну вообще, 1 функция должна делать 1 действие. Поэтому микрофункции позволяют читать код лучше чем одна большая функция. И ты её легко можешь отдебажить по входящим и исходящим данным вместо того чем смотреть где поменянные переменные ещё используются дальше.
источник