• Реализация итераторов в C# (часть 2)

    • Translation
    Реализация итераторов в C# (часть 1).

    Теперь, когда вы имеете в своём багаже общее представление о том, что стоит за итераторами, вы уже можете ответить на некоторые вопросы их использования. Вот сценарий, основанный на реальных событиях:
    Читать дальше →
    • +12
    • 10.2k
    • 3
  • Реализация итераторов в C# (часть 1)

    • Translation
    От переводчика:
    Не так давно мой менее опытный коллега спросил меня о том, для чего используется yield return в C#. Я не очень часто пишу свои итераторы, поэтому, отвечая ему, я сомневался в своих словах. Справившись в MSDN, я укрепился в сказанном, но у меня возник вопрос: “А во что же всё таки компилируется эта инструкция?” К тому моменту, я уже был знаком с переводимой статьёй, однако всё, что в ней сказано, давно “выветрилось”. Статья старая, но мне думается, что она может быть полезна для определённой группы разработчиков, привыкшей читать русскоязычные статьи и документы.

    Ссылка на продолжение: реализация итераторов в C# (часть 2)

    Читать дальше →
  • Полное сокрытие полей свойствами в C#

      Сперва я подумал, что стоит начать статью с описания основного назначения свойств в языке C#, но потом понял, что с этим можно на самом деле “развернуться” на целую статью. Поэтому, чтобы не затягивать со вступительной частью, я начну сразу с конкретной задачи.

      Постановка задачи


      Как известно, в подавляющем большинстве случаев свойства применяются, чтобы скрыть private или protected поле класса. То есть свойства в данном случае помогают реализовать инкапсуляцию данных и методов работы с ними.
      Рассмотрим простой пример
    • Почему программисты срывают сроки

      Вместо введения


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

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