Ключ к эффективности разработки: делать то, что нужно, но лишнего не делать.
Кучу времени можно сэкономить если:
Написать тесты на функциональность, которая суперважна или в будущем будет меняться с большой вероятностью
Не писать тесты на функциональность, которая меняться никогда не будет или не особо критична при поломке
Тщательно проработать важные аспекты нового проекта, собрав нужных людей на встречу(и), написав понятно задачи
Не прорабатывать тщательно то, что допустимо придумать на ходу / не особо важно / можно спросить
Сделать и сверстать красивый удобный дизайн там, где им пользуются тысячи клиентов
Сделать на отъебись там, где раз в год один сотрудник вашей же компании нажимает пару кнопок
Написать документацию на критически важные узлы и важное взаимодействие с внешними компонентами
Не писать документацию там, где всё и так очевидно или неважно или почти умерло вообще
Выделять слои бизнес-логики в сложных программах
Не городить 10 слоёв абстракций и супергибкий код в небольшой эффективной программе, которая не будет особо меняться в будущем
Проверять на код ревью важные вещи
Не докапываться до стилистических мелочей и вкусовщины, а некоторые очевидные MR(PR) вообще не проводить через код ревью
Тщательно запланировать работы перед важным дедлайном
Не тратить (много) времени на планирование, если нет дедлайна или нет взаимодействия с другими командами
К сожалению, люди часто упарываются во что-то одно, или перфекционизм, или вселенский пофигизм. Или 100% тестирование в пет-проекте или катим работу с деньгами без тестирования прямо в прод. Это какое-то когнитивное искажение, человеку проще выбрать один шаблон, и всё делать по нему, унифицируя всё и вся, все проекты и задачи.
Я призываю всегда думать и взвешивать вероятности. Быть осознанным. Ключевой вопрос "А что будет, если не делать?". Это точно окупится.
Короче, нормально делай - нормально будет, и подписывайся на Cross Join
Кучу времени можно сэкономить если:
Написать тесты на функциональность, которая суперважна или в будущем будет меняться с большой вероятностью
Не писать тесты на функциональность, которая меняться никогда не будет или не особо критична при поломке
Тщательно проработать важные аспекты нового проекта, собрав нужных людей на встречу(и), написав понятно задачи
Не прорабатывать тщательно то, что допустимо придумать на ходу / не особо важно / можно спросить
Сделать и сверстать красивый удобный дизайн там, где им пользуются тысячи клиентов
Сделать на отъебись там, где раз в год один сотрудник вашей же компании нажимает пару кнопок
Написать документацию на критически важные узлы и важное взаимодействие с внешними компонентами
Не писать документацию там, где всё и так очевидно или неважно или почти умерло вообще
Выделять слои бизнес-логики в сложных программах
Не городить 10 слоёв абстракций и супергибкий код в небольшой эффективной программе, которая не будет особо меняться в будущем
Проверять на код ревью важные вещи
Не докапываться до стилистических мелочей и вкусовщины, а некоторые очевидные MR(PR) вообще не проводить через код ревью
Тщательно запланировать работы перед важным дедлайном
Не тратить (много) времени на планирование, если нет дедлайна или нет взаимодействия с другими командами
К сожалению, люди часто упарываются во что-то одно, или перфекционизм, или вселенский пофигизм. Или 100% тестирование в пет-проекте или катим работу с деньгами без тестирования прямо в прод. Это какое-то когнитивное искажение, человеку проще выбрать один шаблон, и всё делать по нему, унифицируя всё и вся, все проекты и задачи.
Я призываю всегда думать и взвешивать вероятности. Быть осознанным. Ключевой вопрос "А что будет, если не делать?". Это точно окупится.