Комментарии 8
Вместо этого начните с независимо тестируемого модуля состояния корзины на стороне клиента и сделайте пулл реквест для этого. Потом постройте серверный API и сделайте отдельный PR и для него. Затем напишите UI компонент который бы импортировал состояние из модуля и связывался бы с серверным API.
Мне всегда нравится, как восхитительные истории о маленьких коммитах рассказывают о максимально тривиальных ситуациях (в данном случае — о новой фиче). И никто почему-то очень не любит рассуждать о дроблении коммитов в реально сложных ситуациях (рефакторинг API и прочие изменения с огромным fanout). Почему бы это? ¯\_(ツ)_/¯
В то время как основы разработки такие как принципы абстракции, связанность и зацепление, модульность против монолитного дизайна, работа с модулями, композиция функций, композиция объектов, дизайн фреймворков и архитектура приложений упускают из виду. Из-за взрывного роста индустрии примерно половина разработчиков имеют меньше пяти лет опыта и 88% специалистов считает, что им не помешало бы обучение.
Это всё звучит очень весело, особенно на фоне постоянной публикации статей типа такой. Не понятно только, что с этим делать.
Еще интересные статьи на хабре вредят производительности разработчика. Благо, таких на хабре все меньше…
Есть хороший анекдот про время разработки.
Анекдот про оценку времени разработки
— Слушай, ты разработчик. Ответь, почему разработчики всегда неправильно оценивают время на создание программ?
— Представь что тебе надо разгрузить машину, сколько времени это займет?
— Пару часов
— Это камаз
— 8 часов
— Камаз, груженый песком
— 12 часов
— У тебя нет лопаты и инструментов, только твои руки
— 2 дня
— На улице -40
— 4 дня
— Камаз вообще под водой
— Так же нечестно, ты постоянно придумываешь новые условия! К чему ты мне вообще все это рассказываешь? Вы, разработчики, вечно всякую фигню рассказываете! Вместо этого могли бы просто оценить правильное время на разработку.
— Представь что тебе надо разгрузить машину, сколько времени это займет?
— Пару часов
— Это камаз
— 8 часов
— Камаз, груженый песком
— 12 часов
— У тебя нет лопаты и инструментов, только твои руки
— 2 дня
— На улице -40
— 4 дня
— Камаз вообще под водой
— Так же нечестно, ты постоянно придумываешь новые условия! К чему ты мне вообще все это рассказываешь? Вы, разработчики, вечно всякую фигню рассказываете! Вместо этого могли бы просто оценить правильное время на разработку.
В 100% случаев, если команда разработки работает слишком медленно — это вина руководителя.
теоретик уровень 100
Спасибо за красивые сказки. А теперь я пойду плодить 10 тасок в джире на одну задачу, чтобы руководство чувствовало "прозрачность процесса разработки" и было много красивых burn-down графиков :-*
Проводите дизайн ревью. Совокупность проверки кода и требований позволяет отловить до 70% багов.
Проводите код ревью. Хорошо проверенный код на 90% проще поддерживать. Один час рецензирования сохранить вам 33 часа поддержки. Программисты, которые проводят код ревью на 20% более продуктивны.
Используйте TDD подход. Он сокращает количество багов на 30-40 процентов.
Откуда такие данные в % и чем они подкреплены?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему разработчики такие медленные: распространенные проблемы и их решения