Forwarded from Russian Association of Software Architects (Eugene Lukianov)
💬 "Кто-то спросит: так ли уж часто читается наш код? Разве большая часть времени не уходит на его написание?
Вам когда-нибудь доводилось воспроизводить запись сеанса редактирования? В 80-х и 90-х годах существовали редакторы, записывавшие все нажатия клавиш (например, Emacs). Вы могли проработать целый час, а потом воспроизвести весь сеанс, словно ускоренное кино. Когда я это делал, результаты оказывались просто потрясающими.
Большинство операций относилось к прокрутке и переходу к другим модулям!
- Боб открывает модуль.
- Он находит функцию, которую необходимо изменить.
- Задумывается о последствиях.
- Ой, теперь он переходит в начало модуля, чтобы проверить инициализацию переменной.
- Снова возвращается вниз и начинает вводить код.
- Стирает то, что только что ввел.
- Вводит заново.
- Еще раз стирает!
- Вводит половину чего-то другого, но стирает и это!
- Прокручивает модуль к другой функции, которая вызывает изменяемую функцию, чтобы посмотреть, как она вызывается.
- Возвращается обратно и восстанавливает только что стертый код.
- Задумывается.
- Снова стирает!
- Открывает другое окно и просматривает код субкласса. Переопределяется ли в нем эта функция?
<...>
В общем, вы поняли. На самом деле соотношение времени чтения и написания кода превышает 10:1. Мы постоянно читаем свой старый код, поскольку это необходимо для написания нового кода.
Из-за столь высокого соотношения наш код должен легко читаться, даже если это затрудняет его написание. Конечно, написать код, не прочитав его, невозможно, так что упрощение чтения в действительности упрощает и написание кода. Уйти от этой логики невозможно. Невозможно написать код без предварительного чтения окружающего кода. Код, который вы собираетесь написать сегодня, будет легко или тяжело читаться в зависимости от того, насколько легко или тяжело читается окружающий код. Если вы хотите быстро справиться со своей задачей, если вы хотите, чтобы ваш код было легко писать — позаботьтесь о том, чтобы он легко читался.
You might ask: How much is code really read? Doesn't most of the effort go into writing it?
Have you ever played back an edit session? In the 80s and 90s we had editors like Emacs that kept track of every keystroke. You could work for an hour and then play back your whole edit session like a high-speed movie. When I did this, the results were fascinating.
The vast majority of the playback was scrolling and navigating to other modules!
- Bob enters the module.
- He scrolls down to the function needing change.
- He pauses, considering his options.
- Oh, he's scrolling up to the top of the module to check the initialization of a variable.
- Now he scrolls back down and begins to type.
- Ooops, he's erasing what he typed!
- He types it again.
- He erases it again!
- He types half of something else but then erases that!
- He scrolls down to another function that calls the function he's changing to see how it is called.
- He scrolls back up and types the same code he just erased.
- He pauses.
- He erases that code again!
- He pops up another window and looks at a subclass. Is that function overridden?
<...>
You get the drift. Indeed, the ratio of time spent reading vs. writing is well over 10:1. We are constantly reading old code as part of the effort to write new code.
Because this ratio is so high, we want the reading of code to be easy, even if it makes the writing harder. Of course there's no way to write code without reading it, so making it easy to read actually makes it easier to write.
There is no escape from this logic. You cannot write code if you cannot read the surrounding code. The code you are trying to write today will be hard or easy to write depending on how hard or easy the surrounding code is to read. So if you want to go fast, if you want to get done quickly, if you want your code to be easy to write, make it easy to read."
—"Clean Code: A Handbook of Agile Software Craftsmanship" by Robert C. Martin, перевод: Е.Матвеев, ООО Издательство "Питер"
#SoftwareDesign
Вам когда-нибудь доводилось воспроизводить запись сеанса редактирования? В 80-х и 90-х годах существовали редакторы, записывавшие все нажатия клавиш (например, Emacs). Вы могли проработать целый час, а потом воспроизвести весь сеанс, словно ускоренное кино. Когда я это делал, результаты оказывались просто потрясающими.
Большинство операций относилось к прокрутке и переходу к другим модулям!
- Боб открывает модуль.
- Он находит функцию, которую необходимо изменить.
- Задумывается о последствиях.
- Ой, теперь он переходит в начало модуля, чтобы проверить инициализацию переменной.
- Снова возвращается вниз и начинает вводить код.
- Стирает то, что только что ввел.
- Вводит заново.
- Еще раз стирает!
- Вводит половину чего-то другого, но стирает и это!
- Прокручивает модуль к другой функции, которая вызывает изменяемую функцию, чтобы посмотреть, как она вызывается.
- Возвращается обратно и восстанавливает только что стертый код.
- Задумывается.
- Снова стирает!
- Открывает другое окно и просматривает код субкласса. Переопределяется ли в нем эта функция?
<...>
В общем, вы поняли. На самом деле соотношение времени чтения и написания кода превышает 10:1. Мы постоянно читаем свой старый код, поскольку это необходимо для написания нового кода.
Из-за столь высокого соотношения наш код должен легко читаться, даже если это затрудняет его написание. Конечно, написать код, не прочитав его, невозможно, так что упрощение чтения в действительности упрощает и написание кода. Уйти от этой логики невозможно. Невозможно написать код без предварительного чтения окружающего кода. Код, который вы собираетесь написать сегодня, будет легко или тяжело читаться в зависимости от того, насколько легко или тяжело читается окружающий код. Если вы хотите быстро справиться со своей задачей, если вы хотите, чтобы ваш код было легко писать — позаботьтесь о том, чтобы он легко читался.
You might ask: How much is code really read? Doesn't most of the effort go into writing it?
Have you ever played back an edit session? In the 80s and 90s we had editors like Emacs that kept track of every keystroke. You could work for an hour and then play back your whole edit session like a high-speed movie. When I did this, the results were fascinating.
The vast majority of the playback was scrolling and navigating to other modules!
- Bob enters the module.
- He scrolls down to the function needing change.
- He pauses, considering his options.
- Oh, he's scrolling up to the top of the module to check the initialization of a variable.
- Now he scrolls back down and begins to type.
- Ooops, he's erasing what he typed!
- He types it again.
- He erases it again!
- He types half of something else but then erases that!
- He scrolls down to another function that calls the function he's changing to see how it is called.
- He scrolls back up and types the same code he just erased.
- He pauses.
- He erases that code again!
- He pops up another window and looks at a subclass. Is that function overridden?
<...>
You get the drift. Indeed, the ratio of time spent reading vs. writing is well over 10:1. We are constantly reading old code as part of the effort to write new code.
Because this ratio is so high, we want the reading of code to be easy, even if it makes the writing harder. Of course there's no way to write code without reading it, so making it easy to read actually makes it easier to write.
There is no escape from this logic. You cannot write code if you cannot read the surrounding code. The code you are trying to write today will be hard or easy to write depending on how hard or easy the surrounding code is to read. So if you want to go fast, if you want to get done quickly, if you want your code to be easy to write, make it easy to read."
—"Clean Code: A Handbook of Agile Software Craftsmanship" by Robert C. Martin, перевод: Е.Матвеев, ООО Издательство "Питер"
#SoftwareDesign
👍15
Дельный комментарий про интеграционные тесты и юнит тесты с конференции DevOops (ссылка с таймкодом на нужный фрагмент): https://youtu.be/0-BAmdZ9MWU?t=2225
YouTube
Интервью с Олегом Шелаевым
Ближайшая конференция: DevOops 2023, 5–6 сентября (Online), 17 октября–18 (Offline, Москва)
Билеты: https://cutt.ly/hwrLOVO0
— — Эфир из главной студии DevOops.
Участники: Андрей Когунь, Алексей Акопян, Олег Шелаев.
Билеты: https://cutt.ly/hwrLOVO0
— — Эфир из главной студии DevOops.
Участники: Андрей Когунь, Алексей Акопян, Олег Шелаев.
👍4
Совет: при модернизации legacy приложений, если ценность этой модернизации сомнительна или низка, то такое приложение лучше отдать на поддержку на аутсорс, а самим сосредоточиться на более маржинальных для бизнеса задачах. https://youtu.be/ary7OqYGpI0?t=1789
YouTube
Модернизация унаследованных приложений
Вопросы и ответы относительно модернизации унаследованных приложений. Переписывание, расширение, перехват и обработка команд и запросов, добавление одних технологий и отказ от других, изменение архитектуры и вариантов использования системы. С чего начать…
👍4👎2👏1
Мнение: Legacy приложением можно назвать такое, для которого выполняется хотя бы одно из двух условий:
1) Характеристики не достаточны с точки зрения пользователей (ёмкость, время отклика);
2) Скорость внесения изменений в систему не удовлетворяет нашим потребностям.
https://youtu.be/ary7OqYGpI0?t=2413
1) Характеристики не достаточны с точки зрения пользователей (ёмкость, время отклика);
2) Скорость внесения изменений в систему не удовлетворяет нашим потребностям.
https://youtu.be/ary7OqYGpI0?t=2413
YouTube
Модернизация унаследованных приложений
Вопросы и ответы относительно модернизации унаследованных приложений. Переписывание, расширение, перехват и обработка команд и запросов, добавление одних технологий и отказ от других, изменение архитектуры и вариантов использования системы. С чего начать…
👍5
В прошлом году я записал два выпуска подкаста про современную разработку на Битрикс.
А недавно в эту же тему подняли на YouTube канале Хекслета, смотрите свежий батл между CTO с большой экспертизой по Битрикс (Иван Поддубный) и core разработчиком Yii (Александр Макаров): http://amp.gs/jnVXm
Послушайте также выпуски Пятиминутки PHP: http://amp.gs/jnVXZ
http://amp.gs/jnVXp
А недавно в эту же тему подняли на YouTube канале Хекслета, смотрите свежий батл между CTO с большой экспертизой по Битрикс (Иван Поддубный) и core разработчиком Yii (Александр Макаров): http://amp.gs/jnVXm
Послушайте также выпуски Пятиминутки PHP: http://amp.gs/jnVXZ
http://amp.gs/jnVXp
🔥7💩4🤬1
Новый язык программирования от Google: Carbon
http://amp.gs/jn9iq
Совместим с C++, но выглядит современнее и безопасно работает с памятью.
JavaScript → TypeScript
Java → Kotlin
C++ → Carbon
http://amp.gs/jn9iq
Совместим с C++, но выглядит современнее и безопасно работает с памятью.
JavaScript → TypeScript
Java → Kotlin
C++ → Carbon
GitHub
GitHub - carbon-language/carbon-lang: Carbon Language's main repository: documents, design, implementation, and related tools.…
Carbon Language's main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README) - GitHub - carbon-language/carbon-lang: Carbon L...
🤔14👍1
У тимлидов бывает свой «пакет с пакетами» — это Excel с Excel’ями
#подслушановмаршрутке
#подслушановмаршрутке
👎9😁4👍1
Образец желтых заголовков: "Масштабирование Laravel до 30 000 запросов в минуту".
Wait... В МИНУТУ?
Обычно запросами меряются в секунду и если перевести в привычную систему измерения, выходит 500 req/sec. Мощно отмасшабировали!
https://subscribe.mateusguimaraes.com/posts/scaling-laravel-to-30-000-requests-sec-and-over-100m-jobs
Wait... В МИНУТУ?
Обычно запросами меряются в секунду и если перевести в привычную систему измерения, выходит 500 req/sec. Мощно отмасшабировали!
https://subscribe.mateusguimaraes.com/posts/scaling-laravel-to-30-000-requests-sec-and-over-100m-jobs
💩15😁7
Про маржинальность Amazon AWS в инфографике.
Кратко: выручка eCommerce бизнеса составляет 85%, однако профит от eCommerce всего 26%! AWS выходит гораздо более прибыльный бизнес!
http://amp.gs/jnDu7
Кратко: выручка eCommerce бизнеса составляет 85%, однако профит от eCommerce всего 26%! AWS выходит гораздо более прибыльный бизнес!
http://amp.gs/jnDu7
Вышла версия PhpStorm 2022.2: http://amp.gs/jnufc
Лично меня заинтересовал переход на JetBrains Runtime 17, в котором рендеринг на macOS переведён на Metal. В прошлом году я ставил бета-версии этого рантайма и тогда разницы не заметил. Пошел обновляться, всё пока!
Лично меня заинтересовал переход на JetBrains Runtime 17, в котором рендеринг на macOS переведён на Metal. В прошлом году я ставил бета-версии этого рантайма и тогда разницы не заметил. Пошел обновляться, всё пока!
JetBrains
Что нового в PhpStorm 2022.2
PhpStorm 2022.2 — большое обновление, в котором вас ждет поддержка Mockery и Rector, расширенная поддержка дженериков и перечислений, улучшения в отладчике и HTTP-клиенте и многое другое.
👏1
Вот такой интересный стартап со слоганом «Pull Request as a Service». Оплата за результат, напоминает Zerocracy (который Егор Бугаенко). Однако, как пишут в заметке - на платформе нет возможности обсуждения задачи с заказчиком и это как-то пугает!
👎1
Forwarded from Стартап дня. Александр Горный.
Оплата за коммиты
Пример идеальной организации работы - такси. Всё оплачиваемое время водителя продуктивно, потери на коммуникацию и менеджмент минимальны, Uber даже сейчас стоит 40 миллиардов долларов. Всем бы так!
Ключевой фактор успеха - точность задачи. “Из пункта А в пункт Б,” - неправильно понять такое почти невозможно, да и споры о том, выполнен ли заказ, крайне маловероятны. Американский #стартапдня GitStart предлагает перенести магию на совсем другую профессию - на программистов.
Задача ставится на уровне исходников. “Обновить SDK, но чтобы все Unit-тесты продолжали работать,” - что-то в таком духе. Ответ разработчика приходит в формате Git Pull Request - т. е. готового кода. Если заказчик принимает Request - деньги списываются, нет - нет. Никаких переговоров, обсуждений или уточнений Gitstart не предусматривает.
А поговорить? Естественно, в такую схему вписывается далеко не любая задача. Где-то проще самому сделать, чем формализовать требования, где-то для успеха нужно хорошо знать проект. Но, увы. Нельзя - значит нельзя, никаких поблажек Gitstart не дает, обычных аутсорсеров можно искать на другой площадке, специализация и дифференциация - наше всё.
Стартап пока привлек 5 миллионов долларов инвестиций, по американским меркам - почти ничего, зато успел пройти Y Combinator.
https://www.gitstart.com/
#seed #сша #uber #itдляit
Пример идеальной организации работы - такси. Всё оплачиваемое время водителя продуктивно, потери на коммуникацию и менеджмент минимальны, Uber даже сейчас стоит 40 миллиардов долларов. Всем бы так!
Ключевой фактор успеха - точность задачи. “Из пункта А в пункт Б,” - неправильно понять такое почти невозможно, да и споры о том, выполнен ли заказ, крайне маловероятны. Американский #стартапдня GitStart предлагает перенести магию на совсем другую профессию - на программистов.
Задача ставится на уровне исходников. “Обновить SDK, но чтобы все Unit-тесты продолжали работать,” - что-то в таком духе. Ответ разработчика приходит в формате Git Pull Request - т. е. готового кода. Если заказчик принимает Request - деньги списываются, нет - нет. Никаких переговоров, обсуждений или уточнений Gitstart не предусматривает.
А поговорить? Естественно, в такую схему вписывается далеко не любая задача. Где-то проще самому сделать, чем формализовать требования, где-то для успеха нужно хорошо знать проект. Но, увы. Нельзя - значит нельзя, никаких поблажек Gitstart не дает, обычных аутсорсеров можно искать на другой площадке, специализация и дифференциация - наше всё.
Стартап пока привлек 5 миллионов долларов инвестиций, по американским меркам - почти ничего, зато успел пройти Y Combinator.
https://www.gitstart.com/
#seed #сша #uber #itдляit
💩7👍2🤔2👎1
Вакансия на моём проекте:
Делаем систему управления международными грузоперевозками (документооборот/CRM/интеграции с клиентами и подрядчиками). Это внутренний продукт компании, т. е. мы напрямую общаемся с пользователями и стейкхолдерами. Также продаём своё решение партнёрам по бизнесу.
Стек:
- PHP 8.1, strict_types=1;
- MySQL 8, много запросов на чистом SQL;
- Собран самописный микро-фреймворк на PSR-7 (HTTP message interfaces), есть желание обернуть в Laravel, присматриваемся также к Yii3 как к более аккуратному фреймворку, но с последним нет экспертизы. Если ты уже пробовал Yii3 и искал работу на Yii3 для себя, пиши!
- Монолит (без микросервисов), рендеринг на бэкенде (без SPA), не highload;
- Codeception.
Задачи:
- разработка продуктовых фич связанных непосредственно с бизнесом грузоперевозок;
- работа над самим продуктом, генерация идей, повышение удовлетворённости пользователей;
- развитие архитектуры проекта, рефакторинг, покрытие тестами.
Условия:
- оформление по ТК РФ, ЗП на руки до 200 000;
- работа в офисе, в шаговой доступности от ст. м. Сокол, Москва
- пятидневная рабочая неделя с 10:00 до 19:00 (возможен гибкий график +/- 2 часа);
Если интересно или есть вопросы, с радостью отвечу: https://news.1rj.ru/str/petrmyazin
Делаем систему управления международными грузоперевозками (документооборот/CRM/интеграции с клиентами и подрядчиками). Это внутренний продукт компании, т. е. мы напрямую общаемся с пользователями и стейкхолдерами. Также продаём своё решение партнёрам по бизнесу.
Стек:
- PHP 8.1, strict_types=1;
- MySQL 8, много запросов на чистом SQL;
- Собран самописный микро-фреймворк на PSR-7 (HTTP message interfaces), есть желание обернуть в Laravel, присматриваемся также к Yii3 как к более аккуратному фреймворку, но с последним нет экспертизы. Если ты уже пробовал Yii3 и искал работу на Yii3 для себя, пиши!
- Монолит (без микросервисов), рендеринг на бэкенде (без SPA), не highload;
- Codeception.
Задачи:
- разработка продуктовых фич связанных непосредственно с бизнесом грузоперевозок;
- работа над самим продуктом, генерация идей, повышение удовлетворённости пользователей;
- развитие архитектуры проекта, рефакторинг, покрытие тестами.
Условия:
- оформление по ТК РФ, ЗП на руки до 200 000;
- работа в офисе, в шаговой доступности от ст. м. Сокол, Москва
- пятидневная рабочая неделя с 10:00 до 19:00 (возможен гибкий график +/- 2 часа);
Если интересно или есть вопросы, с радостью отвечу: https://news.1rj.ru/str/petrmyazin
🔥7👎3💩3😐2🤔1🍌1
IT батл: PHP против Python/Go/Java в 2022 году https://youtu.be/Jo04TXES64s
На мой взгляд участники дискусси не достаточно жестко аргументировали и частенько скатывались в банальное "выбор языка зависит от задачи..."
На мой взгляд участники дискусси не достаточно жестко аргументировали и частенько скатывались в банальное "выбор языка зависит от задачи..."
YouTube
«PHP мертв?» // Демо-занятие курса «Специализация PHP Developer»
В сети устоялось мнение о том, что PHP неактуален в 2022, его не стоит даже начинать использовать, и вообще - он мертв. Вот только статистика использования языков и рейтинг TIOBE почему-то противоречат этому.
Так кому же верить? Стоит взять и столкнуть мнения…
Так кому же верить? Стоит взять и столкнуть мнения…
🤔5👎2
Forwarded from Cross Join - канал о разработке (Anton Okolelov)
Минусы скрама
1) Считается, что команда "комитится", что сделает всё запланированное на спринт. Однако точно угадать сроки невозможно никогда, в жизни не видел еще точно угаданных сроков.
А перерабатывать по ночам, чтобы успеть в спринт, никто не будет, да и плохо это, ведет к выгоранию. Так в чем же тогда "комитмент"? Просто со временем развивается пофигизм. Ну продолбали и продолбали, дальше чо
2) Если пункт 1 верен, то тратить столько времени на скурпулезную оценку сроков каждой задачи (и потом скурпулезное выяснение почему продолбали) - просто бессмысленно.
3) Стремление уложиться в спринт может привести к срезанию углов и снижению качества там, где это не стоило делать.
4) Некоторые разработчики испытывают чувство вины от того, что не успели в спринт; иногда продакт смотрит на них, как на говно. И когда сроки продолбаны не из-за лени, а из-за неправильной оценки (а оценить все зависимости и случайности очень сложно), это приводит к выгоранию.
5) Если запретить вставлять новые задачи в середине спринта, то страдает гибкость бизнеса. Если разрешить - то зачем комититься на выполнение задач спринта. Есть конечно лайфхак, что при добавлении новой задачи, выкидываются другие (на столько же сторипоинтов), то тогда это ближе к канбану. Ну и всё то, на что комитились (включая цели спринта) - больше не актуально.
6) Цель спринта считается очень важной, но к сожалению в реальности зачастую спринт - это или куча задач, которые не объединить общей целью, или одна большая задача, которая принесет ценность только после нескольких спринтов, и тогда цель выглядит туповато: "Поработать над задачей X"
7) Оценка в сторипоинтах - это неведомая хрень. Которую никто не понимает нормально. Это не время, но всё же сторипоинты надо уместить во временные рамки (2 недели). Так время или нет? Лайфхак: сторипоинтами считать количество дней, округленных до фибоначи в большую сторону. Это уже лучше, но всё равно непонятно, нафига это всё.
Буду рад, если кто-то развеет мои сомнения.
1) Считается, что команда "комитится", что сделает всё запланированное на спринт. Однако точно угадать сроки невозможно никогда, в жизни не видел еще точно угаданных сроков.
А перерабатывать по ночам, чтобы успеть в спринт, никто не будет, да и плохо это, ведет к выгоранию. Так в чем же тогда "комитмент"? Просто со временем развивается пофигизм. Ну продолбали и продолбали, дальше чо
2) Если пункт 1 верен, то тратить столько времени на скурпулезную оценку сроков каждой задачи (и потом скурпулезное выяснение почему продолбали) - просто бессмысленно.
3) Стремление уложиться в спринт может привести к срезанию углов и снижению качества там, где это не стоило делать.
4) Некоторые разработчики испытывают чувство вины от того, что не успели в спринт; иногда продакт смотрит на них, как на говно. И когда сроки продолбаны не из-за лени, а из-за неправильной оценки (а оценить все зависимости и случайности очень сложно), это приводит к выгоранию.
5) Если запретить вставлять новые задачи в середине спринта, то страдает гибкость бизнеса. Если разрешить - то зачем комититься на выполнение задач спринта. Есть конечно лайфхак, что при добавлении новой задачи, выкидываются другие (на столько же сторипоинтов), то тогда это ближе к канбану. Ну и всё то, на что комитились (включая цели спринта) - больше не актуально.
6) Цель спринта считается очень важной, но к сожалению в реальности зачастую спринт - это или куча задач, которые не объединить общей целью, или одна большая задача, которая принесет ценность только после нескольких спринтов, и тогда цель выглядит туповато: "Поработать над задачей X"
7) Оценка в сторипоинтах - это неведомая хрень. Которую никто не понимает нормально. Это не время, но всё же сторипоинты надо уместить во временные рамки (2 недели). Так время или нет? Лайфхак: сторипоинтами считать количество дней, округленных до фибоначи в большую сторону. Это уже лучше, но всё равно непонятно, нафига это всё.
Буду рад, если кто-то развеет мои сомнения.
👍28💩4🔥2
Email рассылка The Road to PHP 8.2 — ежедневные заметки на почту об изменениях и улучшениях в новой версии PHP 8.2, всего должно прийти 6 писем, такой вот формат для неспешного погружения https://stitcher.io/blog/road-to-php-82?utm_source=telegram&utm_medium=social&utm_campaign=email-rassylka-the-road-to-php-8.2--ezhe&utm_content=64192518
stitcher.io
The Road to PHP 8.2 - stitcher.io
A 6 day newsletter series about PHP 8.2
🔥9