[Перевод] 7 смертных грехов в разработке ПО

[square]

Совершенный кот

[javax]

«Код не работает. Администрация» (ц) Понедельник

[TheShock]

«Проверили, код работает. Программисты.» (ц) Среда

[javax]

Я вижу молодые не читали «Понедельник начинается в субботу.» Жаль

[grigoryvp]

Часто хочется похлопать себя по спине и поблагодарить за хорошо сделанную работу. Но откуда вы знаете, что она действительно хорошо сделана? Какие метрики вы используете?

Насколько я помню, юнит-тесированию поддатеся только код, в котором есть юниты :). Для очень многих вещей очень трудно писать тесты, потому как эти вещи завязаны на внешние библиотеки, модули и поведение операционной системы :(. ИМХО, это не всегда смертный грех. Скорее уж сказать, что крайне плохо отсутствие юнит тестов там, где это можно дешего сделать и это принесет явную пользу.

[bobermaniac]

Правильно проведенная декомпозиция системы и наворачивание фасадов на все внешние связи позволяет произвести юнит-тестирование любой системы.

[torkve]

Да ну бросьте Вы. Половину регулярок, которые используются для валидации и обработки данных (а не для примитивных задач типа поиска html-тэгов или вырезания комментариев), невозможно полностью покрыть тестами. Вернее, да, теоретически можно, регулярка — это, как ни крути, конечный автомат, только никто не напишет тестов, которые покроют всевозможные ветвления.

[TheShock]

Ну дык, я так понимаю, и не необходимо покрывать все случае. Покройте несколько ключевых успешных и несколько ключевых фейлов.

[qehgt]

>позволяет произвести юнит-тестирование любой системы
Это будет тестирование не исходной системы, а системы, из которой существенный кусок вытащили.

[Nashev]

Это будет тестирование своей части системы.

Правда, я лично в возможности полноценного тестирования даже только своей части системы — сильно сомневаюсь…

[grigoryvp]

Каждый раз нужно знать, что именно будет проверять и фиксировать юнит-тест, не надо это делать бездумно и механически. Потому что, безусловно, «всегда можно написать ещё один юнит-тест», и даже не один. Задача — выбрать наиболее полезный.

Я именно это и написал :). Юнит-тест GUI сделать, конечно, можно — но объем произведенной работы и цена поддержки при изменении этого UI будут, мягко говоря, немаленькие. Вот и спрашивается — а нужен он, такой «юнит» тест, или проще было поддерживать мануал в актуальном состоянии для тестирования силами тестировщиков? :)

[GraD_Kh]

По большей части, все проблемы проистекают из лени, как и в обычной жизни. Лень рефакторить что-то кое-как работающее, лень внимательно читать документацию, лень писать документацию и комментарии, лень обговаривать архитектуру с коллегами. Поэтому, я считаю, что это первый порок который надо в себе победить.

[Kassab]

5. Гнев (отсутствие практики комментировать код)
6. Зависть (не использование систем управления версиями)

Какое-то сомнительное соответствие между библейскими и программистскими грехами.

[TheShock]

Притянуто за уши просто)

[ijin]

8. Матерные комментарии в коде. Рано или поздно их увидит тот для кого они совсем не предназначены. Это чем-то похоже на один из законов Мерфи.

[anarleen]

Это №5, однозначно.

[agoshkinviktor]

если настроение гамно то и код в гамно, и наоборот

[GraD_Kh]

Если у программиста это так, то программист — «гамно».

[agoshkinviktor]

да, ты прав, но когда настроение хорошее — код выглядет лучше)) (отвечаю за себя)

[GraD_Kh]

Когда хорошее настроение — то вообще работается лучше и продуктивнее, это ясно. Но важно не опускаться ниже разумной планки качества да и количества тоже.

[agoshkinviktor]

я имею ввиду визуальное оформление кода) пробелы и т.д.

[GraD_Kh]

А это у нормального программиста должно выработаться как почерк. После нескольких лет просто не получается писать ненормально отформатированный код.

[agoshkinviktor]

хорошо

[Nashev]

У меня неформатированный код и читать получается с трудом %)
Первым делом форматирую, если приходится читать

[Shersh]

— Знаешь, чем отличается хороший программист от программиста-профессионала?
— Чем?
— Хороший программист пишет хороший код, когда у него хорошее настроение, а профессионал пишет хороший код всегда.

(с) не мое

[torkve]

Не, профессионал не пишет код, когда оно плохое :)
А у гуру оно должно быть хорошее всегда.

[mono2k]

профессионал — человек, делающий свою работу за деньги. К качеству сделанной работы определение «профессионал» никакого отношения не имеет.

[Shersh]

Вы это серьёзно?

«Профессионал — человек, сделавший определённое занятие своей профессией и являющийся мастером своего дела, близко по значению понятию специалист высокого класса.» (с) Вика

Человек которому платят за работу деньги — работник (сотрудник, наемник). И определение профессионал к понятию «получать деньги» никакого отношения не имеет.

[anticyclope]

Как по мне, так «фича» это «фишка». И звучит похоже, и далекие от темы люди понимают быстрее.

[edelweard]

На самом деле, самое главное — найти баланс. Золотую середину.
Собственно, как и во многих других отраслях помимо программирования.

Нет тестов — плохо. Всё в тестах, а на разработку 10 % времени — тоже плохо. Нет фич, один непрерывный рефакторинг — плохо. Нет рефакторинга, одни фичи на костылях — тоже. Ну и так далее.

[Ikutsin]

Первый пункт прямо задел за больное — но лично мне кажется, что это от недостатка предпринимательской жилки. 2,3 — болезнь компаний, где менеджмент и программисты «ходят в разные курилки». Остальные похожи больше некомпетентность и недостаточный опыт.