Итак, книга закрыта и большая ее часть осмыслена. В большинстве случаев, мне пришлось согласиться с авторами. Не смотря на первую скептическую реакцию.
Тем не менее, осталось два аспекта, по поводу которых мне пока не удалось придти к внутренней гармонии.
1. Самокомментируемый код. Т.е. код без комментариев. Т.е. у вас могут быть комментарии для выражения ссылок на предметную облсть или ТЗ или другую документацию. Но если у вас возникло желание написать комментарий объясняющий код, то вернитесь к коду и попробуйте переписать его. А очевидные комментарии тем более не нужны.
Как сказал мой друг "а мне повезло родиться во времена, когда переменная уже могла себе позволить быть длиннее 5 символов."... А мне вот тяжело. Каким бы ни был читабельным и аккуратным код, когда я удаляю даже очевидный и, следовательно, ненужный комментарий, где-то в моей душе все равно умирает котенок. Серьезно.
Кроме того. Я не очень понимаю, как тогда обходиться с парадигмой документации к коду: той, которая автоматически генерится из соответственно оформленных комментариев. Должна ли я пожертвовать её полнотой?.. В надежде что мои имена методов интерфейса и их переменных действительно"очевидны" просты и прозрачны. Тех. писатель во мне недоумевает.
2. TDD - Test Driven Development.
Чистый код - код полностью покрытый и легко покрываемый тестами. Это абсолютно легитимно, но... с этим просто очень сложно жить.
Когда я последний раз пыталась создать тестовый проект к своему коду, я вспомнила всех чертей, каких могла. Код был слаботестируем. (Это даже с учетом, что мой диплом научил меня хотя бы поверхностно разбираться в тестировании и подходах к нему).
Между тем, авторы открыли мне весьма очевидный факт... чтобы тестирование не было такой мукой, а проект его подразумевал... что? Надо просто СНАЧАЛА подумать о том, как будут сформулированы тесты для текущей подзадачии написать их. И уже потом оформлять задачу, учитывая этот факт.
Тем не менее, данный пункт я пока не готова применить. Увы.
Я попробую, когда освоюсь с более легкой частью материала.
Из диаложиков на полях:
[17:05] К. М.: так вот, юнит-тесты иногда таки сильно упрощают жизнь
[17:06] U.: юнит тесты ВСЕГДА сильно упрощают жизнь.
[17:06] U.: кроме одного момента - момента их создания
[17:07] К. М.: они далеко не везде нужны, точнее
[17:08] U.: Когда например нет?
[17:10] К. М.: когда трата времени на формализацию и написание теста не даст кратного выигрыша по времени при дальнейшем использовании (рефакторинг, расширение функционала проекта етц); вот моё имхо
[17:11] U.: идея хорошая
[17:12] U.: ты можешь как-нибудь сформулировать критерий оценки потерь времени при дальнейшем использовании при отсутствии тестов?
[17:13] К. М.: не могу. Но вот есть мать её Управляющая Х : мониторит процесс Х, и перезагружает его, если тот отожрал слишком много памяти или пропустил контрольное время обновления логов.
[17:13] К. М.: цикл вайл(труъ), а в нём три функции проверки состояния КОДа
[17:14] К. М.: чо тут покрыть тестами? А попытки написать хоть какие-то тесты на многопоточность сожрут массу времени.
Тем не менее, осталось два аспекта, по поводу которых мне пока не удалось придти к внутренней гармонии.
1. Самокомментируемый код. Т.е. код без комментариев. Т.е. у вас могут быть комментарии для выражения ссылок на предметную облсть или ТЗ или другую документацию. Но если у вас возникло желание написать комментарий объясняющий код, то вернитесь к коду и попробуйте переписать его. А очевидные комментарии тем более не нужны.
Как сказал мой друг "а мне повезло родиться во времена, когда переменная уже могла себе позволить быть длиннее 5 символов."... А мне вот тяжело. Каким бы ни был читабельным и аккуратным код, когда я удаляю даже очевидный и, следовательно, ненужный комментарий, где-то в моей душе все равно умирает котенок. Серьезно.
Кроме того. Я не очень понимаю, как тогда обходиться с парадигмой документации к коду: той, которая автоматически генерится из соответственно оформленных комментариев. Должна ли я пожертвовать её полнотой?.. В надежде что мои имена методов интерфейса и их переменных действительно
2. TDD - Test Driven Development.
Чистый код - код полностью покрытый и легко покрываемый тестами. Это абсолютно легитимно, но... с этим просто очень сложно жить.
Когда я последний раз пыталась создать тестовый проект к своему коду, я вспомнила всех чертей, каких могла. Код был слаботестируем. (Это даже с учетом, что мой диплом научил меня хотя бы поверхностно разбираться в тестировании и подходах к нему).
Между тем, авторы открыли мне весьма очевидный факт... чтобы тестирование не было такой мукой, а проект его подразумевал... что? Надо просто СНАЧАЛА подумать о том, как будут сформулированы тесты для текущей подзадачи
Тем не менее, данный пункт я пока не готова применить. Увы.
Я попробую, когда освоюсь с более легкой частью материала.
Из диаложиков на полях:
[17:05] К. М.: так вот, юнит-тесты иногда таки сильно упрощают жизнь
[17:06] U.: юнит тесты ВСЕГДА сильно упрощают жизнь.
[17:06] U.: кроме одного момента - момента их создания
[17:07] К. М.: они далеко не везде нужны, точнее
[17:08] U.: Когда например нет?
[17:10] К. М.: когда трата времени на формализацию и написание теста не даст кратного выигрыша по времени при дальнейшем использовании (рефакторинг, расширение функционала проекта етц); вот моё имхо
[17:11] U.: идея хорошая
[17:12] U.: ты можешь как-нибудь сформулировать критерий оценки потерь времени при дальнейшем использовании при отсутствии тестов?
[17:13] К. М.: не могу. Но вот есть мать её Управляющая Х : мониторит процесс Х, и перезагружает его, если тот отожрал слишком много памяти или пропустил контрольное время обновления логов.
[17:13] К. М.: цикл вайл(труъ), а в нём три функции проверки состояния КОДа
[17:14] К. М.: чо тут покрыть тестами? А попытки написать хоть какие-то тесты на многопоточность сожрут массу времени.
Комментариев нет:
Отправить комментарий