> Вы часто видели, когда на практике эффективно применяют пароное программирование?
Да, вижу каждый день.
Это реально работает, все эти плюсы срабатывают только то.
Справедливсти ради надо отметить, что парное программирование не всем нравится. Есть много людей, у которых есть психологический барьер: им не нравится, когда за ними кто-то наблюдает и постоянно что-то советует. Они хоят сидеть за своим компьютером «в одну репу». Но попрбовав ПП на практике, я убедился, что эти люди неправы. Надо этот барьер преодолеть, оно того стоит.
Да, есть такое. Но вот Intellij IDEA, например, умеет так же быстро и юнит-тесты показывать. Когда такая поддержка будет во всех IDE, то это преимущество javadoc перед юнит-тестами исчезнет. Так что это всего лишь вопрос техники.
Здрасьте!
Как раз здесь и зарыта собака! Юнит-тесты запускаются автоматически при каждой компиляции проекта, вот вам и гарантия. Забил на тесты — тесты не прошли — проект не собрался.
Одним словом, в отличие от документации, юнит-тесты валидируются. Цена за это — они не совсем на человеческом языке.
Речь идёт о юнит-тестах. Они как раз должны проверять только саму функцию без затрагивания внешних зависимостей. И это должны делать сами девелоперы.
А то, о чём вы говорите — это integration tests. Для этого действительно нужны отдельные специалисты. Но это совсем другая область.
PS. Кто сказал, что именно те программеры были опытными, а не наоборот?
Конечно, написание тестов занимает какое-то время.
Но я убеждён, что оно себя окупает с лихвой за счёт меньшего количества ошибок, понятности кода и т.д. и т.п. Я использую это на практике, так что я знаю, о чём говорю.
Есть распространённое мнение, что «нам не до тестов», но я вас уверяю, так говорят только те, кто не пробовал их на практике.
Мы говорим немножко о разных вещах. Вы говорите о документации для публично доступных библиотек — это такой отдельный продукт, который компания отдельно создаёт. В этом случае проверка корректности такой документации — отдельная статья расходов.
Я же говорю о «внутреннем» коде, к которому программеры пишут документацию просто так, просто потому что так принято или Eclipse автоматически её генерирует. А потом её никто не валидирует, и она очень быстро устаревает. Документация лжёт — этим всё сказано.
Самая прямая. Чем сложнее правила, тем сложнее их выполнять. Лучше сделать правила максимально простыми, тогда скорее люди их будут выполнять. В идеале правила должны выполняться «сами по себе», что и достигается с помощью автоматического запуска юнит-тестов при каждой компиляции проекта.
> у меня будет документация в читабельном формате, сгенерированная.
Повторюсь: нет никакой гарантии, что там написана правда, то какой толк от этой документации?
Опенсоурсные библиотеки — немного другой случай, я как бы не о нём говорил.
Пожалуй, у меня речь скорее не об API, а о «внутреннем» коде, пишушемся внутри компании, «пользователями» которого являются сами же программисты. Я так понимаю, по вашей философии, его вообще не надо документировать? Ну вот, я об этом.
1. Ничто не мешает, и тем не менее очень часто люди это не делают. Это факт. Забывают, не успевают, не знают — причин может быть масса.
2. см. 1.
3. Это стандартный javadoc. @param — параметры функции, @return — что она возвращает.
Для начала, он не мой, это всего лишь перевод статьи www.lessonsoffailure.com/developers/problem-above-average-programmers/
Лично мне она показалась очень полезной, вот и решил перевести. Чтобы и себе, и людям.
А я видел — а это значит, что бывает! :)
Да, вижу каждый день.
Это реально работает, все эти плюсы срабатывают только то.
Справедливсти ради надо отметить, что парное программирование не всем нравится. Есть много людей, у которых есть психологический барьер: им не нравится, когда за ними кто-то наблюдает и постоянно что-то советует. Они хоят сидеть за своим компьютером «в одну репу». Но попрбовав ПП на практике, я убедился, что эти люди неправы. Надо этот барьер преодолеть, оно того стоит.
Я тут впервые, обвыкаюсь.
Как раз здесь и зарыта собака! Юнит-тесты запускаются автоматически при каждой компиляции проекта, вот вам и гарантия. Забил на тесты — тесты не прошли — проект не собрался.
Одним словом, в отличие от документации, юнит-тесты валидируются. Цена за это — они не совсем на человеческом языке.
Но ответ тот же: технически ничего не мешает, но факт в том, что люди этого не делают.
А то, о чём вы говорите — это integration tests. Для этого действительно нужны отдельные специалисты. Но это совсем другая область.
PS. Кто сказал, что именно те программеры были опытными, а не наоборот?
Но я убеждён, что оно себя окупает с лихвой за счёт меньшего количества ошибок, понятности кода и т.д. и т.п. Я использую это на практике, так что я знаю, о чём говорю.
Есть распространённое мнение, что «нам не до тестов», но я вас уверяю, так говорят только те, кто не пробовал их на практике.
Я же говорю о «внутреннем» коде, к которому программеры пишут документацию просто так, просто потому что так принято или Eclipse автоматически её генерирует. А потом её никто не валидирует, и она очень быстро устаревает. Документация лжёт — этим всё сказано.
Повторюсь: нет никакой гарантии, что там написана правда, то какой толк от этой документации?
Опенсоурсные библиотеки — немного другой случай, я как бы не о нём говорил.
Возможно, javadoc легче читать, поскольку он написан на человеческом языке, но нет никакой гарантии, что там написана правда. That's the point.
2. см. 1.
3. Это стандартный javadoc. @param — параметры функции, @return — что она возвращает.