Давно хотелось как-то записать свои мысли по тому, как лучше организовывать пайплайн контента и его проверок.
В больших проектах, когда скорость разработки контента и его качество сравнимо по важности с надежностью кода и его стабильностью, а по объему значительно превышает его, построение хорошего пайплайна разработки контента становится крайне важным мероприятием.
При этом главное решить для себя что такое правильный и хороший пайплайн.
С одной стороны надо давать производителям контента гибкие и удобные инструменты, а с другой стороны, постоянно следить, что бы гибкость не перерастала в хаос. К сожалению слишком часто сталкивались с ситуациями, когда попытка выдать микроскоп, приводила к тому, что им начинали заколачивать гвозди, не заказывая молоток.
Сначала я думал, что надо как-то ограничивать доступ к микроскопу, чтобы те, кто им не умеют пользоваться не могли взять его в руки, а потом понял, что это полностью неправильный подход. Гораздо легче написать несколько тестов на то, что инструмент используется правильно и отлавливать неправильные случаи использования, объясняя как надо делать правильно. Так и только так можно добиться исправления основной причины ошибки, которая вовсе не в том, что гвоздь забили микроскопом. В конце концов, цель забить гвоздь выполнена и не принципиально как именно, жалко только что время потрачено глупо. Причина ошибки в голове того, кто не подумал заказать молоток и именно ее надо поймать и исправить. Научить человека работать правильно.
Любые запретительные меры бесполезны, если вы не предоставляете человеческой мысли удобное русло, то сначала, она будет накапливаться перед вашими дамбами, там загниет и вот эта тухлятина через некоторое время прорвется и затопит или весь проект или приличную его часть.
Т.к. человек всегда идет по наиболее простому сценарию, надо огромное количество усилий прикладывать к тому, чтобы правильный сценарий использования функционала был и наиболее удобным. Понятно, что всегда есть технологически сложные моменты, которые никуда не денутся, но при этом надо чтобы даже там, правильный путь, был наиболее удобным.
Особенно внимательно относитесь к жалобам людей на неудобства в использовании правильного сценария. Сам факт жалобу указывает что чувство прекрасного сотрудника уже идентично вашему и оно протестует против неудобства на правильном пути и противится хакам и обходам. На такие жалобы надо реагировать максимально быстро, потому как правильный способ мышления, наша величайшая ценность и она под угрозой.
Здесь надо обратить внимание, что одним из краеугольных камней данной системы является то, что у исправления ошибок должен быть более высокий приоритет, чем у создания новых фичей и контента. Иначе все ваши чекеры, билды отлавливающие странные ситуации не заставят людей думать правильно. Ведь именно исправление ошибки, правильным использованием фичи — читать — правильное понимание фичи в мозгу создателя контента — является нашим самым желанным результатом. Важно чтобы времени прошло мало и человек не забыл, что и зачем он делал. Иначе понятие правильно и неправильно у него в мозгу не свяжутся прочно.
Конечна данная система должна постоянно эволюционировать вместе с проектом. По возможности находя очередное феерическое «скрещивание микроскопа, молотка и газонокосилки» надо аккуратно добавлять его в тесты. Конечно в идеальном мире, надо продумывать все это пока фича еще в разработке, но в реальном такое почти не получается делать. К сожалению (((.
Еще стоит отметить, что не стоит увлекаться сложностью чеков, т.к. всегда стоит понимать, что дизайн может поменяться и часть ограничений надо будет снимать. Поэтому лучше много маленьких тривиальных проверок, которые легко переписывать, дополнять, или отключать при необходимости, чем несколько мега крутых, сложных чеков, в которых вы сами не разберетесь через месяц, не прочитав толмуд описания. Оно вам надо? Поймите, точнее вспомните о том, что вам потом еще объяснять логичность этой ошибки человеку делающему контент, который зачастую ни разу не технический специалист. Желательно чтобы сам факт провала проверки практически однозначно указывал на ошибку. Не забывайте, наша цель головы наших сотрудников, которые тоже хотят делать все правильно, просто не всегда понимают сразу как. Простые проверки легко донести до их понимания.
Вас пугает, что одна ошибка породит кучу провалившихся тестов? Зря! Чем больше тестов провалилось, тем глубже допущена ошибка, тем она важнее. Это ведь прекрасно, когда поглядев на отчет, можно сразу оценить масштаб катастрофы, не вчитываясь в детали.
К этому конечно стоит прибавить безжалостную войну с дублированием. Это один из злейших врагов всего IT. Скопировать дом в реальном мире, и добавить на него пару рющечек, в реальном мире равносильно постройке нового дома. В IT к сожалению это дело нескольких кликов. В итоге потом выясняется, что у этого дома плохо спроэктирован фундамент и его надо переделать. В итоге зачастую переделывается только оригинал, а копии продолжают нести в себе все баги, пока их не найдут отдельно. Ужасная, но к сожалению регулярная ситуация. Если с кодом это можно хоть как-то забороть, то с данными автоматически это сделать очень тяжело.
Единственное что можно делать легко, это уничтожать дублирование между полями данных. Благо это можно делать в собственном мозгу. Далее находя потенциальные функциональные зависимости, надо или сразу истреблять их, или делать процедуры, которые будут реализовывать эти функциональные зависимости. Т.е. объявляя одно из полей исходным, мы жестко перепрописываем значения в зависимых, даже если руками их кто-то пытается выставить в другое значение, помечая изменение, как сделанное автоматически. Обычно человек видя, что его значение сбрасывает автоматика, понимает, что не прав и делает все как положено.
К раздолбаям и любителям всегда делать по своему не желающим учиться, система должна быть безжалостна. Их головы это неисправимые ошибки в системе и от них лучше избавляться. Поэтому их вопли о железном занавесе и запрете креатива не стоит особо слушать. Креатив это умение сделать красиво в указанных рамках, а не вообще как моя левая пятка хочет.
Подводя итог.
Правильный пайплайн должен быть удобным для правильного использования и агрессивен к неправильному.
Простые чеки, простые и понятные тулзы, простые интерфейсы, сами подсказывают людям как делать правильно.
Неправильно использование пресекается по возможности мягко, но безальтернативно. Обход должен быть крайне затруднен. Помните человек всегда пойдет туда где проще, поэтому приглашайте его на правильный путь, затрудняя неправильные.
В больших проектах, когда скорость разработки контента и его качество сравнимо по важности с надежностью кода и его стабильностью, а по объему значительно превышает его, построение хорошего пайплайна разработки контента становится крайне важным мероприятием.
При этом главное решить для себя что такое правильный и хороший пайплайн.
С одной стороны надо давать производителям контента гибкие и удобные инструменты, а с другой стороны, постоянно следить, что бы гибкость не перерастала в хаос. К сожалению слишком часто сталкивались с ситуациями, когда попытка выдать микроскоп, приводила к тому, что им начинали заколачивать гвозди, не заказывая молоток.
Сначала я думал, что надо как-то ограничивать доступ к микроскопу, чтобы те, кто им не умеют пользоваться не могли взять его в руки, а потом понял, что это полностью неправильный подход. Гораздо легче написать несколько тестов на то, что инструмент используется правильно и отлавливать неправильные случаи использования, объясняя как надо делать правильно. Так и только так можно добиться исправления основной причины ошибки, которая вовсе не в том, что гвоздь забили микроскопом. В конце концов, цель забить гвоздь выполнена и не принципиально как именно, жалко только что время потрачено глупо. Причина ошибки в голове того, кто не подумал заказать молоток и именно ее надо поймать и исправить. Научить человека работать правильно.
Любые запретительные меры бесполезны, если вы не предоставляете человеческой мысли удобное русло, то сначала, она будет накапливаться перед вашими дамбами, там загниет и вот эта тухлятина через некоторое время прорвется и затопит или весь проект или приличную его часть.
Т.к. человек всегда идет по наиболее простому сценарию, надо огромное количество усилий прикладывать к тому, чтобы правильный сценарий использования функционала был и наиболее удобным. Понятно, что всегда есть технологически сложные моменты, которые никуда не денутся, но при этом надо чтобы даже там, правильный путь, был наиболее удобным.
Особенно внимательно относитесь к жалобам людей на неудобства в использовании правильного сценария. Сам факт жалобу указывает что чувство прекрасного сотрудника уже идентично вашему и оно протестует против неудобства на правильном пути и противится хакам и обходам. На такие жалобы надо реагировать максимально быстро, потому как правильный способ мышления, наша величайшая ценность и она под угрозой.
Здесь надо обратить внимание, что одним из краеугольных камней данной системы является то, что у исправления ошибок должен быть более высокий приоритет, чем у создания новых фичей и контента. Иначе все ваши чекеры, билды отлавливающие странные ситуации не заставят людей думать правильно. Ведь именно исправление ошибки, правильным использованием фичи — читать — правильное понимание фичи в мозгу создателя контента — является нашим самым желанным результатом. Важно чтобы времени прошло мало и человек не забыл, что и зачем он делал. Иначе понятие правильно и неправильно у него в мозгу не свяжутся прочно.
Конечна данная система должна постоянно эволюционировать вместе с проектом. По возможности находя очередное феерическое «скрещивание микроскопа, молотка и газонокосилки» надо аккуратно добавлять его в тесты. Конечно в идеальном мире, надо продумывать все это пока фича еще в разработке, но в реальном такое почти не получается делать. К сожалению (((.
Еще стоит отметить, что не стоит увлекаться сложностью чеков, т.к. всегда стоит понимать, что дизайн может поменяться и часть ограничений надо будет снимать. Поэтому лучше много маленьких тривиальных проверок, которые легко переписывать, дополнять, или отключать при необходимости, чем несколько мега крутых, сложных чеков, в которых вы сами не разберетесь через месяц, не прочитав толмуд описания. Оно вам надо? Поймите, точнее вспомните о том, что вам потом еще объяснять логичность этой ошибки человеку делающему контент, который зачастую ни разу не технический специалист. Желательно чтобы сам факт провала проверки практически однозначно указывал на ошибку. Не забывайте, наша цель головы наших сотрудников, которые тоже хотят делать все правильно, просто не всегда понимают сразу как. Простые проверки легко донести до их понимания.
Вас пугает, что одна ошибка породит кучу провалившихся тестов? Зря! Чем больше тестов провалилось, тем глубже допущена ошибка, тем она важнее. Это ведь прекрасно, когда поглядев на отчет, можно сразу оценить масштаб катастрофы, не вчитываясь в детали.
К этому конечно стоит прибавить безжалостную войну с дублированием. Это один из злейших врагов всего IT. Скопировать дом в реальном мире, и добавить на него пару рющечек, в реальном мире равносильно постройке нового дома. В IT к сожалению это дело нескольких кликов. В итоге потом выясняется, что у этого дома плохо спроэктирован фундамент и его надо переделать. В итоге зачастую переделывается только оригинал, а копии продолжают нести в себе все баги, пока их не найдут отдельно. Ужасная, но к сожалению регулярная ситуация. Если с кодом это можно хоть как-то забороть, то с данными автоматически это сделать очень тяжело.
Единственное что можно делать легко, это уничтожать дублирование между полями данных. Благо это можно делать в собственном мозгу. Далее находя потенциальные функциональные зависимости, надо или сразу истреблять их, или делать процедуры, которые будут реализовывать эти функциональные зависимости. Т.е. объявляя одно из полей исходным, мы жестко перепрописываем значения в зависимых, даже если руками их кто-то пытается выставить в другое значение, помечая изменение, как сделанное автоматически. Обычно человек видя, что его значение сбрасывает автоматика, понимает, что не прав и делает все как положено.
К раздолбаям и любителям всегда делать по своему не желающим учиться, система должна быть безжалостна. Их головы это неисправимые ошибки в системе и от них лучше избавляться. Поэтому их вопли о железном занавесе и запрете креатива не стоит особо слушать. Креатив это умение сделать красиво в указанных рамках, а не вообще как моя левая пятка хочет.
Подводя итог.
Правильный пайплайн должен быть удобным для правильного использования и агрессивен к неправильному.
Простые чеки, простые и понятные тулзы, простые интерфейсы, сами подсказывают людям как делать правильно.
Неправильно использование пресекается по возможности мягко, но безальтернативно. Обход должен быть крайне затруднен. Помните человек всегда пойдет туда где проще, поэтому приглашайте его на правильный путь, затрудняя неправильные.
