Комментарии 32
Совершенный кот
Часто хочется похлопать себя по спине и поблагодарить за хорошо сделанную работу. Но откуда вы знаете, что она действительно хорошо сделана? Какие метрики вы используете?
Насколько я помню, юнит-тесированию поддатеся только код, в котором есть юниты :). Для очень многих вещей очень трудно писать тесты, потому как эти вещи завязаны на внешние библиотеки, модули и поведение операционной системы :(. ИМХО, это не всегда смертный грех. Скорее уж сказать, что крайне плохо отсутствие юнит тестов там, где это можно дешего сделать и это принесет явную пользу.
Правильно проведенная декомпозиция системы и наворачивание фасадов на все внешние связи позволяет произвести юнит-тестирование любой системы.
Да ну бросьте Вы. Половину регулярок, которые используются для валидации и обработки данных (а не для примитивных задач типа поиска html-тэгов или вырезания комментариев), невозможно полностью покрыть тестами. Вернее, да, теоретически можно, регулярка — это, как ни крути, конечный автомат, только никто не напишет тестов, которые покроют всевозможные ветвления.
>позволяет произвести юнит-тестирование любой системы
Это будет тестирование не исходной системы, а системы, из которой существенный кусок вытащили.
Это будет тестирование не исходной системы, а системы, из которой существенный кусок вытащили.
НЛО прилетело и опубликовало эту надпись здесь
Каждый раз нужно знать, что именно будет проверять и фиксировать юнит-тест, не надо это делать бездумно и механически. Потому что, безусловно, «всегда можно написать ещё один юнит-тест», и даже не один. Задача — выбрать наиболее полезный.
Я именно это и написал :). Юнит-тест GUI сделать, конечно, можно — но объем произведенной работы и цена поддержки при изменении этого UI будут, мягко говоря, немаленькие. Вот и спрашивается — а нужен он, такой «юнит» тест, или проще было поддерживать мануал в актуальном состоянии для тестирования силами тестировщиков? :)
По большей части, все проблемы проистекают из лени, как и в обычной жизни. Лень рефакторить что-то кое-как работающее, лень внимательно читать документацию, лень писать документацию и комментарии, лень обговаривать архитектуру с коллегами. Поэтому, я считаю, что это первый порок который надо в себе победить.
5. Гнев (отсутствие практики комментировать код)
6. Зависть (не использование систем управления версиями)
Какое-то сомнительное соответствие между библейскими и программистскими грехами.
6. Зависть (не использование систем управления версиями)
Какое-то сомнительное соответствие между библейскими и программистскими грехами.
8. Матерные комментарии в коде. Рано или поздно их увидит тот для кого они совсем не предназначены. Это чем-то похоже на один из законов Мерфи.
если настроение гамно то и код в гамно, и наоборот
Если у программиста это так, то программист — «гамно».
— Знаешь, чем отличается хороший программист от программиста-профессионала?
— Чем?
— Хороший программист пишет хороший код, когда у него хорошее настроение, а профессионал пишет хороший код всегда.
(с) не мое
— Чем?
— Хороший программист пишет хороший код, когда у него хорошее настроение, а профессионал пишет хороший код всегда.
(с) не мое
Не, профессионал не пишет код, когда оно плохое :)
А у гуру оно должно быть хорошее всегда.
А у гуру оно должно быть хорошее всегда.
профессионал — человек, делающий свою работу за деньги. К качеству сделанной работы определение «профессионал» никакого отношения не имеет.
Вы это серьёзно?
«Профессионал — человек, сделавший определённое занятие своей профессией и являющийся мастером своего дела, близко по значению понятию специалист высокого класса.» (с) Вика
Человек которому платят за работу деньги — работник (сотрудник, наемник). И определение профессионал к понятию «получать деньги» никакого отношения не имеет.
«Профессионал — человек, сделавший определённое занятие своей профессией и являющийся мастером своего дела, близко по значению понятию специалист высокого класса.» (с) Вика
Человек которому платят за работу деньги — работник (сотрудник, наемник). И определение профессионал к понятию «получать деньги» никакого отношения не имеет.
Как по мне, так «фича» это «фишка». И звучит похоже, и далекие от темы люди понимают быстрее.
На самом деле, самое главное — найти баланс. Золотую середину.
Собственно, как и во многих других отраслях помимо программирования.
Нет тестов — плохо. Всё в тестах, а на разработку 10 % времени — тоже плохо. Нет фич, один непрерывный рефакторинг — плохо. Нет рефакторинга, одни фичи на костылях — тоже. Ну и так далее.
Собственно, как и во многих других отраслях помимо программирования.
Нет тестов — плохо. Всё в тестах, а на разработку 10 % времени — тоже плохо. Нет фич, один непрерывный рефакторинг — плохо. Нет рефакторинга, одни фичи на костылях — тоже. Ну и так далее.
Первый пункт прямо задел за больное — но лично мне кажется, что это от недостатка предпринимательской жилки. 2,3 — болезнь компаний, где менеджмент и программисты «ходят в разные курилки». Остальные похожи больше некомпетентность и недостаточный опыт.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
[Перевод] 7 смертных грехов в разработке ПО