Нашёл в твиттере ссылку на интересную статью Николаса Закаса 2015-го года — "The bunny theory of code".
В статье Николас рассуждает о том, как код похож на кроликов. Стоит немного подождать, и кусочек кода, который находился в одном файле, через некоторое время начинает жить уже в трёх местах. Размножение не зависит от того, хороший это код или плохой, поэтому стоит заботиться о том, какой код попадает в общий репозиторий.
Почему так происходит? Мы редко начинаем писать что-то с нуля в существующем проекте. В первую очередь мы ищем то, как данную проблему решали наши коллеги. Если решение было найдено, то с большой вероятностью оно будет скопировано в новый файл, так как закомиченный код неявно выступает неким гарантом качества. Поэтому стоит делать всё возможное, чтобы поддерживать это качество. Например, с помощью хорошего код ревью, воркшопов, обсуждения спонтанно возникших паттернов (“accidental standards") и т.п.
Читал статью с улыбкой. Николас хорошо описал, как работают разработчики с кодом. По крайней мере, лично я стараюсь не изобретать велосипед в рабочем проекте, но сначала ищу, не был ли этот велосипед изобретён другими.
#musings #programming
https://humanwhocodes.com/blog/2015/05/14/the-bunny-theory-of-code/
В статье Николас рассуждает о том, как код похож на кроликов. Стоит немного подождать, и кусочек кода, который находился в одном файле, через некоторое время начинает жить уже в трёх местах. Размножение не зависит от того, хороший это код или плохой, поэтому стоит заботиться о том, какой код попадает в общий репозиторий.
Почему так происходит? Мы редко начинаем писать что-то с нуля в существующем проекте. В первую очередь мы ищем то, как данную проблему решали наши коллеги. Если решение было найдено, то с большой вероятностью оно будет скопировано в новый файл, так как закомиченный код неявно выступает неким гарантом качества. Поэтому стоит делать всё возможное, чтобы поддерживать это качество. Например, с помощью хорошего код ревью, воркшопов, обсуждения спонтанно возникших паттернов (“accidental standards") и т.п.
Читал статью с улыбкой. Николас хорошо описал, как работают разработчики с кодом. По крайней мере, лично я стараюсь не изобретать велосипед в рабочем проекте, но сначала ищу, не был ли этот велосипед изобретён другими.
#musings #programming
https://humanwhocodes.com/blog/2015/05/14/the-bunny-theory-of-code/
Humanwhocodes
The bunny theory of code - Human Who Codes
The Official Web Site of Nicholas C. Zakas
Случайно увидел статью 2016 года Эрика Эллиота про когнитивную работу мозга программистов — "Are Programmer Brains Different?".
Проводились исследования, которые показывают, что у программистов развита память, способности, необходимые для обработки речи и анализа. Но эти способности не являются какой-то генетической предрасположенностью, они могут быть развиты практическим решением задач. В статье упоминается интересный факт. Среди программистов много музыкантов. Игра на музыкальном инструменте создаёт для мозга такую же нагрузку как и написание кода и, в целом, положительно сказывается на когнитивных способностях.
Как-то не задумывался над этим, но сходу могу вспомнить много людей, кто умеет играть на музыкальных инструментах и программирует. Более того в Яндексе и 2ГИС чуваки собираются в группы и играют музыку на вечеринках.
#programming #psychology
https://medium.com/javascript-scene/are-programmer-brains-different-2068a52648a7
Проводились исследования, которые показывают, что у программистов развита память, способности, необходимые для обработки речи и анализа. Но эти способности не являются какой-то генетической предрасположенностью, они могут быть развиты практическим решением задач. В статье упоминается интересный факт. Среди программистов много музыкантов. Игра на музыкальном инструменте создаёт для мозга такую же нагрузку как и написание кода и, в целом, положительно сказывается на когнитивных способностях.
Как-то не задумывался над этим, но сходу могу вспомнить много людей, кто умеет играть на музыкальных инструментах и программирует. Более того в Яндексе и 2ГИС чуваки собираются в группы и играют музыку на вечеринках.
#programming #psychology
https://medium.com/javascript-scene/are-programmer-brains-different-2068a52648a7
Medium
Are Programmer Brains Different?
What can neuroscience teach us about the brains of software developers? A lot.
Увидел сегодня в твиттере ссылку на статью про код ревью от разработчика из Red Hat Дэвида Лойда — "10 tips for reviewing code you don’t like".
Дэвид пишет про то, что код ревью становится очень неэффективным, когда контрибьютор и майнтейнер не могут найти общий язык. В статье он даёт рекомендации как вести себя с точки зрения мейнтейнера проекта:
1. сделайте из возражения вопрос;
2. избегайте преувеличений;
3. не насмехайтесь;
4. ведите диалог в позитивном ключе;
5. помните, что не у всех одинаковый опыт;
6. не преуменьшайте сложность того, что неочевидно;
7. проявляйте уважение;
8. управляйте ожиданиями (и своим временем);
9. говорите "пожалуйста";
10. начинайте обсуждение, если возникает недопонимание.
Статья хорошая. Очень рекомендую почитать всем, кто работает в команде или занимается поддержкой open source проекта.
#musings #codereview #programming
https://developers.redhat.com/blog/2019/07/08/10-tips-for-reviewing-code-you-dont-like/
Дэвид пишет про то, что код ревью становится очень неэффективным, когда контрибьютор и майнтейнер не могут найти общий язык. В статье он даёт рекомендации как вести себя с точки зрения мейнтейнера проекта:
1. сделайте из возражения вопрос;
2. избегайте преувеличений;
3. не насмехайтесь;
4. ведите диалог в позитивном ключе;
5. помните, что не у всех одинаковый опыт;
6. не преуменьшайте сложность того, что неочевидно;
7. проявляйте уважение;
8. управляйте ожиданиями (и своим временем);
9. говорите "пожалуйста";
10. начинайте обсуждение, если возникает недопонимание.
Статья хорошая. Очень рекомендую почитать всем, кто работает в команде или занимается поддержкой open source проекта.
#musings #codereview #programming
https://developers.redhat.com/blog/2019/07/08/10-tips-for-reviewing-code-you-dont-like/
Red Hat Developer
10 tips for reviewing code you don't like | Red Hat Developer
As a frequent contributor to open source projects (both within and beyond Red Hat), I find one of the most common time-wasters is dealing with code reviews of my submitted code that are negative or
Абстракции и программирование неотъемлемые друг от друга части. Умение добавлять хорошие абстракции и определять те абстракции, которые наносят проекту вред, многого стоит. Мерик Кристенсен написал про эту тему статью — "Art Of Abstraction".
В статье нет каких-либо практических советов, но тем не менее в ней есть тезисы, которые заставят задуматься:
— Абстракция — это инструмент коллективного мышления. Корректное применение абстракции выражается в целостном API и инструментарии, так как люди взаимодействуют с проектом, руководствуясь общим языков.
— Фундаментально, компьютерная наука — это наука абстракций, создающая правильную модель для понимания проблемы и разрабатывающая подходящие воспроизводимые техники для её решения.
В статье есть много ссылок на хорошие статьи и доклады. Я уже выбрал доклад, который буду смотреть завтра — "Hammock Driven Development" Ричарда Хикки.
#musings #programming #abstraction
https://www.merrickchristensen.com/articles/abstraction/
В статье нет каких-либо практических советов, но тем не менее в ней есть тезисы, которые заставят задуматься:
— Абстракция — это инструмент коллективного мышления. Корректное применение абстракции выражается в целостном API и инструментарии, так как люди взаимодействуют с проектом, руководствуясь общим языков.
— Фундаментально, компьютерная наука — это наука абстракций, создающая правильную модель для понимания проблемы и разрабатывающая подходящие воспроизводимые техники для её решения.
В статье есть много ссылок на хорошие статьи и доклады. Я уже выбрал доклад, который буду смотреть завтра — "Hammock Driven Development" Ричарда Хикки.
#musings #programming #abstraction
https://www.merrickchristensen.com/articles/abstraction/
Merrickchristensen
Art of Abstraction
Monorepos & packages seem to be all the rage. However, simply relocating code to a package doesn’t make it more valuable. In fact, it can make it more expensive & introduce unexpected risks! The real value comes from good abstractions.
Посмотрел доклад Ричарда Хикки — "Hammock Driven Development".
Ричард — создатель языка Clojure. При работе над языком ему надо было много думать над тем, чтобы добавляемые в язык абстракции органично взаимодействовали друг с другом. Ему надо была решать много задач. Про это он и рассказывает в своём докладе — про подходы решения разных задач, возникающих при разработке.
Способность эффективного решения задач — это не врождённое качество, а навык, который можно приобрести. Ричард порекомендовал всем почитать книгу "Как решить задачу" Д. Пойа. Книге уже больше 50 лет, но она до сих пор остаётся лучшей книгой на эту тему. В самом конце доклада он говорит про то, что не надо бояться, особенно не надо бояться оказаться неправым.
Очень крутой доклад. Рекомендую посмотреть или почитать транскрипцию.
#talk #programming #musings
https://www.youtube.com/watch?v=f84n5oFoZBc
https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/HammockDrivenDev.md
Ричард — создатель языка Clojure. При работе над языком ему надо было много думать над тем, чтобы добавляемые в язык абстракции органично взаимодействовали друг с другом. Ему надо была решать много задач. Про это он и рассказывает в своём докладе — про подходы решения разных задач, возникающих при разработке.
Способность эффективного решения задач — это не врождённое качество, а навык, который можно приобрести. Ричард порекомендовал всем почитать книгу "Как решить задачу" Д. Пойа. Книге уже больше 50 лет, но она до сих пор остаётся лучшей книгой на эту тему. В самом конце доклада он говорит про то, что не надо бояться, особенно не надо бояться оказаться неправым.
Очень крутой доклад. Рекомендую посмотреть или почитать транскрипцию.
#talk #programming #musings
https://www.youtube.com/watch?v=f84n5oFoZBc
https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/HammockDrivenDev.md
YouTube
Hammock Driven Development - Rich Hickey
Rich Hickey's second, "philosophical" talk at the first Clojure Conj, in Durham, North Carolina on October 23rd, 2010.
Many thanks to Matt Courtney, who graciously provided the equipment and expertise that made this recording possible.
Many thanks to Matt Courtney, who graciously provided the equipment and expertise that made this recording possible.
Сегодня вспомнил такое выражение: "Make It Work Make It Right Make It Fast". Насколько я помню, видел (или услышал) её в контексте разработки алгоритмов. Сегодня стало интересно, откуда она появилась.
Автор этой фразы Кент Бек; в другой формулировке она существует как часть философии Unix. Интерпретировать её можно по-разному, но в общем виде её можно понять так:
1. Сначала сделайте задачу с наименьшим количеством движущихся частей (Make It).
2. Потом следует обработать все крайние случаи и потенциальные ошибки (Make It Right).
3. И только потом можно заниматься оптимизацией (Make It Fast). Если для задач, с которыми не приходилось работать, сразу пытаться писать оптимизированный код, то такая преждевременная оптимизация усложнит систему и превратит её в то, что невозможно будет понять.
Как мне близок последний пункт. Помню, решал последнюю задачу из курса по алгоритмам от Стенфорда на Coursera (очень рекомендую пройти). Там надо было с помощью перебора решить NP-complete задачу. Использовал для решения задач C (потому что быстро, конечно). Ну и в итоге запутался в своём коде... Курс закончил, но было бы гораздо проще, если бы использовал python (javascript система проверки заданий не принимала).
#programming #musings #performance
https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast
Автор этой фразы Кент Бек; в другой формулировке она существует как часть философии Unix. Интерпретировать её можно по-разному, но в общем виде её можно понять так:
1. Сначала сделайте задачу с наименьшим количеством движущихся частей (Make It).
2. Потом следует обработать все крайние случаи и потенциальные ошибки (Make It Right).
3. И только потом можно заниматься оптимизацией (Make It Fast). Если для задач, с которыми не приходилось работать, сразу пытаться писать оптимизированный код, то такая преждевременная оптимизация усложнит систему и превратит её в то, что невозможно будет понять.
Как мне близок последний пункт. Помню, решал последнюю задачу из курса по алгоритмам от Стенфорда на Coursera (очень рекомендую пройти). Там надо было с помощью перебора решить NP-complete задачу. Использовал для решения задач C (потому что быстро, конечно). Ну и в итоге запутался в своём коде... Курс закончил, но было бы гораздо проще, если бы использовал python (javascript система проверки заданий не принимала).
#programming #musings #performance
https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast
Дэн Абрамов написал пост про проблемы фанатичного рефакторинга кода — "Goodbye, Clean Code".
Как-то у Дэна был серьёзный разговор с боссом из-за того, что он переписал чужой "грязный" код. Сейчас он размышляет над той ситуацией и пишет про то, что у добавленных абстракций должна быть хорошая цель — повторение кода, это недостаточно веская причина для его переписывания.
"Одержимость чистым кодом и удаление повторения кода — это фаза, через которую прошли многие. Когда мы не чувствуем себя уверенными в своём коде, соблазнительно соотносить чувство своего достоинства и профессиональную гордость с чем-то измеримым: набором строгих правил линтинга, схемами именования, файловой структурой, отсутствием дублирования кода."
Сейчас в твиттере и реддите немного бомбит из-за того, что Дэн призывает писать плохой код, но, имхо, статья не про это.
#musings #programming
https://overreacted.io/goodbye-clean-code/
Как-то у Дэна был серьёзный разговор с боссом из-за того, что он переписал чужой "грязный" код. Сейчас он размышляет над той ситуацией и пишет про то, что у добавленных абстракций должна быть хорошая цель — повторение кода, это недостаточно веская причина для его переписывания.
"Одержимость чистым кодом и удаление повторения кода — это фаза, через которую прошли многие. Когда мы не чувствуем себя уверенными в своём коде, соблазнительно соотносить чувство своего достоинства и профессиональную гордость с чем-то измеримым: набором строгих правил линтинга, схемами именования, файловой структурой, отсутствием дублирования кода."
Сейчас в твиттере и реддите немного бомбит из-за того, что Дэн призывает писать плохой код, но, имхо, статья не про это.
#musings #programming
https://overreacted.io/goodbye-clean-code/
overreacted.io
Goodbye, Clean Code — overreacted
Let clean code guide you. Then let it go.
Продолжаем тему преждевременных оптимизаций. Пару дней назад Никита Прокопов поделился своими мыслями по поводу известного высказывания "Premature optimization is the root of all evil".
Основная идея статьи в том, что много разработчиков воспринимают эти слова буквально, оставляя вопросы производительности на самый последний момент. Может показаться, что это контрастирует с прошлым постом в канале, но нет. В посте Андрея речь идёт про микрооптимизации, в посте Никиты — про архитектуру приложения. Если архитектура приложения с самого начала была неудачна, то скорее всего не получится без серьёзной доработки или переписывания кода ускорить готовое приложение.
Снова хочу закончить пост цитатой из статьи.
Then, if you are really serious about your final program’s performance, every decision must be made with performance in mind. [...] These sort of decisions are easy to make early on, but impossible to change later.
#programming #performance #musings
https://tonsky.me/blog/performance-first/
Основная идея статьи в том, что много разработчиков воспринимают эти слова буквально, оставляя вопросы производительности на самый последний момент. Может показаться, что это контрастирует с прошлым постом в канале, но нет. В посте Андрея речь идёт про микрооптимизации, в посте Никиты — про архитектуру приложения. Если архитектура приложения с самого начала была неудачна, то скорее всего не получится без серьёзной доработки или переписывания кода ускорить готовое приложение.
Снова хочу закончить пост цитатой из статьи.
Then, if you are really serious about your final program’s performance, every decision must be made with performance in mind. [...] These sort of decisions are easy to make early on, but impossible to change later.
#programming #performance #musings
https://tonsky.me/blog/performance-first/
tonsky.me
Performance first
“Premature optimization being the root of all evil” is the root of all evil
Добрался до статьи Андрея Ситника про допущенные ошибки в советской космической программе, и чему они могут научить — "What I learned as a developer from accidents in space".
В статье разбирается несколько реальных эпизодов. Самый интересный (и пугающий) — возвращение Андрея Волынова на Землю 18 января 1969 года. Его корабль, как все Союзы состоял из трёх отделяемых модулей. Во время приближения к Земле сервисный модуль не смог отсоединиться. Из-за этого корабль начал входить в атмосферу в неправильной позиции — корабль начал гореть. Космонавт начал описывать вслух все звуки, которые он слышал и вибрации, которые чувствовал, в надежде, что записывающая аппаратура сохранит все данные, для того чтобы избежать подобной трагедии в будущих полётах. Но всё закончилось хорошо — космонавт уцелел. Тут можно провести аналогию. Если вы вдруг столкнулись с какой-либо проблемой в сторонней библиотеке, например, сделали опечатку в конфиге и не получили предупреждение, подумайте над тем, чтобы завести issue или открыть пулл реквест — это поможет другим разработчикам при работе с библиотекой в будущем.
Статья очень интересная. Рекомендую почитать всем.
#programming #musings
https://evilmartians.com/chronicles/what-i-learned-as-a-developer-from-accidents-in-space
В статье разбирается несколько реальных эпизодов. Самый интересный (и пугающий) — возвращение Андрея Волынова на Землю 18 января 1969 года. Его корабль, как все Союзы состоял из трёх отделяемых модулей. Во время приближения к Земле сервисный модуль не смог отсоединиться. Из-за этого корабль начал входить в атмосферу в неправильной позиции — корабль начал гореть. Космонавт начал описывать вслух все звуки, которые он слышал и вибрации, которые чувствовал, в надежде, что записывающая аппаратура сохранит все данные, для того чтобы избежать подобной трагедии в будущих полётах. Но всё закончилось хорошо — космонавт уцелел. Тут можно провести аналогию. Если вы вдруг столкнулись с какой-либо проблемой в сторонней библиотеке, например, сделали опечатку в конфиге и не получили предупреждение, подумайте над тем, чтобы завести issue или открыть пулл реквест — это поможет другим разработчикам при работе с библиотекой в будущем.
Статья очень интересная. Рекомендую почитать всем.
#programming #musings
https://evilmartians.com/chronicles/what-i-learned-as-a-developer-from-accidents-in-space
evilmartians.com
What I learned as a developer from accidents in space—Martian Chronicles, Evil Martians’ team blog
How Soviet space tales help the creator of PostCSS to follow best practices in development.
Александра Сикора поделилась мыслями о проблемах статей, посвящённых разработке, — "Most tech content is bullshit".
Александра пишет про то, что в большинстве статей есть много проблем, хотя они преподносятся как истина в последней инстанции. Она призывает критически относиться к материалам, даже если они публикуются авторитетными источниками. Проще всего взять готовое решение, не задав вопрос, почему оно именно такое, какое есть, и насколько хорошо оно подходит к текущей ситуации. Но обычно у нас нет времени, чтобы разобраться в вопросе, мы не верим в собственные силы или просто ленимся. Основной посыл статьи — не потребляйте контент слепо, создавайте, задавайте вопросы, будьте любопытны.
Готов подписаться под каждым словом. Очень хорошая статья, рекомендую почитать всем без исключения.
#musings #programming
https://www.aleksandra.codes/tech-content-consumer
Александра пишет про то, что в большинстве статей есть много проблем, хотя они преподносятся как истина в последней инстанции. Она призывает критически относиться к материалам, даже если они публикуются авторитетными источниками. Проще всего взять готовое решение, не задав вопрос, почему оно именно такое, какое есть, и насколько хорошо оно подходит к текущей ситуации. Но обычно у нас нет времени, чтобы разобраться в вопросе, мы не верим в собственные силы или просто ленимся. Основной посыл статьи — не потребляйте контент слепо, создавайте, задавайте вопросы, будьте любопытны.
Готов подписаться под каждым словом. Очень хорошая статья, рекомендую почитать всем без исключения.
#musings #programming
https://www.aleksandra.codes/tech-content-consumer
www.aleksandra.codes
Most tech content is bullshit
“One of the great commandments of science is, "Mistrust arguments from authority." Too many such arguments have proved too painfully wrong. Authorities must prove their contentions like everybody else.” ~ Carl Sagan
Джек Франклин — разработчик Chrome Dev Tools — написал статью про важность простоты кода — "Keeping Code Simple".
Основная идея статьи. Число строк кода — это не очень адекватная метрика для оценки качества кода. Если одну задачу можно решить в несколько строк кода и если есть альтернативное решение в несколько раз больше, это не означает, что первый вариант лучше. Вполне возможно, что решение с меньшим числом строк будет менее читабельно и труднее в поддержке. Хороший код — это такой код, который прост в поддержке, лёгок в понимании и не требует больших сил для изменений.
Хочется добавить немного своих мыслей. Нет ничего страшного в написании хитрого кода ради фана, но если с кодом работают другие программисты, то приоритет должен быть у простоты.
#programming #musings
https://www.jackfranklin.co.uk/blog/keep-javascript-code-simple/
Основная идея статьи. Число строк кода — это не очень адекватная метрика для оценки качества кода. Если одну задачу можно решить в несколько строк кода и если есть альтернативное решение в несколько раз больше, это не означает, что первый вариант лучше. Вполне возможно, что решение с меньшим числом строк будет менее читабельно и труднее в поддержке. Хороший код — это такой код, который прост в поддержке, лёгок в понимании и не требует больших сил для изменений.
Хочется добавить немного своих мыслей. Нет ничего страшного в написании хитрого кода ради фана, но если с кодом работают другие программисты, то приоритет должен быть у простоты.
#programming #musings
https://www.jackfranklin.co.uk/blog/keep-javascript-code-simple/