Нашёл в твиттере ссылку на интересную статью Николаса Закаса 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.