Почему разработчики такие медленные: распространенные проблемы и их решения

[JustDont]

Вместо этого начните с независимо тестируемого модуля состояния корзины на стороне клиента и сделайте пулл реквест для этого. Потом постройте серверный API и сделайте отдельный PR и для него. Затем напишите UI компонент который бы импортировал состояние из модуля и связывался бы с серверным API.

Мне всегда нравится, как восхитительные истории о маленьких коммитах рассказывают о максимально тривиальных ситуациях (в данном случае — о новой фиче). И никто почему-то очень не любит рассуждать о дроблении коммитов в реально сложных ситуациях (рефакторинг API и прочие изменения с огромным fanout). Почему бы это? ¯\_(ツ)_/¯

В то время как основы разработки такие как принципы абстракции, связанность и зацепление, модульность против монолитного дизайна, работа с модулями, композиция функций, композиция объектов, дизайн фреймворков и архитектура приложений упускают из виду. Из-за взрывного роста индустрии примерно половина разработчиков имеют меньше пяти лет опыта и 88% специалистов считает, что им не помешало бы обучение.

Это всё звучит очень весело, особенно на фоне постоянной публикации статей типа такой. Не понятно только, что с этим делать.

[maxzh83]

Еще интересные статьи на хабре вредят производительности разработчика. Благо, таких на хабре все меньше…

[BlackStar1991]

Есть хороший анекдот про время разработки.

Анекдот про оценку времени разработки

— Слушай, ты разработчик. Ответь, почему разработчики всегда неправильно оценивают время на создание программ?

— Представь что тебе надо разгрузить машину, сколько времени это займет?

— Пару часов

— Это камаз

— 8 часов

— Камаз, груженый песком

— 12 часов

— У тебя нет лопаты и инструментов, только твои руки

— 2 дня

— На улице -40

— 4 дня

— Камаз вообще под водой

— Так же нечестно, ты постоянно придумываешь новые условия! К чему ты мне вообще все это рассказываешь? Вы, разработчики, вечно всякую фигню рассказываете! Вместо этого могли бы просто оценить правильное время на разработку.

[Mimus_spb]

В 100% случаев, если команда разработки работает слишком медленно — это вина руководителя.

теоретик уровень 100

[JuniorIL]

Спасибо за красивые сказки. А теперь я пойду плодить 10 тасок в джире на одну задачу, чтобы руководство чувствовало "прозрачность процесса разработки" и было много красивых burn-down графиков :-*

[sumej]

Вот ещё одна сказка:
Вы тикеты для себя делаете. А не для прикрыть опу.
Я всех всегда убеждал в том, что мне не помогает это. А если это не помогало, то я создавал проект и расписывал 90 этапов с поинтами и т.д. Этого хватает на год :)

[Keyten]

Тикеты полезны чтобы не терять задачи. Такой блокнот, куда ты записываешь баг, чтобы сейчас на него не отвлекаться.
С другой стороны, задачу, которую ты делаешь вот прям щас и погружён в контекст, для тебя действительно заносить наверное смысла нет.

[Smirninini]

Проводите дизайн ревью. Совокупность проверки кода и требований позволяет отловить до 70% багов.
Проводите код ревью. Хорошо проверенный код на 90% проще поддерживать. Один час рецензирования сохранить вам 33 часа поддержки. Программисты, которые проводят код ревью на 20% более продуктивны.
Используйте TDD подход. Он сокращает количество багов на 30-40 процентов.

Откуда такие данные в % и чем они подкреплены?