Комментарии 9
Иногда изменения вносятся на уровне кода, который в будущем может быть перезаписан обновлением шаблона. Это требует создания «обходных путей» или отдельной системы контроля версии, что увеличивает время работы.
У меня тут возникло два вопроса:
В вашей компании считается допустимым править код, который может быть перезаписан при обновлении вендоров? Ведь в любой нормальной CMS можно создать дочернюю тему и переопределять шаблоны в ней.
Вы делаете проекты без системы контроля версий? О_о
1. Правка кода, который может быть перезаписан обновлениями шаблонов.
Мы не считаем это подходом "по умолчанию" и всегда ищем решение, которое минимизирует риски, связанные с обновлениями. Например:
- Если используется CMS с поддержкой дочерних тем (как в WordPress), мы всегда применяем этот подход.
- Когда работа связана с более сложными системами или неочевидными ограничениями (например, кастомизация на уровнях, где нет прямой поддержки дочерних тем), мы разрабатываем кастомный функционал так, чтобы минимизировать вероятность конфликтов с обновлениями. Это могут быть отдельные модули или плагины.
2. Работа без системы контроля версий
Конечно же мы не работаем без системы контроля версий. Использование таких инструментов, как Git, является стандартом для любого проекта в нашей компании. Когда в статье упоминалось создание "отдельной системы контроля версии", имелся в виду процесс, в котором нам иногда приходится создавать отдельные ветки или специальные сценарии работы именно для шаблонов, которые имеют свои особенности. Это дополнительный слой работы, а не альтернатива стандартной системе контроля версий.
Какая-то мешанина.
Как можно сочетать Scrum и Waterfall вместе? Это же две разные методики, одна из которых - короткие итерации и планирование следующих с учетом текущей информации, а вторая - полный план работы на полгода вперёд, расписанный едва ли не по действиям.
Как закрытый код может быть безопаснее открытого? Ведь уязвимости остаются и там и там, злоумышленник на неё всё равно выйдет, а заинтересованный в исправлении никогда не сможет это увидеть. Я понимаю закрытость кода в плане коммерции, но подтягивать сюда безопасность как минимум спорно.
Как уже отметили выше - а где какая-то система контроля версий? Или в битриксе хранятся архивы в виде аттачей к сообщениям на отдельной доске? Без хотя бы гитлаба синхронизация работы в плане версий кода в адищу превращается, где хотя бы упоминание используемого инструмента, если он существует?
В плане коммуникации с заказчиками и команды статья даёт правильные посылы, но в технической реализации будто что-то не дописали, либо исказили реальный рабочий процесс.
1. Как можно сочетать Scrum и Waterfall вместе?
Мы не говорим, что используем эти методологии на проекте совместно, мы лишь о том, что применяем эти подходы на разных проектах в зависимости от условий и требований клиента.
2. Как закрытый код может быть безопаснее открытого?
Давайте уточним, мы не утверждаем, что закрытый или открытый код является априори более безопасным. Мы скорее подсвечиваем то с чем можно столкнутся. С вашим мнением о злоумышленниках согласны.
3.Как уже отметили выше - а где какая-то система контроля версий?
Конечно, система контроля версий используется, и мы полагаемся на Git. Инструменты вроде GitHub помогают нам. В статье это не было упомянуто, и мы согласны, что этот момент нужно было раскрыть, чтобы не возникало сомнений.
Спасибо за подробный комментарий к статье, мы учтем в будущем о упоминании более технических вещей.
Стоит чуть-чуть отойти от готовых решений и всё делается непонятно. Мне был нужен сайт-визитка, я продумал интерфейс, который на мой взгляд был самым обыкновенным, ну кроме каких-то мааааленьких деталей - типа какая страница видна первой, и т.п.. Рассказывал знакомым веб-дизайнерам, они морщились и говорили, что такое делается за полчаса. В результате за несколько лет было сделано пять попыток разными людьми - сделать так как я хотел не получилось ни у кого. Я думаю если бы это делалось не по дружбе, а с нормальным ТЗ, бюджетом, и т.п... то всё было бы сделано, но... но... не за полчаса.
Статья просто пронизана болью, даже выводы дочитать не смог. Болью веб-студии, которой попадаются классические заказчики, которые не знают, что им нужно, и не понимают сложности внедрения и изменения функционала. Будто вернулся на 10 лет назад, когда тоже в такой конторе работал) К сожалению, это очень неблагодарная и рисковая сфера как для бизнеса, так и для разработчиков. И научить всех клиентов "сформировать план работ и выстроить грамотную коммуникацию" точно не получится. Остается посочувствовать и пожелать удачи.
Честно говоря, вся статья выглядит, как оправдание - "почему мы берём столько денег за работу, которую фрилансер сделает за бутылку пива" :D
Здесь вопрос скорее не только в создании, но и поддержке. Потому что фрилансеры часто делают всё без оглядки на будущее. "Собрал по быстрому из готовых решений, исправил в них кое-как код, а что там будет дальше (расширение проекта, поддержка и т.д.) это их не волнует, может как сломается потом ещё раз прибегут с новым заказом".
Конечно есть фрилансеры, которые имеют свои универсальные библиотеки/плагины/мини фреймворки/прочие заготовки и более серьезно подходят к делу, но и берут за свою работу они больше, чем стоит "бутылка пива". Так что баш на баш. Так же, у веб студий есть один плюс для клиентов. Фрилансер сегодня взялся за работу, завтра сбежал. Чем он рискует? Репутацией на платформе? Ничего ему не предъявить, по факту.
Организации же, подписывают обычно договора, по которым просто так "сбежать" не выйдет. Фрилансер тоже может подписать договор, но если он физ. лицо, не получал предоплату и не ставил печать или не подписывал 2 экземпляра лично, т.к. подпись в пдф можно и в фотошопе подделать, то никакой суд не будет рассматривать дело, в отличие от ситуации с договорами между юр. лицами.
Публикации
Правда или миф: почему в разработке не все так быстро, как кажется