Про обязательные и необязательные параметры в ТЗ
Сегодня расскажу про немного очевидную вещь, но про которую, тем не менее, часто забывают.
Если вы интегрируетесь с другой системой, очень важно разбираться с обязательностью параметров для передачи партнеру и обязательностью параметров в ответе. Если вы не показываете документацию партнера разработчику, а пишете по ней свою (по разным причинам - слишком длинная, слишком запутанная, нужно время, чтобы разобраться и т.д) - не оставляйте определение "обязательности" на усмотрение разработчика. Не потому, что это не его дело, а потому что параметр, который кажется на первый взгляд обязательным, может оказаться совсем не таким.
Например, интеграция с кинотеатрами: вы делаете приложение про покупку билета в кино и забираете у систем-партнеров список фильмов, чтобы показать пользователю. В дизайне у каждого фильма стоит дата премьеры, и разработчик закладывается на то, что этот параметр приходит всегда, и в целом он рассуждает логично - у какого фильма может не быть даты премьеры? Но вы не знаете, как работает система партнера, обязательна ли у них дата премьеры для заведения фильма в систему. Возможно, в какой-то момент контент-менеджер забудет ее проставить и ваше приложение либо ломается, не получая обязательный параметр, либо пользователь не видит в списке фильм, который хотел посмотреть.
Там, где вам обязательность/необязательность кажется странной, нужно обсуждать эту обязательность с партнером - может быть, это опечатка в документации, а может быть, партнер расскажет вам какие-то нетривиальные примеры, которые вы не учли, где этого параметра может не быть. И здесь очень важно не закладываться на слова "да это просто в документации он необязательный, но на самом деле он практически всегда есть" - всегда лучше перестраховаться.
Сегодня расскажу про немного очевидную вещь, но про которую, тем не менее, часто забывают.
Если вы интегрируетесь с другой системой, очень важно разбираться с обязательностью параметров для передачи партнеру и обязательностью параметров в ответе. Если вы не показываете документацию партнера разработчику, а пишете по ней свою (по разным причинам - слишком длинная, слишком запутанная, нужно время, чтобы разобраться и т.д) - не оставляйте определение "обязательности" на усмотрение разработчика. Не потому, что это не его дело, а потому что параметр, который кажется на первый взгляд обязательным, может оказаться совсем не таким.
Например, интеграция с кинотеатрами: вы делаете приложение про покупку билета в кино и забираете у систем-партнеров список фильмов, чтобы показать пользователю. В дизайне у каждого фильма стоит дата премьеры, и разработчик закладывается на то, что этот параметр приходит всегда, и в целом он рассуждает логично - у какого фильма может не быть даты премьеры? Но вы не знаете, как работает система партнера, обязательна ли у них дата премьеры для заведения фильма в систему. Возможно, в какой-то момент контент-менеджер забудет ее проставить и ваше приложение либо ломается, не получая обязательный параметр, либо пользователь не видит в списке фильм, который хотел посмотреть.
Там, где вам обязательность/необязательность кажется странной, нужно обсуждать эту обязательность с партнером - может быть, это опечатка в документации, а может быть, партнер расскажет вам какие-то нетривиальные примеры, которые вы не учли, где этого параметра может не быть. И здесь очень важно не закладываться на слова "да это просто в документации он необязательный, но на самом деле он практически всегда есть" - всегда лучше перестраховаться.