да, возможно забыл упомянуть. Обучение студентов этого университета - только начало. В планах у ребят масштабировать эту систему и с прицелом на будущее - возможно как облачный сервис по подписке.
Про бд - это кластер postgres. У каждого сервиса своя бд.
Про согласованноость данных если, то в подавляющем большинстве сервисы слабо связаны по данным, тут больше про доступность. Но есть связка сервисов (пользователи, группы, зачетка) - для некоторых флоу использовался механизм с компенсирующими транзакциями, для других же - на основе подтверждений. По разработчикам могу сказать, что работы хватало всем. В разные этапы на проекте работало от 6 ти до 11 разработчиков (бэк+фронт, помимо аналитиков, тестировщиков и прочих) и по уровню разработчиков - участвовали это middle и выше
По поводу rpc на php - мы реализовывали такое не только на protobuf в этом продукте, но и раннее вполне успешно и с использованием и rabbit и просто по http. Так что тут я не соглашусь. Кажется тут суть в удаленном вызове процедур, а не стеке
Понял. Да, проверка по исправлению возможна, только уже в последующем аудите, то есть новом. Первый, изначальный, подразумевает только "найти" ошибки уже существующие, а не то, как их подлатали после тыка на них.
Но, предполагаю, что бывает и тот случай, когда договоренность есть и на последующую проверку по исправлению в контексте изначального аудита. В общем, это уже индивидуально все, а так, как и писал ранее, - аудит проверяет, разработчик исправляет, а аудитор в дальнейшем готовит новый аудит, если он требуется.
*Для избежания подобных косяков нужна изначально хорошая команда, кьюа-ребята, ну и внимательность, конечно. Но у любого проекта есть некая требовательность к аудиту, особенно в случае масштабирования крупного, который по срокам и деньгам весит прилично.
Если вы имеете ввиду, исправляем ли мы чужие косяки, то да, но это уже не аудит, а разработка. Аудит подразумевает "найти" любой косяк, а не "решить" его. Все зависит от договоренности: если клиент уволил первого разработчика и договорился с аудиторами на переоформление работы - то да, конечно.
Конечно, аудит не стоит 50%, далеко не: если представить, что проект стоит NNN, то аудит его 12-nnn часть. То есть аудит = +-5% от стоимости такого проекта. Мы не делали разработку, точные сроки не знаем. По количеству кода/функционала сроки разработки такой системы будет около 1,5 лет.
Аудит же предоставляет рекомендации к исправлениям, ну а разработчики имеют право сопротивляться и оспаривать. Смысл аудита не в "накосячить еще на один аудит", а исключить косяки и помочь исправлять уже существующие. И, да, у аудитора нет выгоды в "накосячить еще больше".
После аудита мы связывались с разработчиками чтобы обсудить рекомендации, интересующие вопросы и т.д.
Вопрос немного риторический, однако ответ можно сформулировать как "потому что мы все одна команда и у нас есть задача выполнить свою работу, прикрывая друг-друга" ;)
да, возможно забыл упомянуть. Обучение студентов этого университета - только начало. В планах у ребят масштабировать эту систему и с прицелом на будущее - возможно как облачный сервис по подписке.
Про бд - это кластер postgres. У каждого сервиса своя бд.
Про согласованноость данных если, то в подавляющем большинстве сервисы слабо связаны по данным, тут больше про доступность. Но есть связка сервисов (пользователи, группы, зачетка) - для некоторых флоу использовался механизм с компенсирующими транзакциями, для других же - на основе подтверждений.
По разработчикам могу сказать, что работы хватало всем. В разные этапы на проекте работало от 6 ти до 11 разработчиков (бэк+фронт, помимо аналитиков, тестировщиков и прочих) и по уровню разработчиков - участвовали это middle и выше
По поводу rpc на php - мы реализовывали такое не только на protobuf в этом продукте, но и раннее вполне успешно и с использованием и rabbit и просто по http. Так что тут я не соглашусь. Кажется тут суть в удаленном вызове процедур, а не стеке
ну мы как раз про помочь, думаю, вы тож). За опыт спасибо, интересно!
Понял. Да, проверка по исправлению возможна, только уже в последующем аудите, то есть новом. Первый, изначальный, подразумевает только "найти" ошибки уже существующие, а не то, как их подлатали после тыка на них.
Но, предполагаю, что бывает и тот случай, когда договоренность есть и на последующую проверку по исправлению в контексте изначального аудита. В общем, это уже индивидуально все, а так, как и писал ранее, - аудит проверяет, разработчик исправляет, а аудитор в дальнейшем готовит новый аудит, если он требуется.
*Для избежания подобных косяков нужна изначально хорошая команда, кьюа-ребята, ну и внимательность, конечно. Но у любого проекта есть некая требовательность к аудиту, особенно в случае масштабирования крупного, который по срокам и деньгам весит прилично.
Если вы имеете ввиду, исправляем ли мы чужие косяки, то да, но это уже не аудит, а разработка. Аудит подразумевает "найти" любой косяк, а не "решить" его. Все зависит от договоренности: если клиент уволил первого разработчика и договорился с аудиторами на переоформление работы - то да, конечно.
Конечно, аудит не стоит 50%, далеко не: если представить, что проект стоит NNN, то аудит его 12-nnn часть. То есть аудит = +-5% от стоимости такого проекта. Мы не делали разработку, точные сроки не знаем. По количеству кода/функционала сроки разработки такой системы будет около 1,5 лет.
Аудит же предоставляет рекомендации к исправлениям, ну а разработчики имеют право сопротивляться и оспаривать. Смысл аудита не в "накосячить еще на один аудит", а исключить косяки и помочь исправлять уже существующие. И, да, у аудитора нет выгоды в "накосячить еще больше".
После аудита мы связывались с разработчиками чтобы обсудить рекомендации, интересующие вопросы и т.д.
к сожалению, стоимость разглашать не можем (в процентном соотношении это куда меньше). Но вот если говорить про сроки, то потратили около 2,5 месяцев.
Вопрос немного риторический, однако ответ можно сформулировать как "потому что мы все одна команда и у нас есть задача выполнить свою работу, прикрывая друг-друга" ;)