Комментарии 19
> Автор книги пишет, что эти тесты должны быть понятными заказчику и автоматизированными.
похоже на BDD
> Инверсия приоритетов
ИМХО это проблема менеджмента, если задачу не охота делать, это обычно означает что не тому задачу дали или задача вообще никому не нужна или задача криво поставлена, а интуиция сигналит об этом.
похоже на BDD
> Инверсия приоритетов
ИМХО это проблема менеджмента, если задачу не охота делать, это обычно означает что не тому задачу дали или задача вообще никому не нужна или задача криво поставлена, а интуиция сигналит об этом.
BDD не мешает TDD же, они по моему не пересекаются особо даже.
Простите, а что делать, если задача никому не нравится? Закрывать проект? Ещё никогда не сталкивался с проектами, где сплошь и рядом интересные задачи…
Речь не про нравится/не нравится, мы же профессионалы, работаем за деньги.
Речь про то, что если не можешь заставить себя делать задачу, то скорее всего с ней что-то не то и стоит её ещё раз обсудить.
Речь про то, что если не можешь заставить себя делать задачу, то скорее всего с ней что-то не то и стоит её ещё раз обсудить.
Творчески подойти к задаче: либо разбить на более мелкие и легкие или спихнуть компьютеру (или не компьютеру). На крайняк, придумать сильную аргументацию, почему её не надо делать. Ну и последний рубеж, когда ничего не помогает — «сделаю завтра». :)
НЛО прилетело и опубликовало эту надпись здесь
Простите, а что делать, если задача никому не нравится?
Это может быть ленью или действительно чужой работой. Когда мы справляемся с ленью, мы развиваемся. Когда мы выполняем не свою работу, мы деградируем. Если мы слишком часто заняты не своей работой, нужно действительно пересматривать распределение задач. Искать младших сотрудников, которым можно спихнуть рутинную работу.
Если менеджер не понимает, кому какую задачу дать, — это повод для беспокойства. С ним нужно об этом поговорить и, если он не понимает, искать новое место работы.
А наш бывший менеджмент говорил, что на тесты времени тратить не будем.
Помню как то менеджеру скинул эту книгу, месяц за ним гнался, спрашивая прочситал ли что-нибудь :D
Кароче, нужна вторая книга «Как заставить менеджера прочитать <<Идеальный Программист>>»
Кароче, нужна вторая книга «Как заставить менеджера прочитать <<Идеальный Программист>>»
Я бы еще добавил «Не усложняют систему без необходимости»… А то посмотришь на примитивную web-отображалку БД, а там… Слой DAL (все в интерфейсах как положено конечно же, но ни намека на unit-тесты или другую реализацию интерфейсов), бизнес-логика (ничего, что она «пока» только перекидывает модели данных выше), слой UI (конечно на web api 2, ведь мы же слишком круты для простого MVC), и такая же сопля на фронт-энде (реакт, ангуляр, контроллеры, сервисы). И добавление нового поля в БД (и на UI) занимает неделю — надо его везде прописать, потом конечно исправить баги (где-то не прописали), немного порефакторить (а тут мы применим Inversion of Control — это ж круто). А менеджер бегает вокруг заказчика и объясняет, почему он должен еще немного подождать, а пока попользоваться Экселем, попутно теряя деньги :)
Да. Я совсем недавно смотрел код очень интересной системы. Там всё, прям, как вы пишете. Там, где можно было обойтись тремя слоями, разработчики использовали восемь. Там, где можно было обойтись стандартными средствами, подтянута куча доп. пакетов. Такое впечатление, что они тренировались за деньги заказчика: «А давайте используем это, это и это».
В результате плёвый проект превратился в нечто неподъёмное, разрабатывался два года и так и не был запущен: на рынке появились сильные конкуренты и проект потерял актуальность. Заказчик выкинул код и стартовал другой проект, надеясь на профессионализм новой команды.
В результате плёвый проект превратился в нечто неподъёмное, разрабатывался два года и так и не был запущен: на рынке появились сильные конкуренты и проект потерял актуальность. Заказчик выкинул код и стартовал другой проект, надеясь на профессионализм новой команды.
опечатка: смелось
Спасибо вам за статью!
Очевидно, православным программистам всё эти индуистские практики не подходят. У них другие базовые ценности. Главное, чтоб работало. А уж что там внутри… весь этот рефакторинг-шмефакторингг… и уж тем более тесты — это вопрос третьестепенный. Начальник скажет, что надо делать рефакторинг — будем делать рефакторинг. Скажет, чтобы делали тесты вначале — будем делать вначале. А если скажет, что нужно делать вообще только тесты и потом их всё время рефакторить, то будем делать тесты и рефакторить...
Блок схема процесса разработки
1. Предчувствие тупика
2. Инверсия приоритетов
3. Работа под давлением
4. Тупик
Инверсия приоритетов. Бывает такое, чаще к вечеру, развивается состояние нестояния. Что-бы не делать чтобы ничего не делать. Заставлять себя — только хуже будет. Переключаюсь на что-нибудь низко интеллектуальное — рефакторинг например.
1. Предчувствие тупика
2. Инверсия приоритетов
3. Работа под давлением
4. Тупик
Инверсия приоритетов. Бывает такое, чаще к вечеру, развивается состояние нестояния. Что-бы не делать чтобы ничего не делать. Заставлять себя — только хуже будет. Переключаюсь на что-нибудь низко интеллектуальное — рефакторинг например.
Отличная статья. Мантра для программиста =)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Идеальный программист. Часть 2