Комментарии 26
Обожаю читать статьи, где сформирован разнообразный скелет из разных фактов. Теперь есть что пояньдить подробнее.
Признаюсь честно, что на хабре уже видел картинку точно такую же как из раздела «Декомпозиция спецификации»
Хорошая статья. Как бы и эту мысль проиллюстрировать?
Критика
Обычно риск ходит в паре с «изменением требований». Если наступил первый, то второй наступает почти автоматически.
Читаю подобные статьи часто, все нравится, пытаюсь забрать себе как можно больше рекомендаций, но когда сталкиваюсь с реалиями рынка веб разработки в России, мне становится грустно. Никому не нужны тесты, спецификации и проектирование.
Менеджеры хотят сдать проект, получить денег и как можно меньше заплатить разработчику.
Заказчики отличаются от первых только желанием заработать в сети за чужой счет.
Разработчики (процентов 90) вообще не знают предметной области, и работать с ними или дорабатывать после них невозможно.
Мне иногда начинает казаться, что это со мной что-то не так, но после каждой такой статьи понимаю, что нет.
Менеджеры хотят сдать проект, получить денег и как можно меньше заплатить разработчику.
Заказчики отличаются от первых только желанием заработать в сети за чужой счет.
Разработчики (процентов 90) вообще не знают предметной области, и работать с ними или дорабатывать после них невозможно.
Мне иногда начинает казаться, что это со мной что-то не так, но после каждой такой статьи понимаю, что нет.
Если вы имеете в виду web-разработку в сфере рекламных промо-сайтов или e-торговли, то там нет особенной предметной области. Есть в первом случае «креатиффф», а во втором — «натягивание на движок».
Я для себя разделил понятия «разработчик», «frontend-специалист» и «веб-мастер». Чтобы разработать хороший промо-сайт нужен хороший frontend-специалист. Хороший frontend'щик это такой программист, укушенный дизайнером. А веб-мастер — это технолог, специалист по «натягиванию на CMS». Никто из них не лучше и не хуже, просто делают разную работу.
На рынке стартапов и web-приложений есть адекватные заказчики и исполнители, но их действительно меньше, но в этом нет ничего удивительного. Умных людей тоже меньше. Это, я бы сказал, не отраслевая, а общечеловеческая тенденция.
Я для себя разделил понятия «разработчик», «frontend-специалист» и «веб-мастер». Чтобы разработать хороший промо-сайт нужен хороший frontend-специалист. Хороший frontend'щик это такой программист, укушенный дизайнером. А веб-мастер — это технолог, специалист по «натягиванию на CMS». Никто из них не лучше и не хуже, просто делают разную работу.
На рынке стартапов и web-приложений есть адекватные заказчики и исполнители, но их действительно меньше, но в этом нет ничего удивительного. Умных людей тоже меньше. Это, я бы сказал, не отраслевая, а общечеловеческая тенденция.
Когда интеграция дизайна в систему выглядит так, будто ее делала шимпанзе два дня изучающая язык программирования, а заказчика все устраивает и он обвиняет тебя а криворукости, мировоззрение подкашивается.
Или когда разработчик с 10ти летнем стажем не может разобрать код на ангуляр.
Сам я фулл-стак разработчик. Не претендую на идеальные знания в каждой конкретной области, но то что мне попадает на доработку, никак кроме как хламом назвать нельзя.
Или когда разработчик с 10ти летнем стажем не может разобрать код на ангуляр.
Сам я фулл-стак разработчик. Не претендую на идеальные знания в каждой конкретной области, но то что мне попадает на доработку, никак кроме как хламом назвать нельзя.
Статья это теория, а работа это практика. И, как говорится: «Когда теория сталкивается с практикой практика побеждает, всегда.»
Большая часть работы делается людьми, которые не читают статей, а работу работают. С одной стороны — они каждый раз ходят по граблям, на которые уже есть подробные мануалы. А с другой — они делают реальные вещи. Поэтому когда в проекте есть один-два любознательных или просто достаточно опытных человека, которые знают теорию на них приходится десяток тех кто не знает и «мы всегда так работали и всё получалось». А в такой ситуации победить теоретик может только если он начальник, причём желательно самый главный.
К сожалению это суровая реальность работы с людьми.
Большая часть работы делается людьми, которые не читают статей, а работу работают. С одной стороны — они каждый раз ходят по граблям, на которые уже есть подробные мануалы. А с другой — они делают реальные вещи. Поэтому когда в проекте есть один-два любознательных или просто достаточно опытных человека, которые знают теорию на них приходится десяток тех кто не знает и «мы всегда так работали и всё получалось». А в такой ситуации победить теоретик может только если он начальник, причём желательно самый главный.
К сожалению это суровая реальность работы с людьми.
Я работу работаю, как и большинство хабражителей, как я думаю. Выпускаю в год около 20 проектов как фрилансер или через ИП + множество доработок готовых сайтов, но у меня есть время почитать про новый фреймворк, увидеть его плюсы и применить в следующем проекте, предложить заказчику новые возможности для его проекта, объяснить почему ООП верстка лучше макаронной, изучить и проверить в работе паттерны проектирования, попробовать разработать сайт на другом языке (Python, Ruby) зная требования по безопасности / скорости / особенности проекта.
Только я обычный человек, который любит свою работу, ничем не выделяющийся среди тысяч разработчиков, и мне не понятно, почему большая часть рынка считает что заказчику достаточно продать битрикс и левой пяткой «натянуть шаблон» без юнит тестов, без вникания в бизнес / наполнение и прочие моменты,
Только я обычный человек, который любит свою работу, ничем не выделяющийся среди тысяч разработчиков, и мне не понятно, почему большая часть рынка считает что заказчику достаточно продать битрикс и левой пяткой «натянуть шаблон» без юнит тестов, без вникания в бизнес / наполнение и прочие моменты,
Вы правы. Я успел походить по граблям «мы так уже делали». К счастью, сейчас я могу выбирать с кем мне работать, а с кем — нет. Если взгляды не совпадают, работу даже не начинаем.
Пока меня не закидали помидорами в комментариях, поспешу раскрыть идею с отсутствием тестов и «костыльными» частями системы.
я ведь верно понял Вашу мысль, что все то, что не стоит тестирования — не стоит того, чтобы мы этим занимались и является явным кандидатом на отправку в outsource?
Ага. Если ваш процесс позволяет. Причем меня еще крамольная мысль посетила. Откуда берется демпинг на рынке? Молодые студии напрочь игнорируют риски. Соответственно estimation для них равен deadline'у. И для простых проектов (Promo, Landing, и т.д.) вероятность не наступления риска в целом велика. Если задача не срочная, то можно тупо давать подрядчику с договором, в котором прописано, что за 20% срыв сроков можно не платить. Первые не справились, пошли дальше, вторые не справились — дальше, времени больше нет? Идем к взрослым исполнителем. Это жестоко по отношению к оптимистичным ребятам, но в целом для отрасли будет полезно, чтобы разброс цен и сроков был по меньше и более реальный.
Примерно этим занимаются крупные digital-агенства в России.
Да, примерно так чаще всего организуется и в пределах компании (деревни), по моему опыту.
Тогда еще один момент — в следующем абзаце, после процитированной фразы, складывается впечатление, что неизменность требований каким-то образом коррелирует с их важностью. Скорее всего — смысл вкладывался другой, но вот так вот выглядит, на первый взгляд.
Вам не кажется, что код (кейс) может быть ответственным, но, все-еще неустановившимся? И тестирование, в таких «нестабильных» случаях, возможно даже более важно, чем обычно?
Тогда еще один момент — в следующем абзаце, после процитированной фразы, складывается впечатление, что неизменность требований каким-то образом коррелирует с их важностью. Скорее всего — смысл вкладывался другой, но вот так вот выглядит, на первый взгляд.
Вам не кажется, что код (кейс) может быть ответственным, но, все-еще неустановившимся? И тестирование, в таких «нестабильных» случаях, возможно даже более важно, чем обычно?
А можно пример реальный какой-то? Понял общее направление мысли, но дьявол, думаю в деталях.
По первому моменту, или по второму?
По первому — в деревне такие задачи отдаются подмастерьям.
По второму, можно и не опускаться до частностей (там от контекста много зависит, обычно), вот Ваша цитата:
Насколько я понимаю — тесты — это хороший способ описания проблемы. Нестабильность, чаще всего, объясняется отсутствием ясности. Бизнес-правила через упорно улучшаемые тесты (по хорошему — до написания кода), в идеальном случае, опять же, ясность призваны усилить.
По первому — в деревне такие задачи отдаются подмастерьям.
По второму, можно и не опускаться до частностей (там от контекста много зависит, обычно), вот Ваша цитата:
Старайтесь использовать общепринятые методы специфицирования… закрепите основные бизнес-правила системы в unit-тестах
Насколько я понимаю — тесты — это хороший способ описания проблемы. Нестабильность, чаще всего, объясняется отсутствием ясности. Бизнес-правила через упорно улучшаемые тесты (по хорошему — до написания кода), в идеальном случае, опять же, ясность призваны усилить.
Да, я про второй момент. Я с вами согласен. Речь шла о том, что покрытие тестами тоже нам много чего стоит (привет, Дарт Автотестиус). Поэтому я противник покрытия 98% или типа того. Какое-то сливание бюджета в унитаз просто. Но в сложных местах — это просто необходимость: бородатые примеры с упавшем спутником и Knight Capital. Если цена ошибки низкая — проще fail fast. Я в этом смысле.
А про деревню это вы хорошо подметили. Надо на заметку взять: Countryside Driven Development.
А про деревню это вы хорошо подметили. Надо на заметку взять: Countryside Driven Development.
Ну… тут речь не о тестах, в таком случае, а о фанатизме. Фанатизм обладает свойством одинаково опускать любую сторону. И темную и светлую.
Скажу честно — когда я вижу, как модно ругать языки программирования, парадигмы (ООП/процедурный/функциональный и т.п.), всякие банды от четырех до одного с их паттернами, демонстрировать, в конце-концов, свое возмущение методиками вообще или, даже, проектной бюрократией… Ну что сказать. Скорее всего человек чего-то не понимает. Или встречает в своей жизни слишком много фанатов. Хочется ему посочувствовать, но не жалко, совсем. Единственный ему совет — не подходить к сектам, а в игре ценить игру, а не просто акт единения с массами.
С другой стороны — смущает политкорректность в отношении ленности, глупости (следствие первого), высокомерности (следствие второго) и т.п. Не только в людях, но и в проявлениях, в поступках, продукции, так сказать. Но молчишь, конечно. Политкорректно и смущенно.
Скажу честно — когда я вижу, как модно ругать языки программирования, парадигмы (ООП/процедурный/функциональный и т.п.), всякие банды от четырех до одного с их паттернами, демонстрировать, в конце-концов, свое возмущение методиками вообще или, даже, проектной бюрократией… Ну что сказать. Скорее всего человек чего-то не понимает. Или встречает в своей жизни слишком много фанатов. Хочется ему посочувствовать, но не жалко, совсем. Единственный ему совет — не подходить к сектам, а в игре ценить игру, а не просто акт единения с массами.
С другой стороны — смущает политкорректность в отношении ленности, глупости (следствие первого), высокомерности (следствие второго) и т.п. Не только в людях, но и в проявлениях, в поступках, продукции, так сказать. Но молчишь, конечно. Политкорректно и смущенно.
Graceful Degradation для кода с низкой ценностью, хитрое YAGNI
Это очень хорошо описано у Фаулера:
martinfowler.com/bliki/UtilityVsStrategicDichotomy.html
Спасибо, очень актуально для меня )
Нового немного, но такая выжимка позволяет посмотреть на вопрос комплексно и задуматься.
Нового немного, но такая выжимка позволяет посмотреть на вопрос комплексно и задуматься.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Рентабельный код