Никогда не доверяйте ничему приходящему в вашу систему
Читать дальшеРубрика: Разработчикам
Стоимость ошибки и изменений…
хотелка бизнеса
1 строка
бизнес анализ этой хотелки
10 строк
ТЗ, спека
100 строк
Код реализации
1000 строк
Наконец то: Гвидо ван Россум намерен достигнуть двукратного увеличения производительности в CPython 3.11
Наработки проекта публикуются в отдельном репозитории faster-cpython. Один из участников проекта, ранее занимавшийся разработкой JIT-компилятора HotPy для CPython, опубликовал план, в соответствии с которым считает реалистичным поднять производительность в пять раз и добиться этого результата в выпуске Python 3.13.
Читать дальшена Джаве быстрее писать и саппортить, чем на системных языках
Go – для маленьких эффективных микросервисов, Java – для ООП-монстров, Rust – для лютого байтоёбства
Читать дальшеРуководство разработчиками почти не отличается от воспитателя детей
между воспитанием детей, и работой руководителем есть много общего.
Читать дальшеЧто нужно учитывать менеджеру, чтобы не переделывать проект с нуля
из-за игнорирования техдолга, рано или поздно загибается каждый третий продукт
Читать дальшеТехнический долг на проекте
Ответ кроется в самом понятии проекта. Одним из ключевых отличий проекта от других видов деятельности является уникальность конечного продукта. Там где уникальность, там и непредсказуемость, и именно она порождает изменения на проекте и вносит трудности в первоначальное проектирование системы.
Читать дальше65 вещей, которые я не знал, когда начинал программировать (а жаль)
58. Мастерство приходит с практикой
Повторение — мать учения, а один из самых надежных способов овладеть чем-то — настойчиво это практиковать.
Типизация языков программирования: разбираемся в основах
Статическая и динамическая типизация ,Сильная и слабая типизация , Явная и неявная типизация
Читать дальшекак мы решали проблему постоянных исправлений
сбор сведений и формирование требовании;
команда груммит и продумывает решение;
назначается ответственный разработчик;
разработчик описывает техническое решение;
затем это техническое решение проходит ревью у команды и остальных погруженных в предметную область;
и только после того, как согласовали решение, разработчик пишет код;
код-ревью;
тестирование.
Скрытые расходы при переходе на микросервисы
Перед стартом работы над дроблением монолита на микросервисы рекомендую пройтись по чеклисту, чтобы ничего не упустить:
Мастер-данные
Написание кода по-новому
Проектирование IT-продукта заново
Создание новой инфраструктуры
Измерение и проверка SLA
Вклад в fault tolerance на всех уровнях
Реорганизация команд
Работы по обратной совместимости
Интеграция служб поддержки
Догоняющий поток фич
Waterfall которого никогда не было
В 1970 году внесение изменений в код занимало 1 день: кодирование алгоритма, нанесение на перфокарту, проверка. А машинное время дорогое, там еще другой математик-алгоритмист хочет провериться, поэтому если ты ошибся -жди один день пока тебе дадут машинное время.
…
Таком образом весь Agile это про две цели:
– Идеальный мир для Инженера
– Сокращение затрат на поддержку ИТ-продукта.
Нет пророка в своем отечестве
… накопленный у руководителя негатив уже ничем нельзя было сдержать. Программиста хотели уволить. Собственно, это была одно из причин аудита, на который я припёрся.
Читать дальшеРазрабы работают медленно и дорого — и люди считают нас лентяями. Просто в разработке всё сложно
С программным обеспечением всегда так. На поверхности кажется, что мы делаем простые штуки. Но на самом деле — оно невероятно сложное. Проблема в том, что сложность станет видна, только когда ты погрузишься во все технические нюансы.
Читать дальшеБольше всего меня раздражает в PHP комьюнити
…это то что усредненный пхпист растет в таком порядке:
1. есть сайт, мне надо что-то добавить, изменить. Или сразу: делаю сайт!
2. лезу в код, изучаю попутно на чем он сделан (задаю вопросы уровня: а это WordPress или Laravel?)
3. изучая на чем он сделан, изучаю попутно ООП (если сайт сделан на современном фреймворке)
4. изучая ООП, изучаю попутно PHP
А надо бы – с точностью до наоборот.
Сложение двух чисел с плавающей запятой без потери точности
не надо 0,1 + 0,2 = 0,3
надо 1 + 2 = 3
Никто не умеет управлять программистами — и все придумывают костыли, вместо решений
Есть компании, где процесс разработки реально работает отлично. Я скажу вам почему — они выиграли в лотерею. У них оказалось намного больше людей, которые хотят работать — с такими, как не управляй, все будет идти хорошо. Даже манагерскую мишуру с бордами они используют для дела, а их перформанс и по джировым, и по интуитивным метрикам ясно виден. И когда их менеджеры-не-разрабы приходят мешать им, у них за спиной стоит шикарный продукт, который даёт им право посылать эти говорящие головы к черту.
…
Но такая команда — фантастическая удача. А обычно происходит вот что. На десять человек у тебя два, которые хотят работать. Один из них тимлид, а второй увольняется.
Не давать обещаний сходу
Вывод простой — никогда не давать обещаний сразу, когда их просят.
Читать дальшеГугл прислал уведомление
Пусть войдет в историю,
Для КПК на Windows Mobile
А вы хороший руководитель?
1. Донесение своих мыслей и слов спокойно.
2. Прозрачное и понятное донесение своих мыслей.
3. Умение давать людям делать свою работу.
4. Умение слушать своих людей.
5. Умение управлять не жестко, а компетентно.
7. Принятие ответственности за результат работы команды.
8. Умение принимать решения и нести за них ответственность.
9. Понимание, что его задача нужна прежде всего ему, а не его подчиненным.