• Откуда мифы про Agile


      Сейчас много говорят о гибких подходах к разработке программного обеспечения. И даже пытаются внедрить для выполнения гос. контрактов. С другой стороны, много компаний спотыкаются на этих подходах. И хотя в компаниях делают что нужно, и даже Scrum-мастер в них есть, программный Продукт почему-то перестает развиваться, и появляется много задач на исправление дефектов. Давайте разберемся почему так происходит.

      Читать дальше →
    • Хороший дизайн, плохой дизайн…


        Иногда, открываешь какой-нибудь проект с историей и понимаешь, что история и у этого проекта была длинная… Да еще и авторы менялись, и видно, что у них был небольшой опыт.

        В чем это выражается? — В том, что все части системы настолько переплетены, что невозможно оторвать один кусок и использовать где-то еще. Как результат, такой проект, конечно невозможно накрыть никакими модульными тестами кроме как приемочными со стороны группы QA. А значит, что со временем стоимость доработки будет возрастать, так как мы теряем уверенность в том, что наши изменения не поломают какие-то другие части.

        Проблемы и решения
      • Применение Теории Ограничений для постановки процесса

          В деятельности менеджера всегда есть какая-то доля работы связанная с постановкой бизнес-процессов. Как правило это необходимо когда появляются новые потребности компании, бОльший оборот, лучшая стабильность по денежному потоку или просто внедрить каике-то улучшения. Иногда бывает, что мы сталкиваемся только с симптомами или нежелательными явлениями, когда что-то идет не так: «продалбываем» сроки, заказчик недоволен, слишком большие расходы на содержание инфраструктуры или иные издержки. Между этими двумя позициями есть общая деталь: если есть потребность к изменению значит что-то эти улучшения сдерживает, и это можно расценивать как нежелательное явление. Когда мы начинаем разбираться в ситуации, то можем собрать множество разрозненных фактов из которых понятно только то, что изменения требуются. но с чего начать? Как минимальными усилиями провести изменения?


          И тоже самое можно сказать о конфликтах в команде. Когда видишь конфликт интересов но решить его в лоб, административным рычагом, будет не самым правильным выходом. Нужно искать корневую причину конфликта и решать ее.


          Алгоритм решения
          • +11
          • 8,3k
          • 4
        • CxxMock — принцип действия


            Иногда бывает интересно изучить архитектуру какого либо изделия, и посмотреть как оно устроено. Вот бывало разберешь часы, а обратно собрать не можешь… Но в отличии от часов программные продукты при доступе к исходникам можно разобрать, и собрать. А найденные решения применять уже в своей практике.

            Когда у меня возникла необходимость в создании CxxMock, о котором я писал в статье CxxMock — Mock-объекты в C++, я разобрал принцип действия похожего GoogleMock. Или еще раньше разобрал основную идею c10k сервера mathopd, что последующих проектах позволило мне лучше маневрировать в проектировании архитектуры.

            Поэтому, я расскажу об основных концепциях и за счет которых работает CxxMock. И которые было интересно придумывать. Возможно, некоторые трюки покажутся вам простыми, а другие смогут вам помочь в вашей практике.
            CxxMock взгляд изнутри
          • CxxMock — Mock-объекты в C++

            • Tutorial
            Если вы верите в Agile и разработка через тестирование для вас является нормой, а не какой-то непонятной практикой, но наверное столкнулись с такой нехорошей проблемой как организацией тестирования объектов которые используют другие объекты через интерфейсы на C++.

            Если для .NET есть замечательная библиотека Rhino.Mocks, которой достаточно «скормить» интерфейс и вы получаете возможность программирования поведения методов интерфейса прямо в модульном тесте. То для С++ все сильно сложнее, так как нет замечательного рефлекшена который позволяет строить код во время исполнения. И приходится писать объекты-заглушки вручную. И в случае изменения интерфейса приходится не только обновлять все классы в приложении но обновлять весь набор «одноразовых» классов заглушек реализующих интерфейс которые применяются в тестах.
            Читать дальше →
            • +15
            • 13,7k
            • 6
          • Проектная кухня. Снижение архитектурных рисков проекта

              За свой опыт в разработке ПО я работал на многих проектах, и часто приходилось включаться в уже существующий проект или видеть как новая команда на моих проектах подхватывает проект с историей. Часто новый разработчик приходящий на проект и приступающий к выполнению задачи первым делом начинает плеваться на существующий дизайн. Ему кажется, что всё сделано не правильно, не очевидно и слишком переусложнено. И как результат, при выполнении задачи, начинают появляться дыры в уже разработанном дизайне и существующая архитектура начинает обрастать костылями. В конце концов, проект или его подсистему требуется переписать почти полностью. Чем старше проект, тем таких случаев может быть больше.

              Также бывает и другая крайность, для реализации нового функционала или переделки существующего, один и разработчиков говорит: «Я знаю как сделать лучше!» после чего, вместо того чтобы дать идее «отлежаться» и оценить все плюсы и минусы, сразу начинает её делать. Где-то через месяц разработки может возникнуть ситуация, что чего-то он не предусмотрел, и приходится отказываться от разработки и выкидывать код или срочно искать варианты решения проблемы. Почти каждому разработчику в этом случае хочется сохранить лицо: «Как же так? Я же профессионал!» — думает он, «Если я признаю свою ошибку то все подумают, что я не настолько крут как всем говорю». И в этом случае Идея которая недостаточно проработана входит в проект и становится проблемой уже всей команды. Что также удорожает проект. А так как это становится заметно не сразу и внимания на причинно-следственные связи почти никто не обращает, то ситуация может повторяться снова и снова.
              Это похоже на Ваш проект?
            • Экспресс-курс «Проектное планирование»

              Везде ли применимо проектное планирование


              Любую деятельность компании или отдельного человека можно разделить на два состояния:

              1. Я делаю (сделаю) что-то сейчас;
              2. Я буду это делать в будущем.

              Первое состояние очень популярно в торгово-закупочной деятельности:

              • купить прямо сейчас;
              • заказать прямо сейчас;
              • позвонить прямо сейчас.

              На вас сваливается десяток задач которые надо сделать прямо сейчас. Как правило, это задачи на «на пять минут», хотя иногда подготовка к выполнению самой задачи может занять и больше пары часов. Если такое происходит, тогда весь поток задач, которые надо сделать «прямо сейчас», останавливается, пока короткая задача не будет завершена, Однако, каким-то мифическим образом все такие задачи «рассасываются» к концу недели.
              Читать дальше →
              • +14
              • 10,3k
              • 5