Ответы пользователя по тегу Программирование
  • Как технически получают КБМ (коэффициент бонус малус) у страховой?

    @miksir
    IT
    Все движения по ОСАГО (например, оформление полиса) в настоящее время страховые передают в единый реестр. Ну и КБМ тоже. Соответственно, оттуда он и запрашивается. Для страховых есть API
    dkbm-web.autoins.ru/dkbm-web-1.0/kbm.htm
    Ответ написан
  • Как должен вести себя нормальный PM?

    @miksir
    IT
    Начните пользоваться трекером, хотя бы. Все задачи - через трекер. Задачи должны декомпозироваться на мелкие, до 8-16 часов, хотя бы. Приоритетом могут управлять менеджеры, хоть 10 - пусть сами дерутся. Принципиально не меняете задачу, не закончив ее (ну, за исключением хотфиксов). Но учитывайте , что тут больше к вам требований, чем к ПМ-ам - правильно декомпозировать проект, оценить задачу и выдержать время, и да, это тоже занимает время.
    А найти хорошего ПМ-а еще сложнее, чем хорошего программиста.
    Ответ написан
    Комментировать
  • Что такое enterprise разработка на самом деле?

    @miksir
    IT
    Enterprise разработка - это разработка, направленная на решение проблем бизнеса. В отличии от разработки для решения проблем конечных пользователей.

    На самом деле нет каких-то зафиксированных принципиальных характеристик, которые присущи только EA. По-этому, в разговорной речи понятие "энтерпрайз" может значить весьма разные вещи. С одной стороны энтерпрайз - не про увлечение модой с переписыванием всего, как только появится новый тренд. Ибо это _дорого_, так как цена ошибки дорога. С другой стороны - совсем не обязательно, что это 20-летние технологии. Конкретный бизнес сам для себя выбирает модели развития и обновления стека технологий. С одной стороны - это сложность ПО, бизнес-логики. С другой - сложность понятие весьма относительное.

    Но если все же пытаться выделить какие-то характерные черты, я бы назвал несколько:
    * устойчивость к трендам (использование их, когда они пройдут стадию моды и перейдут к стадии заинтересованности крупными игроками, ибо никому не нужны технологии, которые через год умрут и их поддержка будет дорожать каждый день).
    * сложная и непостоянная бизнес-логика, давление на нее из множества источников
    * результат сложной переменчивой бизнес-логики в совокупности с длительным использованием продукта приводит к целям снижения стоимости поддержки за счет стоимости первоначальной разработки, производительности и потребляемых ресурсов. ООП, SOLID, Unit Test/TDD, DDD - все эти популярные буквы - последствия "энтерпрайза", когда мы готовы серьезно подходить к написанию кода для облегчения его последующего изменения.
    * слабо заметный вклад конкретного программиста, проистекает из сложности ПО

    Требования к программисту... ну я бы сказал, усидчивость, вдумчивость, исполнительность... хм, а что, в каких-то других областях другие требования к программистам? Хотя, конечно, в противоположность, можно назвать способ разработки "быстро-быстро и в продакшн". Но, к слову, такие ситуации могут и в энтерпрайзе возникнуть.

    По-этому, стоит рассматривать не энтерпрайз/не энтерпрайз, а конкретные компании с конкретными требованиями и циклами разработки.
    Ответ написан
    1 комментарий
  • Что делать первым? Дизайн и интерфейсы или серверную разработку? (backend/API)?

    @miksir
    IT
    Зависит от обстоятельств. И от того, что приоритетнее - затраты или сроки.

    Если у нас есть подробное ТЗ на функционал, по которому работает как бекенд, так и дизайнеры, то разработка может идти одновременно с дизайном. Или есть интеграционные задачи с системами заказчика, по которым можно работать без дизайна вообще - разработке ждать дизайн не нужно.

    Или, если UI команда занимается только разрисовкой стандартных шаблонов - то почти всю разработку можно закончить и без макетов. Но, если есть этап целеориентированного проектирования, т.е. на старте нет понимания того, какой функционал будет реализован, то стоит подождать прототипов. Хотя даже в этом случае - базовые модели данных редко меняются.

    С опытом управления разработкой приходит понимание, что именно может сильно поменяться после отриcовки UI, а что нет. И это "нет" можно запустить в разработку. Ну а ошибки такого понимания рефакторятся - в большинстве случаев это будет все-равно быстрее, хотя и затратнее.

    С мобильным приложением как-то так же. Мы знаем базовые модели данных, можем делать АПИ. Но по мере отрисовки экранов приложения - АПИ может меняться, дополняться.
    Ответ написан
    Комментировать