Комментарии

Паттерн MVC позволяет писать независимые друг от друга блоки кода. Их можно менять отдельно, не затрагивая остальные. Так можно облегчить себе работу, разрабатывая только один программный компонент — независимо от остальных. Например, переписывать способ отображения данных, не трогая способ их обработки.

Это особенно актуально для больших команд. MVC структурирует код и упрощает тестирование, поддержку: с этим паттерном модернизировать можно отдельные блоки, а не всё приложение целиком. Модель позволяет разделить обязанности: пока один программист пишет обработчик данных, другой занят их отображением. В DST Platform это здорово экономит время: каждый работает над своей задачей, не нужно вникать в чужой код, а изменения в одном блоке не влияют на другой.

Паттерн MVC позволяет писать независимые друг от друга блоки кода. Их можно менять отдельно, не затрагивая остальные. Так можно облегчить себе работу, разрабатывая только один программный компонент — независимо от остальных. Например, переписывать способ отображения данных, не трогая способ их обработки.

Это особенно актуально для больших команд. MVC структурирует код и упрощает тестирование, поддержку: с этим паттерном модернизировать можно отдельные блоки, а не всё приложение целиком. Модель позволяет разделить обязанности: пока один программист пишет обработчик данных, другой занят их отображением. В DST Platform это здорово экономит время: каждый работает над своей задачей, не нужно вникать в чужой код, а изменения в одном блоке не влияют на другой.

Ну если просто то MVC помогает грамотно организовать собственный код — по функциям каждого конкретного блока. Это повышает его читаемость. Вам будет проще к нему возвращаться и дорабатывать, а другим разработчикам — легче его понять.

Ну если просто то MVC помогает грамотно организовать собственный код — по функциям каждого конкретного блока. Это повышает его читаемость. Вам будет проще к нему возвращаться и дорабатывать, а другим разработчикам — легче его понять.

Хотелось бы по подробней узнать, зачем использовать паттерн MVC в DST Platform? Какие вообще преимущества и минусы MVC. Также было здорово понять MVC в реальной веб-разработке: как работает контроллер?

Хотелось бы по подробней узнать, зачем использовать паттерн MVC в DST Platform? Какие вообще преимущества и минусы MVC. Также было здорово понять MVC в реальной веб-разработке: как работает контроллер?

Аутсорс хорош, когда заказчик знает что нужно сделать и может это проконтролировать.

Аутсорс хорош, когда заказчик знает что нужно сделать и может это проконтролировать.

Аутсорс хорош, когда заказчик знает что нужно сделать и может это проконтролировать.

Я работаю в компании ICL, но мнение частное.

Про резервных поставщиков согласен. Заказчик должен знать рынок и помнить про лучшее альтернативное решение. И про стоимость перехода на это решение в случае чего.
А чтоб «в случае чего» не случалось, выбирать лучших и заключать с ними добротный контракт с покрытием рисков через штрафы если поставщик факапит.

Про привлечение к проектированию и развитию – тоже весьма за!
ИТ-директор может (и должен!) знать куда идет бизнес, как он развивается или планирует развиваться, он должен думать о том, как можно сделать бизнес лучше, используя ИТ и владеть дорожной картой развития ИТ. И при принятии решений ему весьма полезно знать мнение тех, кому это потом реализовывать и обслуживать :)
Но обязывать не можем. Если он уверен в своих силах и готов решать самостоятельно – это его право.

Суть SLA вы уловили. Главное, чтоб «что, кому, в какие сроки и с каким качеством» было зафиксировано в максимально измеримом виде.

Я работаю в компании ICL, но мнение частное.

Про резервных поставщиков согласен. Заказчик должен знать рынок и помнить про лучшее альтернативное решение. И про стоимость перехода на это решение в случае чего.
А чтоб «в случае чего» не случалось, выбирать лучших и заключать с ними добротный контракт с покрытием рисков через штрафы если поставщик факапит.

Про привлечение к проектированию и развитию – тоже весьма за!
ИТ-директор может (и должен!) знать куда идет бизнес, как он развивается или планирует развиваться, он должен думать о том, как можно сделать бизнес лучше, используя ИТ и владеть дорожной картой развития ИТ. И при принятии решений ему весьма полезно знать мнение тех, кому это потом реализовывать и обслуживать :)
Но обязывать не можем. Если он уверен в своих силах и готов решать самостоятельно – это его право.

Суть SLA вы уловили. Главное, чтоб «что, кому, в какие сроки и с каким качеством» было зафиксировано в максимально измеримом виде.

Я работаю в компании ICL, но мнение частное.

Про резервных поставщиков согласен. Заказчик должен знать рынок и помнить про лучшее альтернативное решение. И про стоимость перехода на это решение в случае чего.
А чтоб «в случае чего» не случалось, выбирать лучших и заключать с ними добротный контракт с покрытием рисков через штрафы если поставщик факапит.

Про привлечение к проектированию и развитию – тоже весьма за!
ИТ-директор может (и должен!) знать куда идет бизнес, как он развивается или планирует развиваться, он должен думать о том, как можно сделать бизнес лучше, используя ИТ и владеть дорожной картой развития ИТ. И при принятии решений ему весьма полезно знать мнение тех, кому это потом реализовывать и обслуживать :)
Но обязывать не можем. Если он уверен в своих силах и готов решать самостоятельно – это его право.

Суть SLA вы уловили. Главное, чтоб «что, кому, в какие сроки и с каким качеством» было зафиксировано в максимально измеримом виде.

1) Нельзя выбирать одного аутсорсера. Всегда необходим основной и резервный поставщик услуг, особенно в российских реалиях.

2) Заказчик обязан (а не может) привлекать аутсорсера в вопросах проектирования и развития архитектуры. Если этого не происходит, то аутсорсер не может контролировать объем задач по поддержке (заказчик может плохо спроектировать систему), а значит, не может предложить адекватного ценообразования своих услуг. Ни о какой синергии в этом случае также речи не идет.

3) «Ключевой показатель для решения о заключении контракта – Service Level Agreement (соглашение об уровне предоставления услуг)» — как по мне, дак это понятность для обоих сторон (на всех уровнях) что и как будет делаться, а что делаться не будет, а не возвышенная терминология.

1) Нельзя выбирать одного аутсорсера. Всегда необходим основной и резервный поставщик услуг, особенно в российских реалиях.

2) Заказчик обязан (а не может) привлекать аутсорсера в вопросах проектирования и развития архитектуры. Если этого не происходит, то аутсорсер не может контролировать объем задач по поддержке (заказчик может плохо спроектировать систему), а значит, не может предложить адекватного ценообразования своих услуг. Ни о какой синергии в этом случае также речи не идет.

3) «Ключевой показатель для решения о заключении контракта – Service Level Agreement (соглашение об уровне предоставления услуг)» — как по мне, дак это понятность для обоих сторон (на всех уровнях) что и как будет делаться, а что делаться не будет, а не возвышенная терминология.

1) Нельзя выбирать одного аутсорсера. Всегда необходим основной и резервный поставщик услуг, особенно в российских реалиях.

2) Заказчик обязан (а не может) привлекать аутсорсера в вопросах проектирования и развития архитектуры. Если этого не происходит, то аутсорсер не может контролировать объем задач по поддержке (заказчик может плохо спроектировать систему), а значит, не может предложить адекватного ценообразования своих услуг. Ни о какой синергии в этом случае также речи не идет.

3) «Ключевой показатель для решения о заключении контракта – Service Level Agreement (соглашение об уровне предоставления услуг)» — как по мне, дак это понятность для обоих сторон (на всех уровнях) что и как будет делаться, а что делаться не будет, а не возвышенная терминология.

Ну если не полностью покрывают, то точно не позволяют расслабиться и нарушать сроки.

Ну если не полностью покрывают, то точно не позволяют расслабиться и нарушать сроки.

Ну если не полностью покрывают, то точно не позволяют расслабиться и нарушать сроки.

Насчёт «штрафов, которые покрывают простои бизнеса» — ни разу таких не видел. Большие штрафы — видел. Компенсацию убытков (недополученной прибыли) — ни разу. Слишком разорительно и слишком легко эксплуатируемо.

Насчёт «штрафов, которые покрывают простои бизнеса» — ни разу таких не видел. Большие штрафы — видел. Компенсацию убытков (недополученной прибыли) — ни разу. Слишком разорительно и слишком легко эксплуатируемо.