давайте переделаем ваш пост:
Действительно, не понимаю какой мне смысл вместо MP3 плеера или портативного медиа плеера покупать одно супернавороченное устройство за 300 (400-500) баксов, на котором я даже не смогу играть DivX...
готов написать такой же отзыв о любом iPod, Apple TV, OS X, Airport Extreme, Mac mini и т.д. ... но это будет глупо...
ваш пост тоже будет казаться глупым после выхода iPhone...
>поскольку даже команда из 7 человек делает в течение дня несмертельное количество коммитов.
а если команда из 50 или 100 человек?
>Поясните, пожалуйста, "history для каждого файла". Как работает SCM, я знаю, мне интересно, как люди >этим будут пользоваться.
смотреть на историю изменений и понимать, что произошло с файлом за определенный промежуток времени.
>по итогам полуторачасового совещания по внедрению управления релизами
ИМХО, за полтора часа, нельзя наладить работу SCM, в компании, в которой этого никогда не было...
>В этом же проекте меня убеждали, что пункт 5 не будет работать как раз в противоположной ситуации: >когда дизайн прекрасен.
Этот должно работать, я не спорю с этим. Но в определенных ситуациях, на начальных стадиях проекта, это может казаться не естественным...
>что некоторым просто лень писать тикеты и описывать поставленные задачи.
Это должны делать те, кто ставит задачи.
второй пункт работать не будет... если при любом изменении в коде или документации, будет приходить письмо, то в конечном итоге, все на эти письма забьют и они будут копиться в какой нибудь папочке в оутлуке... кроме того, не каждому разработчику интересно знать что происходит в других модулях, к которым он не имеет никакого отношения...
гораздо эффективнее, по крайней мере для документации, выпускать release notes, с определенным периодом, скажем каждую неделю или две, в зависимости от количества изменений...
для кода, просто, нужно вести history для каждого файла, к которой, можно обратиться в любой момент... любая SCM система это поддерживает...
пункт 4... я бы не хотел работать с компанией, у которой нет багтрекера
пункт 5 не всегда работает, особенно на ранних стадиях проекта, особенно при отсутствии хорошего дизайна.
вообще в статье, как мне показалось, автор хотел добиться определенного уровня абстракции, описывая очевидные вещи, но это не удалось, и осталась привязка к каким-то определенным "проектам", которые не применимы для всех компаний...
если бы здесь также были перечислены все достоинства iPhone, то статья была бы полноценной...
вспомните, когда выходил iPod, про него говорили похожие вещи...
Действительно, не понимаю какой мне смысл вместо MP3 плеера или портативного медиа плеера покупать одно супернавороченное устройство за 300 (400-500) баксов, на котором я даже не смогу играть DivX...
ваш пост тоже будет казаться глупым после выхода iPhone...
10.4.9
а если команда из 50 или 100 человек?
>Поясните, пожалуйста, "history для каждого файла". Как работает SCM, я знаю, мне интересно, как люди >этим будут пользоваться.
смотреть на историю изменений и понимать, что произошло с файлом за определенный промежуток времени.
>по итогам полуторачасового совещания по внедрению управления релизами
ИМХО, за полтора часа, нельзя наладить работу SCM, в компании, в которой этого никогда не было...
>В этом же проекте меня убеждали, что пункт 5 не будет работать как раз в противоположной ситуации: >когда дизайн прекрасен.
Этот должно работать, я не спорю с этим. Но в определенных ситуациях, на начальных стадиях проекта, это может казаться не естественным...
>что некоторым просто лень писать тикеты и описывать поставленные задачи.
Это должны делать те, кто ставит задачи.
гораздо эффективнее, по крайней мере для документации, выпускать release notes, с определенным периодом, скажем каждую неделю или две, в зависимости от количества изменений...
для кода, просто, нужно вести history для каждого файла, к которой, можно обратиться в любой момент... любая SCM система это поддерживает...
пункт 4... я бы не хотел работать с компанией, у которой нет багтрекера
пункт 5 не всегда работает, особенно на ранних стадиях проекта, особенно при отсутствии хорошего дизайна.
вообще в статье, как мне показалось, автор хотел добиться определенного уровня абстракции, описывая очевидные вещи, но это не удалось, и осталась привязка к каким-то определенным "проектам", которые не применимы для всех компаний...
P.S. Лучше бы он не отвечал на этот вопрос. Карма у него теперь упала...
вспомните, когда выходил iPod, про него говорили похожие вещи...