Вас также хочется предостеречь. Описанное в хабратопике — не панацея. Это всего лишь срез наилучшего, что я видел за 8 лет в разработке веб-проектов и применял на практике. Импровизируйте, делайте свои уникальные солюшены для своих проектов. Если у вас есть сомнения по поводу написанного — это даже лучше!
За свою практику я манагерил 3 веб-проекта в соответствии с TDD — все провалились по одной и той же причине: на сопровождение (актуализацию) пространства тестов требовалось слишком много времени. В итоге, все 3 проекта разного размера (Java, Java, PHP), сделанные разными командами, перешли в классическую схему — частично покрытый тестами код. Веб-проекты требуют слишком частых и значительных изменений =(
И хотелось бы предостеречь от неправильных выводов — все вышесказанное относится только к веб-проектам. Я сам — экс-фанат методологии TDD. Возможно, TDD оправдан в разработке банковским систем или систем автоматического управления поездами метро. Но я лично пока не нашел TDD практического применения.
Ну вот правда, не хотелось вступать в полемику, максимум ответить на вопросы по своей точке зрения. Но тут человек старался, столько много написал про мое разоблачение… Придется тоже что-нибудь ответить.
вы пренебрегаете необходимостью тестов
Я считаю, что тесты — необходимость. Не знаю, где вы вычитали что я ими пренебрегаю. Тесты позволяют разработчику сдать проект в приемочное тестирование в нормальном состоянии. Делать же оценку качества по автотестам нельзя. Говоря о верхней планке затрат, я затрагиваю две проблемы. Первая — тесты, это тоже код, который пишут люди, а значит оттуда растут баги. Вторая — в своем стремлении создать идеальную систему разработчики настолько тверды, что готовы потратить громадное количество времени на покрытие кода тестами. Но реальная потребность покрытия тестами возникает только в важных и серьезных местах приложения. Менеджеры, которые вписывают громадные затраты на работы класса «Разработка unit-тестов», либо не умеют считать деньги, либо доверчивые идиоты, либо искусственно завышают бюджет.
кроме того, release candidate и проведение приемочного тестирования людьми на любую типографическую ошибку
Говорите какие-то глупости, о чем вообще не было написано.
для таких ошибок должен существовать механизм quick-fix
Чтобы делать quick-fix, нужно еще найти корень зла, на что уйдет больше времени, чем сделать мгновенный откат до предыдущей версии — переключить контекст веб-сервера на предыдущий релиз.
никогда нельзя выкатывать и проверять инсталляцию на машину
Гораздо круче все застопить, запустить новый процесс и посмотреть что получится — заведется или не заведется?
перед выкладкой новой версии сервис полностью останавливается
Расскажите об этом ребятам из любого высоконагруженного проекта (Яндекс, Рамблер, РБК). Подсчитывать бабло и смеятся будем все вместе.
пользовательские файлы обязаны быть частью текущей версии и частью директории проекта
Расскажите об этом ребятам из фотофайла или любого видеосервиса. Будет в два раза смешней!
Как- то так. Про остальное глупо писать — человек просто не понял сути. Либо я дал слишком мало информации о приемах.
Для внедрения/отката подойдет Apache Ant, CruiseControl не зависимо от того на чем разрабатываете. Автоматизация тестирования — любой удобный вам Unit-фреймворк, Selenium (ацкая хрень, сжирает кучу времени). Это что первое приходит в голову.
А вообще, специализированные инструменты для этих операций нужно использовать, если у вас действительно большой проект и много участников. Для простых проектов достаточно ручных операций с svn и стандартных системных утилит.
Я делюсь с хабрасообществом лучшей практикой из своего личного опыта. Для того чтобы рассказать все в деталях, придется написать книгу =) Если есть вопросы «почему» — задавайте в комментах или в хабрапочте.
Наверно, не туда: инвесторы морщатся при упоминании «социальная сеть» в презентации стартапа, силиконовая долина сокращает персонал, т. к. боится повторного краха доткомов и переводит проекты в standby-режим, sales-хаусы режут планы по продажам медийки, российские интернет-компании сокращают расходы на производство.
Экономическая ситуация не может не сказываться на нашей индустрии — инвестиционные ноги все равно растут оттуда (банки, денежные трасты, финансовые коропорации). В общем и целом, да — рынок на подъеме. Просто у интернета заторможенная реакция. Кризис в итоге оздоровит индустрию, и будет всем счастье =)
Ок, но денежная масса от продаж куда-то девается? У инвесторов, которые начали массово продавать ценные бумаги, деньги перешли в кэш, который храниться в тех же самых банках (ну не под подушку же они банкноты упаковывают)? Или все бросились скупать индийский рис?
Уж простите, но не вижу хоть чего-нибудь футбольного в проекте. На этой же платформе можно смело запускать сообщество филателистов, археологов, владельцев домашних животных и т.д. Надо всего лишь поменять логотип и пару фраз.
Клепать сообщества на одной платформе без минимального тюнинга - изначально провальный проект. Для того чтобы делать тематические сообщества тематическими, нужно понимать что нужно народу от этой тематики. Какой функционал необходим, и где-какие акценты расставить. А с этой точки зрения Dribbler интересней.
Сядьте и подумайте зачем болелам социальная сеть, чем они сейчас пользуются в интернете, какой функционал нужен и как им не дать друг друга убить. И будет вам счастье.
За свою практику я манагерил 3 веб-проекта в соответствии с TDD — все провалились по одной и той же причине: на сопровождение (актуализацию) пространства тестов требовалось слишком много времени. В итоге, все 3 проекта разного размера (Java, Java, PHP), сделанные разными командами, перешли в классическую схему — частично покрытый тестами код. Веб-проекты требуют слишком частых и значительных изменений =(
И хотелось бы предостеречь от неправильных выводов — все вышесказанное относится только к веб-проектам. Я сам — экс-фанат методологии TDD. Возможно, TDD оправдан в разработке банковским систем или систем автоматического управления поездами метро. Но я лично пока не нашел TDD практического применения.
Я считаю, что тесты — необходимость. Не знаю, где вы вычитали что я ими пренебрегаю. Тесты позволяют разработчику сдать проект в приемочное тестирование в нормальном состоянии. Делать же оценку качества по автотестам нельзя. Говоря о верхней планке затрат, я затрагиваю две проблемы. Первая — тесты, это тоже код, который пишут люди, а значит оттуда растут баги. Вторая — в своем стремлении создать идеальную систему разработчики настолько тверды, что готовы потратить громадное количество времени на покрытие кода тестами. Но реальная потребность покрытия тестами возникает только в важных и серьезных местах приложения. Менеджеры, которые вписывают громадные затраты на работы класса «Разработка unit-тестов», либо не умеют считать деньги, либо доверчивые идиоты, либо искусственно завышают бюджет.
Говорите какие-то глупости, о чем вообще не было написано.
Чтобы делать quick-fix, нужно еще найти корень зла, на что уйдет больше времени, чем сделать мгновенный откат до предыдущей версии — переключить контекст веб-сервера на предыдущий релиз.
Гораздо круче все застопить, запустить новый процесс и посмотреть что получится — заведется или не заведется?
Расскажите об этом ребятам из любого высоконагруженного проекта (Яндекс, Рамблер, РБК). Подсчитывать бабло и смеятся будем все вместе.
Расскажите об этом ребятам из фотофайла или любого видеосервиса. Будет в два раза смешней!
Как- то так. Про остальное глупо писать — человек просто не понял сути. Либо я дал слишком мало информации о приемах.
А вообще, специализированные инструменты для этих операций нужно использовать, если у вас действительно большой проект и много участников. Для простых проектов достаточно ручных операций с svn и стандартных системных утилит.
Экономическая ситуация не может не сказываться на нашей индустрии — инвестиционные ноги все равно растут оттуда (банки, денежные трасты, финансовые коропорации). В общем и целом, да — рынок на подъеме. Просто у интернета заторможенная реакция. Кризис в итоге оздоровит индустрию, и будет всем счастье =)
Клепать сообщества на одной платформе без минимального тюнинга - изначально провальный проект. Для того чтобы делать тематические сообщества тематическими, нужно понимать что нужно народу от этой тематики. Какой функционал необходим, и где-какие акценты расставить. А с этой точки зрения Dribbler интересней.
Сядьте и подумайте зачем болелам социальная сеть, чем они сейчас пользуются в интернете, какой функционал нужен и как им не дать друг друга убить. И будет вам счастье.