В разработке ПО существует одно неразрешимое противоречие - это оценка сроков.
С одной стороны, бизнесу надо знать, сколько займёт разработка фичи, причем как можно точнее. И это понятно - ведь надо как-то принимать решения, чтобы сравнить предполагаемые доходы и расходы и достать деньги в нужном количестве.
С другой стороны, разработка пороюв душе не е**т вообще не знает, сколько надо времени, особенно если
- новая функциональность нетипична
- есть зависимости на другие команды
- будет задействована новая технология
- ТЗ надо сильно уточнять
- надо разобраться в логике легаси-кода
Часто, для того, чтобы точно оценить сроки, нужно, собственно, сделать половину работы. Чем точнее надо оценить сроки, тем больше надо на это затратить времени, что приводит к суммарному увеличению time-to-market, причем все равно без гарантий.
Всё это помножается на когнитивные искажения (необъяснимый оптимизм разработчиков и заказчиков), и в результате оценка становится еще хуже.
Короче, предсказание сроков - это предсказание будущего, но при этом бизнес этого всегда требует. Время от времени появляются безумные теории типа этой, которые призваны улучшить оценку, еще, бывает, кто-то умножает на 3.14 и тд, но это всё равно что предсказывать будущее не от балды, а с картами Таро или, например, с помощью хиромантии - честно, результат будет такой же. Херня полная.
Самый рабочий подход - это делать фичи как можно меньше, чтобы "от балды" было в меньшем диапазоне, но не всегда так можно, да и гарантии всё равно нет и не будет. Поэтому есть ли смысл упарываться с оценкой? Проще оценивать в "майках": small, medium, large и помолиться Ктулху, чтобы хотя бы так сработало.
Если же разбивать супербольшую работу на части, то суммарные сроки могут варьироваться от того, насколько качественно была заложена основа. Если бизнес в начале давил (а это почти всегда так), и разрабы из-за этого срезали углы, то в конце сроки могут доходить до x10.
Даже если при оценке пытаться объяснить неразрешимость проблемы, то всегда это сводится к "Слушай, это всё понятно, но мне надо бюджет рассчитать... ну а всё-таки, сколько дней-то займёт?"
В итоге просто называешь какую-то магическую цифру и молишься Ктулху.
Вишенка на торте - это похвала или премия за то, что успел в срок. Т.е. по сути за то, что угадал, ткнув пальцем в небо. Навык предсказателя-хироманта. Ну молодец, чо 🙂
С одной стороны, бизнесу надо знать, сколько займёт разработка фичи, причем как можно точнее. И это понятно - ведь надо как-то принимать решения, чтобы сравнить предполагаемые доходы и расходы и достать деньги в нужном количестве.
С другой стороны, разработка порою
- новая функциональность нетипична
- есть зависимости на другие команды
- будет задействована новая технология
- ТЗ надо сильно уточнять
- надо разобраться в логике легаси-кода
Часто, для того, чтобы точно оценить сроки, нужно, собственно, сделать половину работы. Чем точнее надо оценить сроки, тем больше надо на это затратить времени, что приводит к суммарному увеличению time-to-market, причем все равно без гарантий.
Всё это помножается на когнитивные искажения (необъяснимый оптимизм разработчиков и заказчиков), и в результате оценка становится еще хуже.
Короче, предсказание сроков - это предсказание будущего, но при этом бизнес этого всегда требует. Время от времени появляются безумные теории типа этой, которые призваны улучшить оценку, еще, бывает, кто-то умножает на 3.14 и тд, но это всё равно что предсказывать будущее не от балды, а с картами Таро или, например, с помощью хиромантии - честно, результат будет такой же. Херня полная.
Самый рабочий подход - это делать фичи как можно меньше, чтобы "от балды" было в меньшем диапазоне, но не всегда так можно, да и гарантии всё равно нет и не будет. Поэтому есть ли смысл упарываться с оценкой? Проще оценивать в "майках": small, medium, large и помолиться Ктулху, чтобы хотя бы так сработало.
Если же разбивать супербольшую работу на части, то суммарные сроки могут варьироваться от того, насколько качественно была заложена основа. Если бизнес в начале давил (а это почти всегда так), и разрабы из-за этого срезали углы, то в конце сроки могут доходить до x10.
Даже если при оценке пытаться объяснить неразрешимость проблемы, то всегда это сводится к "Слушай, это всё понятно, но мне надо бюджет рассчитать... ну а всё-таки, сколько дней-то займёт?"
В итоге просто называешь какую-то магическую цифру и молишься Ктулху.
Вишенка на торте - это похвала или премия за то, что успел в срок. Т.е. по сути за то, что угадал, ткнув пальцем в небо. Навык предсказателя-хироманта. Ну молодец, чо 🙂
👏19👍7💯4🤮2👎1🔥1
Вместе с Женей Антоновым, небезызвестным автором канала Тимлид Очевидность, мы договорились написать пост на одну и ту же тему, а потом сравнить наши мысли.
И вот что получилось у меня:
------------------
Что если я скажу вам, что код ревью делать необязательно? Ручное тестирование замедляет процессы? Линтер не нужен? Скрам только вредит? Ваш язык не подходит для ваших задач? Покрытие тестами замерять вредно?
Наверняка вас триггернуло хотя бы одно из этих высказываний. Например: как это без код ревью, да там же говнокод польётся рекой! У всех нормальных команд оно есть!
Тогда у меня встречный вопрос: а как принималось решение о введении код ревью в процессы команды? За всех говорить не буду, но держу пари, что во многих случаях примерно так: в прошлом проекте мы так делали, а когда формировали новую команду, то тоже решили так делать.
Проблема в том, что в прошлой команде процесс принятия решения был точно такой же. И вот мы видим, что код ревью есть везде и у всех, и теперь этот подход - непреложная истина. Съехать с него почти невозможно.
Или взять хотя бы скрам - он перетекает из организации в организацию как вирус, при том, что его ценность во многих случаях сомнительна. Самое смешное, что чаще всего скрам внедряется вообще без особого обсуждения, несмотря на то, что это очень серьёзно влияет вообще на всё. Просто все так делают, и мы будем. У СЕО на прошлом проекте был скрам, теперь и у нас будет. Даже если не решает никаких проблем.
И это удивительно, ведь айтишники любят говорить (особенно в твиттере), какие они избранные интеллектуалы, но в ключевых вопросах зачастую просто следуют “за стадом”, на ходу рационализируя выбор при малейших робких сомнениях.
Лирическое отступление по поводу код ревью, потому что наверняка будут вопросы. Как и любой инструмент, код ревью может быть как на пользу, так и во вред. В проекте, где затрагивается человеческая жизнь (медицинские приборы, автопилоты автомобилей) или есть вопросы безопасности - код ревью наверно необходим. Однако в несложном продуктовом коде делать обязательный апрув, т.е. блокер, на каждой задаче - это серьёзное ухудшение пресловутого time-to-market, и возможно в команде сработавшихся профессионалов эта обязательность будет только мешать: достаточно иногда смотреть старые комиты для контроля качества кода и заранее проговаривать словами особо сложные технические решения, но не блокировать всё подряд. Другими словами, нужность код ревью зависит от проекта и задачи, но не является абсолютной истиной.
В какой момент многократно повторенная мысль становится базовой истиной, от которой потом невозможно отойти? Думаю, что всё просто. Это банальная лень, экономия энергии. Пресловутые система 1 и система 2. Подумайте, сколько всего надо, чтобы перестроиться со скрама на что-нибудь другое: все привыкли к этим пляскам, сторипоинтам, покеру и фибоначчи, знают свою роль, в jira уже всё настроено, в календаре забиты все нужные митинги. А для преобразований надо убедить каждого члена команды и руководство. Дохлый номер. То, что делают все, то истина, и так останется навсегда. Нужна по настоящему железная воля на самом верху, чтобы переубедить всех людей и поменять всю систему на какую-то другую. Потому что система сейчас устойчива (даже если не эффективна), и переход к другому устойчивому состоянию требует огромной энергии.
Кстати, командам легче перестроиться, если им дадут больше полномочий. Я вообще выступаю за по возможности полную независимость команд внутри компании, тогда им будет намного проще пересматривать и менять свои процессы, чем ворочать огромного монстра целиком.
Весто вывода: советую хотя бы иногда пересматривать вообще всё. Любые процессы и технологии, особенно те, которые раздражают, должны регулярно подвергаться сомнению.
-----------------
Вариант Жениного поста можно почитать здесь (ужасно любопытно, что там будет). В любом случае всем искренне советую подписаться на его канал Тимлид Очевидность - это много лет качественного контента на самые важные темы каждую пятницу (мне бы его дисциплину)
И вот что получилось у меня:
------------------
Что если я скажу вам, что код ревью делать необязательно? Ручное тестирование замедляет процессы? Линтер не нужен? Скрам только вредит? Ваш язык не подходит для ваших задач? Покрытие тестами замерять вредно?
Наверняка вас триггернуло хотя бы одно из этих высказываний. Например: как это без код ревью, да там же говнокод польётся рекой! У всех нормальных команд оно есть!
Тогда у меня встречный вопрос: а как принималось решение о введении код ревью в процессы команды? За всех говорить не буду, но держу пари, что во многих случаях примерно так: в прошлом проекте мы так делали, а когда формировали новую команду, то тоже решили так делать.
Проблема в том, что в прошлой команде процесс принятия решения был точно такой же. И вот мы видим, что код ревью есть везде и у всех, и теперь этот подход - непреложная истина. Съехать с него почти невозможно.
Или взять хотя бы скрам - он перетекает из организации в организацию как вирус, при том, что его ценность во многих случаях сомнительна. Самое смешное, что чаще всего скрам внедряется вообще без особого обсуждения, несмотря на то, что это очень серьёзно влияет вообще на всё. Просто все так делают, и мы будем. У СЕО на прошлом проекте был скрам, теперь и у нас будет. Даже если не решает никаких проблем.
И это удивительно, ведь айтишники любят говорить (особенно в твиттере), какие они избранные интеллектуалы, но в ключевых вопросах зачастую просто следуют “за стадом”, на ходу рационализируя выбор при малейших робких сомнениях.
Лирическое отступление по поводу код ревью, потому что наверняка будут вопросы. Как и любой инструмент, код ревью может быть как на пользу, так и во вред. В проекте, где затрагивается человеческая жизнь (медицинские приборы, автопилоты автомобилей) или есть вопросы безопасности - код ревью наверно необходим. Однако в несложном продуктовом коде делать обязательный апрув, т.е. блокер, на каждой задаче - это серьёзное ухудшение пресловутого time-to-market, и возможно в команде сработавшихся профессионалов эта обязательность будет только мешать: достаточно иногда смотреть старые комиты для контроля качества кода и заранее проговаривать словами особо сложные технические решения, но не блокировать всё подряд. Другими словами, нужность код ревью зависит от проекта и задачи, но не является абсолютной истиной.
В какой момент многократно повторенная мысль становится базовой истиной, от которой потом невозможно отойти? Думаю, что всё просто. Это банальная лень, экономия энергии. Пресловутые система 1 и система 2. Подумайте, сколько всего надо, чтобы перестроиться со скрама на что-нибудь другое: все привыкли к этим пляскам, сторипоинтам, покеру и фибоначчи, знают свою роль, в jira уже всё настроено, в календаре забиты все нужные митинги. А для преобразований надо убедить каждого члена команды и руководство. Дохлый номер. То, что делают все, то истина, и так останется навсегда. Нужна по настоящему железная воля на самом верху, чтобы переубедить всех людей и поменять всю систему на какую-то другую. Потому что система сейчас устойчива (даже если не эффективна), и переход к другому устойчивому состоянию требует огромной энергии.
Кстати, командам легче перестроиться, если им дадут больше полномочий. Я вообще выступаю за по возможности полную независимость команд внутри компании, тогда им будет намного проще пересматривать и менять свои процессы, чем ворочать огромного монстра целиком.
Весто вывода: советую хотя бы иногда пересматривать вообще всё. Любые процессы и технологии, особенно те, которые раздражают, должны регулярно подвергаться сомнению.
-----------------
Вариант Жениного поста можно почитать здесь (ужасно любопытно, что там будет). В любом случае всем искренне советую подписаться на его канал Тимлид Очевидность - это много лет качественного контента на самые важные темы каждую пятницу (мне бы его дисциплину)
👍20❤4🤮3👎2🔥2🤔1🌚1👀1
Forwarded from Пятиминутка PHP
Итак, принципы программирования по заветам Марксизма-Ленинизма от Владимира Ильича: LENIND
L - Labor Equality Principle (Принцип равенства труда): Все элементы кода должны иметь равные возможности для исполнения. Избегайте привилегирования каких-либо частей кода за счет других. Каждая функция, метод или класс должны иметь равный доступ к ресурсам и возможности для выполнения своих задач.
E - Economic Efficiency Principle (Принцип экономической эффективности): Максимизируйте использование ресурсов. Оптимизируйте ваш код для достижения максимальной производительности с минимальными затратами. Всякий излишек должен быть устранен.
N - Necessity Principle (Принцип необходимости): Каждый элемент кода должен быть необходимым и иметь цель. Избегайте бесцельного кода. Если часть кода не способствует общей цели программы, она должна быть исключена.
I - International Solidarity Principle (Принцип международной солидарности): Код должен быть написан таким образом, чтобы его можно было легко использовать, модифицировать и понимать в любой точке мира. Это включает в себя учет локализации и интернационализации, использование ясных комментариев и документации, а также придерживание стандартов кодирования.
N - No Exploitation Principle (Принцип нон-эксплуатации): Код не должен злоупотреблять своими ресурсами или зависимостями. Избегайте ситуаций, когда одна часть кода "эксплуатирует" другую, используя больше ресурсов, чем необходимо, или принуждая ее выполнять задачи за себя.
D - Dictatorship of the Proletariat Principle (Принцип диктатуры пролетариата): Код должен служить интересам большинства пользователей. Конечные пользователи - это "пролетариат" вашего кода, и его нужно разрабатывать с учетом их потребностей и интересов. Вы должны активно слушать отзывы и требования пользователей и стремиться их удовлетворить.
L - Labor Equality Principle (Принцип равенства труда): Все элементы кода должны иметь равные возможности для исполнения. Избегайте привилегирования каких-либо частей кода за счет других. Каждая функция, метод или класс должны иметь равный доступ к ресурсам и возможности для выполнения своих задач.
E - Economic Efficiency Principle (Принцип экономической эффективности): Максимизируйте использование ресурсов. Оптимизируйте ваш код для достижения максимальной производительности с минимальными затратами. Всякий излишек должен быть устранен.
N - Necessity Principle (Принцип необходимости): Каждый элемент кода должен быть необходимым и иметь цель. Избегайте бесцельного кода. Если часть кода не способствует общей цели программы, она должна быть исключена.
I - International Solidarity Principle (Принцип международной солидарности): Код должен быть написан таким образом, чтобы его можно было легко использовать, модифицировать и понимать в любой точке мира. Это включает в себя учет локализации и интернационализации, использование ясных комментариев и документации, а также придерживание стандартов кодирования.
N - No Exploitation Principle (Принцип нон-эксплуатации): Код не должен злоупотреблять своими ресурсами или зависимостями. Избегайте ситуаций, когда одна часть кода "эксплуатирует" другую, используя больше ресурсов, чем необходимо, или принуждая ее выполнять задачи за себя.
D - Dictatorship of the Proletariat Principle (Принцип диктатуры пролетариата): Код должен служить интересам большинства пользователей. Конечные пользователи - это "пролетариат" вашего кода, и его нужно разрабатывать с учетом их потребностей и интересов. Вы должны активно слушать отзывы и требования пользователей и стремиться их удовлетворить.
🤮25😁15🤡4👍3💩3🌚3🔥1😱1
Пара мыслей про поиск мёртвого кода в Go, в порядке бреда
В Go 1.20 сделали возможность сбилдить приложение с флагом cover
после чего, если запустить такое приложение, то будет собираться статистика, какие части приложения были выполнены, а какие нет, и складываться в папочку, указанную в переменной окружения.
Это, конечно, было сделано для хитрых интеграционных тестов, когда приложение запускается целиком в каких-то сценариях (а не через go test), но возможно это можно попробовать использовать и по-другому:
запустить прям на проде, подержать какое-то время и посмотреть, какие участки кода в реальности никогда не запускаются.
Это бывает нужно, когда в проекте есть старый легаси-код, и никто уже не знает, что там и зачем. Часто часть этого кода - просто старое недовыпиленное говно. И наоборот - кажется, что код уже не нужен, а он нет-нет, но иногда работает.
Правда, сбор статистики наверняка вносит некоторое торможение в код, насколько много - хз, я пока что не пробовал (У меня сейчас довольно простые микросервисы, там мало кода, и нет старого непонятного легаси). Так что это точно не всем подойдёт.
Просто как мысль на подумать
Пара деталей:
Запускать надо с переменной окружения GOCOVERDIR
После завершения приложения в этой папке появятся бинарники, которые можно сконвертировать в нормальный вид
и посмотреть, что там, стандартными средствами, например так:
Кстати, если приложение было внезапно принудительно завершено, например из-за паники, то статистика не соберется
В Go 1.20 сделали возможность сбилдить приложение с флагом cover
go build -cover
после чего, если запустить такое приложение, то будет собираться статистика, какие части приложения были выполнены, а какие нет, и складываться в папочку, указанную в переменной окружения.
Это, конечно, было сделано для хитрых интеграционных тестов, когда приложение запускается целиком в каких-то сценариях (а не через go test), но возможно это можно попробовать использовать и по-другому:
запустить прям на проде, подержать какое-то время и посмотреть, какие участки кода в реальности никогда не запускаются.
Это бывает нужно, когда в проекте есть старый легаси-код, и никто уже не знает, что там и зачем. Часто часть этого кода - просто старое недовыпиленное говно. И наоборот - кажется, что код уже не нужен, а он нет-нет, но иногда работает.
Правда, сбор статистики наверняка вносит некоторое торможение в код, насколько много - хз, я пока что не пробовал (У меня сейчас довольно простые микросервисы, там мало кода, и нет старого непонятного легаси). Так что это точно не всем подойдёт.
Просто как мысль на подумать
Пара деталей:
Запускать надо с переменной окружения GOCOVERDIR
GOCOVERDIR=somedata ./myapp
После завершения приложения в этой папке появятся бинарники, которые можно сконвертировать в нормальный вид
go tool covdata textfmt -i=somedata -o coverage.txt
и посмотреть, что там, стандартными средствами, например так:
go tool cover -html=coverage.txt
Кстати, если приложение было внезапно принудительно завершено, например из-за паники, то статистика не соберется
👍21😱2🤮2
Мало кто знает, что Кирилл Мокевнин завёл свой канал Организованное программирование. С интересом читаю и рекомендую подписаться, опыт виден в каждой строчке
Вот его мнение по поводу замены програмистов ИИ 👇
Вот его мнение по поводу замены програмистов ИИ 👇
👍3
Forwarded from Организованное программирование | Кирилл Мокевнин (Kirill Mokevnin)
Серебряной пули нет
Такую статью написал Фредерик Брукс, аж в 1986 году, где он утверждает, что, даже в отдаленном будущем, никакая технология, техника менеджмента или способ разработки не улучшат производительность, надежность и простоту разработки ПО. Подробнее об этом можно почитать на вики https://en.wikipedia.org/wiki/No_Silver_Bullet но так как этого все равно никто не сделает, я поделюсь его ключевыми мыслями, так как это очень совпадает с моими представлениями о том, как оно работает.
Если кратко, Брукс определяет два вида сложности: случайная и необходимая.
Случайная сложность, это сложность которая возникает от выбора неверных инструментов или подходов. То на что мы можем влиять и исправлять. Например мы можем выбрать более подходящий язык или фреймворк, использовать готовую библиотеку вместо написания своей и так далее. Большая часть улучшений, которыми мы занимаемся и которые делает индустрия, находятся именно в этой части, так как тут все понятно.
С необходимой сложностью все не так просто. Необходимая сложность определяется бизнес задачами. Если наша программа должна делать 30 разных штук, то мы будем должны эти 30 штук написать. И у нас не будет возможность этого избежать, так как само оно делаться не начнет. Нужно считать зарплату? Придется писать код. Нужно строить отчет? Мы будем писать код, который готовит этот отчет.
Брукс говорит о том, что мы хорошо справляемся со случайной сложностью, но даже когда мы ее уберем почти всю, у нас останется необходимая сложность, которая и является ядром нашего приложения.
Теперь немного моих мыслей по этому поводу. Любая задача, которую мы решаем внутри нашего приложения, моделируется с помощью конечного автомата. Например заказ товара в магазине это процесс в котором есть состояние набора корзины, оформления покупки, возврата и доставки. Тоже самое относится к регистрации, к публикации постов, к прохождению курсов и т.п. Так вот код который мы пишем, это переходы из одного состояние в другое. Таким образом, мы можем примерно оценить сложность нашей системы. Взять все сущности которые проходят через нее, описать автоматы и посчитать количество переходов. Это и будет та необходимая сложность, от которой избавиться нельзя.
А что насчет искуственного интелекта? Тоже самое, большинство фич, которые не являются примитивными крудами, не содержатся где-то в одном месте, как единый кусок кода. Обычно это работа с очередьми, интеграция с внешними источниками, конкретная структура базы, асинхронное выполнение, отправка писем и многое другое, что в сумме может написать только человек. Все остальное всего лишь более умный автокомплит и рефакторинг.
Такую статью написал Фредерик Брукс, аж в 1986 году, где он утверждает, что, даже в отдаленном будущем, никакая технология, техника менеджмента или способ разработки не улучшат производительность, надежность и простоту разработки ПО. Подробнее об этом можно почитать на вики https://en.wikipedia.org/wiki/No_Silver_Bullet но так как этого все равно никто не сделает, я поделюсь его ключевыми мыслями, так как это очень совпадает с моими представлениями о том, как оно работает.
Если кратко, Брукс определяет два вида сложности: случайная и необходимая.
Случайная сложность, это сложность которая возникает от выбора неверных инструментов или подходов. То на что мы можем влиять и исправлять. Например мы можем выбрать более подходящий язык или фреймворк, использовать готовую библиотеку вместо написания своей и так далее. Большая часть улучшений, которыми мы занимаемся и которые делает индустрия, находятся именно в этой части, так как тут все понятно.
С необходимой сложностью все не так просто. Необходимая сложность определяется бизнес задачами. Если наша программа должна делать 30 разных штук, то мы будем должны эти 30 штук написать. И у нас не будет возможность этого избежать, так как само оно делаться не начнет. Нужно считать зарплату? Придется писать код. Нужно строить отчет? Мы будем писать код, который готовит этот отчет.
Брукс говорит о том, что мы хорошо справляемся со случайной сложностью, но даже когда мы ее уберем почти всю, у нас останется необходимая сложность, которая и является ядром нашего приложения.
Теперь немного моих мыслей по этому поводу. Любая задача, которую мы решаем внутри нашего приложения, моделируется с помощью конечного автомата. Например заказ товара в магазине это процесс в котором есть состояние набора корзины, оформления покупки, возврата и доставки. Тоже самое относится к регистрации, к публикации постов, к прохождению курсов и т.п. Так вот код который мы пишем, это переходы из одного состояние в другое. Таким образом, мы можем примерно оценить сложность нашей системы. Взять все сущности которые проходят через нее, описать автоматы и посчитать количество переходов. Это и будет та необходимая сложность, от которой избавиться нельзя.
А что насчет искуственного интелекта? Тоже самое, большинство фич, которые не являются примитивными крудами, не содержатся где-то в одном месте, как единый кусок кода. Обычно это работа с очередьми, интеграция с внешними источниками, конкретная структура базы, асинхронное выполнение, отправка писем и многое другое, что в сумме может написать только человек. Все остальное всего лишь более умный автокомплит и рефакторинг.
👍11❤8
В очередной раз проверил, как работает усталость на способность программировать. Вчера поздно вечером, можно сказать ночью, уставший, решил порешать задачи на литкоде. Простые и средние задачи шли норм, но вот дошел до задачки hard, где надо было чуток подумать, и началось интересное.
Я сумел придумать алгоритм, и он даже сработал на некоторых тестах, но в одном тесте был какой-то затык: я пытался дебажить и так, и сяк, убил точно больше получаса на поиск проблемы, сдался и лёг спать. Интеллект 0%
Утром встал, из любопытства глянул - и СРАЗУ понял, в чем проблема. Сразу блин, за ноль минут.
Просто перепутал && и || 😂
Так тупо, капец
В общем, алгоритм от капитана:
1) устал - отдохни (кофе - не отдых, если чо)
2) отдохнул - работай
3) при необходимости повторить
Несколько лет назад с другом обсуждали такую идею, на работников навешивать какой-нибудь аппарат типа ЭЭГ, и замерять уровень усталости (хз, есть такие или нет). Возможно так будет эффективнее (и для работника, и для работодателя), чем среднее по больнице: работай 8 часов с перерывом на обед, и может быть в среднем по планете будет норм.
Я сумел придумать алгоритм, и он даже сработал на некоторых тестах, но в одном тесте был какой-то затык: я пытался дебажить и так, и сяк, убил точно больше получаса на поиск проблемы, сдался и лёг спать. Интеллект 0%
Утром встал, из любопытства глянул - и СРАЗУ понял, в чем проблема. Сразу блин, за ноль минут.
Просто перепутал && и || 😂
Так тупо, капец
В общем, алгоритм от капитана:
1) устал - отдохни (кофе - не отдых, если чо)
2) отдохнул - работай
3) при необходимости повторить
Несколько лет назад с другом обсуждали такую идею, на работников навешивать какой-нибудь аппарат типа ЭЭГ, и замерять уровень усталости (хз, есть такие или нет). Возможно так будет эффективнее (и для работника, и для работодателя), чем среднее по больнице: работай 8 часов с перерывом на обед, и может быть в среднем по планете будет норм.
👍22🔥3❤2💩1
Пятничный наброс
Есть два способа управлять разработчиками, через процессы и через использование головного мозга.
В первом случае ты выдаешь проработанную аналитиками задачу, обкладываешь сотрудников регламентами, правилами, обязательным % покрытия тестами, обеспечиваешь автоматический и ручной контроль каждой строчки, 2 апрува обязательно, навязываешь истинно правильный подход к разработке, объясняешь как именно надо работать с базой данных (с ORM там или без), апрувить новые либы могут только избранные, выкатывать на прод только Вася и только в определенное время и еще 100500 инструкций.
Плюсы: можно брать более-менее любого человека, его поставят на рельсы, проконтролируют, и поезд будет ехать в нужную сторону
Минусы: нет чувства ответственности за результат, все заняты процессами. Да и вообще, подход "один размер подходит всем" работает не очень эффективно, поэтому быстрой разработки тут не будет точно. Смелых решений никто не предложит. Ты начальник, я дурак. Инициативные люди устают биться о стену апрувов на каждый чих и выгорают. Тимлид тоже подгорает, потому что приходится принимать все решения, а не все решения принимаются правильно (так как сверху видно далеко не всё).
Во втором случае предполагается, что мы нанимаем не только навыки кодописательства, но и мозг целиком. Что программист может сам обговорить некоторые детали с заказчиком, сам понять, что важно тестировать, а что нет. Какие подходы и библиотеки использовать. Например, потому что он сам же будет это поддерживать, выкатывать на прод и разгребать потом проблемы. Формальные апрувы необязательны, разве что он сам захочет показать код товарищам для валидации идеи.
Плюсы: максимальная свобода порождает дополнительную мотивацию. С развязанными руками легче работать. Появляется ответственность за результат. Результат достигается оптимальным в данном контексте образом, а не по усредненной инструкции. Предлагаются идеи, что можно поменять, чтобы было легче работать. Тимлид на расслабоне может поехать в отпуск, да и вообще он может себе позволить быть самым тупым в команде, это нормально.
Минусы: огромные требования к найму. Если ленивый или тупой попадет в команду с максимальной свободой, то проекту пизда. Отсюда вытекает главное требование к тимлиду: быть способным быстро уволить человека, который работает плохо. И не мешать ничем людям, которые и так работают хорошо. По сути, надо изредка контролировать лишь результат: код более менее норм, пишется быстро, прод не ложится каждые 5 минут и т.д. А как именно человек этого достиг - это его дело.
Понятно, что новичков все равно придется контролировать поначалу, да и вообще, это крайние вырожденные случаи, обычно бывает смесь двух подходов. Но я всё же явно тяготею к последнему способу и стремлюсь продвинуться к нему как можно сильнее.
Есть два способа управлять разработчиками, через процессы и через использование головного мозга.
В первом случае ты выдаешь проработанную аналитиками задачу, обкладываешь сотрудников регламентами, правилами, обязательным % покрытия тестами, обеспечиваешь автоматический и ручной контроль каждой строчки, 2 апрува обязательно, навязываешь истинно правильный подход к разработке, объясняешь как именно надо работать с базой данных (с ORM там или без), апрувить новые либы могут только избранные, выкатывать на прод только Вася и только в определенное время и еще 100500 инструкций.
Плюсы: можно брать более-менее любого человека, его поставят на рельсы, проконтролируют, и поезд будет ехать в нужную сторону
Минусы: нет чувства ответственности за результат, все заняты процессами. Да и вообще, подход "один размер подходит всем" работает не очень эффективно, поэтому быстрой разработки тут не будет точно. Смелых решений никто не предложит. Ты начальник, я дурак. Инициативные люди устают биться о стену апрувов на каждый чих и выгорают. Тимлид тоже подгорает, потому что приходится принимать все решения, а не все решения принимаются правильно (так как сверху видно далеко не всё).
Во втором случае предполагается, что мы нанимаем не только навыки кодописательства, но и мозг целиком. Что программист может сам обговорить некоторые детали с заказчиком, сам понять, что важно тестировать, а что нет. Какие подходы и библиотеки использовать. Например, потому что он сам же будет это поддерживать, выкатывать на прод и разгребать потом проблемы. Формальные апрувы необязательны, разве что он сам захочет показать код товарищам для валидации идеи.
Плюсы: максимальная свобода порождает дополнительную мотивацию. С развязанными руками легче работать. Появляется ответственность за результат. Результат достигается оптимальным в данном контексте образом, а не по усредненной инструкции. Предлагаются идеи, что можно поменять, чтобы было легче работать. Тимлид на расслабоне может поехать в отпуск, да и вообще он может себе позволить быть самым тупым в команде, это нормально.
Минусы: огромные требования к найму. Если ленивый или тупой попадет в команду с максимальной свободой, то проекту пизда. Отсюда вытекает главное требование к тимлиду: быть способным быстро уволить человека, который работает плохо. И не мешать ничем людям, которые и так работают хорошо. По сути, надо изредка контролировать лишь результат: код более менее норм, пишется быстро, прод не ложится каждые 5 минут и т.д. А как именно человек этого достиг - это его дело.
Понятно, что новичков все равно придется контролировать поначалу, да и вообще, это крайние вырожденные случаи, обычно бывает смесь двух подходов. Но я всё же явно тяготею к последнему способу и стремлюсь продвинуться к нему как можно сильнее.
🔥33👍12😁2💩2
Нашел забавную вводную статью (я бы даже сказал вводную миникнигу), объясняющую происходящее с программой на низком уровне: как работает процессор, как запускается приложение, как несколько процессов работают одновременно, что такое syscall, зачем нужен libc, как идет взаимодействие с памятью и т.д.
Причем всё, можно сказать, практически на пальцах, насколько это возможно. Для тех, у кого нет общего понимания здесь - must read:
https://cpu.land/
Подпишись на канал о разработке Cross Join
Причем всё, можно сказать, практически на пальцах, насколько это возможно. Для тех, у кого нет общего понимания здесь - must read:
https://cpu.land/
Подпишись на канал о разработке Cross Join
🔥45👍9❤6💩2
Cross Join - канал о разработке pinned «Нашел забавную вводную статью (я бы даже сказал вводную миникнигу), объясняющую происходящее с программой на низком уровне: как работает процессор, как запускается приложение, как несколько процессов работают одновременно, что такое syscall, зачем нужен libc…»
В статье про комплексную эффективность разработки есть забавные цифры про концентрацию программиста:
Разработчик не робот, ему в среднем нужно 23 минуты непрерывной концентрации, прежде чем он войдёт в состояние потока, в котором достигается оптимальная продуктивность.
Инженеры в больших корпорациях по статистике имеют лишь 16.9 часов в неделю, когда они могут нормально сосредоточиться (против 22.5 в более маленьких компаниях).
Т.е. простая, но важная мысль: для эффективности команды надо не только следить, чтобы не было бессмысленных митингов, но важен и порядок их следования: экстремально важно, чтобы у разработчиков был большой кусок непрерывного времени, с учетом митингов/обедов и прочих активностей.
От этой беды, кстати, часто страдают разработчики, ставшие тимлидами: мало того, что куча митингов, но между ними мозг еще и не успевает толком перестраиваться на программирование, и толку от такого кодинга зачастую немного. Это вызывает страдания ("я весь день только болтал, а работать - не работал"). Особенно, потому что со стороны на такую ерунду, как разбивка времени по дню, вообще никто не обращает внимания.
Что можно сделать навскидку: регулярные встречи двигать в самое начало (конец) дня или вплотную к обеду; выделять в календаре блоки времени "я работаю", чтобы никто не вставил туда встречу; на скучных митингах выключать звук - это хорошее время спокойно поработать 🙂
Если серьёзно, то очень хорошо, что эту тему начали поднимать. Пройдет лет 5, и учет непрерывности времени разработки может быть будет стандартом. Хотя, хрен там, наверно 10
P.S. Когда падает прод, чайка-менеджмент из серии "ну че, скоро там почините?" тоже не добавляет концентрации
Разработчик не робот, ему в среднем нужно 23 минуты непрерывной концентрации, прежде чем он войдёт в состояние потока, в котором достигается оптимальная продуктивность.
Инженеры в больших корпорациях по статистике имеют лишь 16.9 часов в неделю, когда они могут нормально сосредоточиться (против 22.5 в более маленьких компаниях).
Т.е. простая, но важная мысль: для эффективности команды надо не только следить, чтобы не было бессмысленных митингов, но важен и порядок их следования: экстремально важно, чтобы у разработчиков был большой кусок непрерывного времени, с учетом митингов/обедов и прочих активностей.
От этой беды, кстати, часто страдают разработчики, ставшие тимлидами: мало того, что куча митингов, но между ними мозг еще и не успевает толком перестраиваться на программирование, и толку от такого кодинга зачастую немного. Это вызывает страдания ("я весь день только болтал, а работать - не работал"). Особенно, потому что со стороны на такую ерунду, как разбивка времени по дню, вообще никто не обращает внимания.
Что можно сделать навскидку: регулярные встречи двигать в самое начало (конец) дня или вплотную к обеду; выделять в календаре блоки времени "я работаю", чтобы никто не вставил туда встречу; на скучных митингах выключать звук - это хорошее время спокойно поработать 🙂
Если серьёзно, то очень хорошо, что эту тему начали поднимать. Пройдет лет 5, и учет непрерывности времени разработки может быть будет стандартом. Хотя, хрен там, наверно 10
P.S. Когда падает прод, чайка-менеджмент из серии "ну че, скоро там почините?" тоже не добавляет концентрации
👍40🤡3🤔1💩1
Петя в канале "Пятиминутка PHP" (советую подписаться!) скинул восхитительную новость. Так вот для чего были все эти вопросы на собеседованиях про сортировку :)))) 👇
Forwarded from OpenNews (HK-47)
Замена алгоритма сортировки в sysinit позволила ускорить загрузку FreeBSD
Во FreeBSD принято изменение, меняющее в коде инициализации ядра (sysinit) алгоритм сортировки массивов. Вместо ранее применявшегося алгоритма пузырьковой сортировки в sysinit задействован более эффективный алгоритм сортировки слиянием, что позволило на 2 мс сократить время загрузки ядра в виртуальных машинах Firecracker.
Во FreeBSD принято изменение, меняющее в коде инициализации ядра (sysinit) алгоритм сортировки массивов. Вместо ранее применявшегося алгоритма пузырьковой сортировки в sysinit задействован более эффективный алгоритм сортировки слиянием, что позволило на 2 мс сократить время загрузки ядра в виртуальных машинах Firecracker.
😁12👍4
Ого, в Microsoft Excel добавили поддержку Python. Для анализа данных, очистки, визуализации (matplotlib и др), machine learning и так далее. Запускаться это будет в облаке Microsoft Cloud. Достаточно лишь написать "=PY", больше ничего якобы настраивать будет не надо.
https://techcommunity.microsoft.com/t5/excel-blog/announcing-python-in-excel-combining-the-power-of-python-and-the/ba-p/3893439
https://techcommunity.microsoft.com/t5/excel-blog/announcing-python-in-excel-combining-the-power-of-python-and-the/ba-p/3893439
❤7👍4🔥4🤯2🤡1
Оказывается, в Гитлабе можно настроить MR так, чтобы сразу подсвечивалось полосками, какие строки покрыты тестами, а какие - нет. Для этого надо ваш файл покрытия сконвертировать в xml нужного формата (cobertura) и положить это в артифакт:
(подробная инструкция здесь)
Далее, после того как весь пайплайн полностью пройдет, появится подсветка, как на картинке выше.
Для языка Go покрытие конвертируется в xml с помощью утилиты gocover-cobertura, для других языков тоже есть аналоги.
Пример:
P.S. Гоша, спасибо за наводку :)
artifacts:
reports:
coverage_report:
coverage_format: cobertura
path: coverage.xml
(подробная инструкция здесь)
Далее, после того как весь пайплайн полностью пройдет, появится подсветка, как на картинке выше.
Для языка Go покрытие конвертируется в xml с помощью утилиты gocover-cobertura, для других языков тоже есть аналоги.
Пример:
go test -coverprofile cover.out ./...
go install github.com/boumenot/gocover-cobertura@latest
gocover-cobertura < cover.out > coverage.xml
P.S. Гоша, спасибо за наводку :)
👍29🔥13❤3❤🔥1👎1🤡1
git - мерзавец, мудак
github - хаб мудаков
gitlab - лаборатория мудаков
trunk - ствол
log - бревно
logger - дровосек
bash - погром
shell - оболочка
yarn - пряжа, нить
node - узел
RESTful - спокойный
docker - портовый грузчик
MySQL часто произносят как my sequel, т.е. "моё продолжение"
Oracle - предсказатель, оракул
daemon - демон
stack - стог
heap - куча
noscript - сценарий
Java, Kotlin - остров Ява, остров Котлин
Rust - ржавый
Swift - стриж, быстрый
Angular - угловой
scrum - схватка, баталия
github - хаб мудаков
gitlab - лаборатория мудаков
trunk - ствол
log - бревно
logger - дровосек
bash - погром
shell - оболочка
yarn - пряжа, нить
node - узел
RESTful - спокойный
docker - портовый грузчик
MySQL часто произносят как my sequel, т.е. "моё продолжение"
Oracle - предсказатель, оракул
daemon - демон
stack - стог
heap - куча
noscript - сценарий
Java, Kotlin - остров Ява, остров Котлин
Rust - ржавый
Swift - стриж, быстрый
Angular - угловой
scrum - схватка, баталия
🥴27😁11❤4🥱3💩2👍1
Чего только не бывает на свете.
https://smolsite.zip/ - позволяет разместить содержимое сайта прямо в урле. Т.е. можно взять папку, в которую положить index.html, картинки и т.д., зазиповать, перегнать в base64 и добавить в урл после слеша: https://smolsite.zip/[тут ваш base64]
Вот пример
В итоге, ваш сайт отобразится по этому урлу.
Непонятно только зачем, а главное - науя
https://smolsite.zip/ - позволяет разместить содержимое сайта прямо в урле. Т.е. можно взять папку, в которую положить index.html, картинки и т.д., зазиповать, перегнать в base64 и добавить в урл после слеша: https://smolsite.zip/[тут ваш base64]
Вот пример
В итоге, ваш сайт отобразится по этому урлу.
Непонятно только зачем, а главное - науя
🔥10🤯8👍4🕊2🤡1
Очень интересное приложение нашел. Общаешься голосом с роботом (на основе chatgpt) и тренируешь английский. Задания там всякие и всё такое. Для английского я его и поставил. Удобнее, чем italki и skyeng, потому что не надо назначать время, подгадывать, а просто учишь, когда хочешь, хоть 24/7. И на порядки дешевле.
Но самое интересное, что его можно использовать как тренировку собесов по-английски.
Ставишь параметры: собес на техлида, роль робота - interviewer. И он тебя гоняет по всяким вопросам типа "какие технологии знаешь", "как бы ты поступил в такой-то конфликтной ситуации" и т.д.
В конце он мне еще и рассказал, что я там сказал не так, что "to rule" - это грубо, лучше "to lead", что у меня бедноватый словарный запас там то и там то. Просто супер. Да, он иногда бывает глуховат и странноват, но и реальные преподы не лучше.
Просто 11/10
Но самое интересное, что его можно использовать как тренировку собесов по-английски.
Ставишь параметры: собес на техлида, роль робота - interviewer. И он тебя гоняет по всяким вопросам типа "какие технологии знаешь", "как бы ты поступил в такой-то конфликтной ситуации" и т.д.
В конце он мне еще и рассказал, что я там сказал не так, что "to rule" - это грубо, лучше "to lead", что у меня бедноватый словарный запас там то и там то. Просто супер. Да, он иногда бывает глуховат и странноват, но и реальные преподы не лучше.
Просто 11/10
praktika.ai
Home / Praktika
Learn a new language with AI tutors. Private tutor quality, app convenience, truly personal. Try it for free!
👍38🔥6❤2🤯2🤡1