Привет!

Есть пара вопросов по предпочтениям к организации своего труда:
1. Как вы относитесь к многозадачности? Есть люди, которые не могут делать больше одной задачи одновременно. Есть те, кто могут.
2. Как вы пишите код? Я предпочитаю написать кусочек (законченный), протестить его и двигаться дальше. Мне так удобнее. Знаю, что есть люди, которые могут неделю писать код, а потом его начинают отлаживать. Эти люди говорят, что им тяжело переключаться с задачи разработки (дизайна) на отладку.

Здравствуйте, Lonely Dog, Вы писали:

LD>2. Как вы пишите код? Я предпочитаю написать кусочек (законченный), протестить его и двигаться дальше. Мне так удобнее. Знаю, что есть люди, которые могут неделю писать код, а потом его начинают отлаживать.

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

Здравствуйте, Lonely Dog, Вы писали:

LD>Есть пара вопросов по предпочтениям к организации своего труда:
LD>1. Как вы относитесь к многозадачности? Есть люди, которые не могут делать больше одной задачи одновременно. Есть те, кто могут.

Мне сложно работать в многозадачном режиме, очень много времени уходит на "переключение контекста".

LD>2. Как вы пишите код? Я предпочитаю написать кусочек (законченный), протестить его и двигаться дальше. Мне так удобнее. Знаю, что есть люди, которые могут неделю писать код, а потом его начинают отлаживать. Эти люди говорят, что им тяжело переключаться с задачи разработки (дизайна) на отладку.

Обычно тоже "кусочничаю", хотя, в зависимости от проекта и от стадии реализации, куски могут быть довольно крупными.

Здравствуйте, Lonely Dog, Вы писали:

LD>1. Как вы относитесь к многозадачности? Есть люди, которые не могут делать больше одной задачи одновременно. Есть те, кто могут.
Люблю многозадачность — мозг работает с нескльких направлениям и зачастую выделяя общие фичи можно сократить время разработки. Ну и в целом думать на несколько направлений гораздо интереснее.

LD>2. Как вы пишите код? Я предпочитаю написать кусочек (законченный), протестить его и двигаться дальше. Мне так удобнее. Знаю, что есть люди, которые могут неделю писать код, а потом его начинают отлаживать. Эти люди говорят, что им тяжело переключаться с задачи разработки (дизайна) на отладку.
Дроблю на маленькие части, идем от малого к большему — или тестами, или сразу кодом.
Или наброски какие то делаю — будет работать или нет, можно сделать или нет. Потом выкидываю и пишу нормально.

Здравствуйте, Lonely Dog, Вы писали:

LD>1. Как вы относитесь к многозадачности? Есть люди, которые не могут делать больше одной задачи одновременно. Есть те, кто могут.
Если нужно переключаться, то приходится. Но это понижает КПД.

LD>2. Как вы пишите код? Я предпочитаю написать кусочек (законченный), протестить его и двигаться дальше. Мне так удобнее. Знаю, что есть люди, которые могут неделю писать код, а потом его начинают отлаживать. Эти люди говорят, что им тяжело переключаться с задачи разработки (дизайна) на отладку.
Предпочитаю отлаживать сразу, если это не требует ощутимых затрат на имитацию незаконченных модулей. А поскольку часто требует, то порой и неделю, да хоть месяц, могу не запускать то, что пишу. Конечно, такой подход предполагает использование широкого спектра средств отладки (аппаратные точки останова на изменения переменных, контроль выхода за пределы блока памяти). Иначе тяжело распутать всю цепочку от причины до проявления бага.

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

псевдокод выглядит примерно так.

void optimize()
{

   Estimation bestEstimation;
   initialize(bestEstimation);
   

   while( !exitCriteriaReached())
   {
      Estimation newEstimation;
      suggestParams(newEstimation);
 
      if( newEstimation > bestEstimation)
      {
         bestEstimation = newEstimation;
      }
   }
}

Здравствуйте, Lonely Dog, Вы писали:

LD>1. Как вы относитесь к многозадачности? Есть люди, которые не могут делать больше одной задачи одновременно. Есть те, кто могут.

Одну задачу делать скучно. Это должна быть действительно достойная интересная трудная задача. Обычные рутинные задачи обычно совмещаю с просмотром видео, чатом по ICQ, иногда чтением. Мониторы широкие, все помещается.

LD>2. Как вы пишите код? Я предпочитаю написать кусочек (законченный), протестить его и двигаться дальше. Мне так удобнее. Знаю, что есть люди, которые могут неделю писать код, а потом его начинают отлаживать. Эти люди говорят, что им тяжело переключаться с задачи разработки (дизайна) на отладку.

От задачи зависит, иногда законченный кусочек надо писать неделю. Иногда пишу через пилотный вариант. Но в целом кусочки (и тесты) больше одного метода.

Здравствуйте, Lonely Dog, Вы писали:

LD>2. Как вы пишите код? Я предпочитаю написать кусочек (законченный), протестить его и двигаться дальше. Мне так удобнее. Знаю, что есть люди, которые могут неделю писать код, а потом его начинают отлаживать. Эти люди говорят, что им тяжело переключаться с задачи разработки (дизайна) на отладку.

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

Здравствуйте, VladD2, Вы писали:

VD>Все предпочитают простые, мелкие задачи. Но бывают задачи которые бессмысленны в упрощенном варианте. Вот тогда и приходится неделями писать код.
И вам это не доставляет проблем или неудобств?

Здравствуйте, Lonely Dog, Вы писали:

VD>>Все предпочитают простые, мелкие задачи. Но бывают задачи которые бессмысленны в упрощенном варианте. Вот тогда и приходится неделями писать код.
LD>И вам это не доставляет проблем или неудобств?

Решение сложных задач? Конечно доставляет. Но неудобства компенсируются удовольствием от решения сложной задачи.

Здравствуйте, Lonely Dog, Вы писали:

LD>И вам это не доставляет проблем или неудобств?

А шо делать???

Здравствуйте, Lonely Dog, Вы писали:

LD>Есть пара вопросов по предпочтениям к организации своего труда:
LD>1. Как вы относитесь к многозадачности?
В принципе легко — опыт работы в хроническом дедлайногенераторе с вытесняющими приоритетами. Но ничего хорошего в этом нет: переключение контекста — дорогая операция.

LD>2. Как вы пишите код?
Максимально быстро пишется прототип + теоретические сценарии использования. Изредка прямо во время обсуждения, гораздо чаще — карандашик + бумажка. Затем пишется рабочий код и проверяются все требования, потенциально влияющие на дизайн, костыли выносятся в библиотеку компонент и т.п. И напоследок — тщательное вылизывание кода, StyleCop, FxCop, если есть свободное время — xml-комментарии. Всё.

Главное, что я для себя выяснил — никогда не откладывать последний этап "на потом". Так и останетесь с горой неподдерживаемого кода.

Здравствуйте, Lonely Dog, Вы писали:

LD>Привет!

LD>Есть пара вопросов по предпочтениям к организации своего труда:
LD>1. Как вы относитесь к многозадачности? Есть люди, которые не могут делать больше одной задачи одновременно. Есть те, кто могут.

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

LD>2. Как вы пишите код? Я предпочитаю написать кусочек (законченный), протестить его и двигаться дальше. Мне так удобнее.

Мне тоже. Но далеко не всегда так возможно. Серьезный фрагмент может потребовать большого времени на написание, лишь только когда он будет готов, можно его отлаживать.


>Знаю, что есть люди, которые могут неделю писать код, а потом его начинают отлаживать.

Вполне возможно, хоть и не люблю я этого.

>Эти люди говорят, что им тяжело переключаться с задачи разработки (дизайна) на отладку.

Ну уж это нет. Пока алгоритмы и структуры данных я не продумал до мельчайших деталей, я и строчки не напишу. Себе дороже выйдет.

Здравствуйте, Lonely Dog, Вы писали:

LD>2. Как вы пишите код? Я предпочитаю написать кусочек (законченный), протестить его и двигаться дальше. Мне так удобнее. Знаю, что есть люди, которые могут неделю писать код, а потом его начинают отлаживать. Эти люди говорят, что им тяжело переключаться с задачи разработки (дизайна) на отладку.


Все зависит от области решаемых задач. У меня, например, на выходе — процентов 5 хорошего, годного программного кода. Все остальное — эксперименты и тесты, которые в итоге без мелейшего сожаления идут в мусорку. Это как листочки бумаги, которые накапливаются на столе, а потом сгребаются и выкидываются. И я честно скажу, совершенно не понимаю, как можно целую неделю дубасить текст программы, и только потом его начинать отлаживать. Уверен, что получается криво и глючно. Но с точки зрения быдлокодинга я наверное рекордсмен по неэффективности. Мой средний норматив — 5-10 строк в день. Иногда получается -1000, это означает, что найдено более изящное решение в замен старому. Как оценить стоимость строки кода, если я за сегодня написал минус тысячу строк? Мнимое значение за действительные деньги.

Здравствуйте, McSeem2, Вы писали:


MS> Как оценить стоимость строки кода, если я за сегодня написал минус тысячу строк? Мнимое значение за действительные деньги.

По модулю комплексного числа

Здравствуйте, McSeem2, Вы писали:

MS>Все зависит от области решаемых задач. У меня, например, на выходе — процентов 5 хорошего, годного программного кода. Все остальное — эксперименты и тесты, которые в итоге без мелейшего сожаления идут в мусорку. Это как листочки бумаги, которые накапливаются на столе, а потом сгребаются и выкидываются. И я честно скажу, совершенно не понимаю, как можно целую неделю дубасить текст программы, и только потом его начинать отлаживать. Уверен, что получается криво и глючно. Но с точки зрения быдлокодинга я наверное рекордсмен по неэффективности. Мой средний норматив — 5-10 строк в день. Иногда получается -1000, это означает, что найдено более изящное решение в замен старому. Как оценить стоимость строки кода, если я за сегодня написал минус тысячу строк? Мнимое значение за действительные деньги.

У меня та же проблема. Но с увеличением опыта количество выброшенного кода уменьшается.

Здравствуйте, jenyavb, Вы писали:

J>У меня та же проблема. Но с увеличением опыта количество выброшенного кода уменьшается.

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

Вот вам практический пример.
Есть регулярная задачка "обойти структуру папок и сгенерить аналогичную структру, но с другими данными".
При этом
а) некоторые папки надо пропустить.
б) имена папок/файлов в папке назначения могут различаться и об этом надо знать вызывающему коду.

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

Страшно? Так вот этот код с марта
1) существовал как один метод
2) был вынесен в библиотеку компонентов
3) параметры были объединены в структуру
4) был вынесен в отдельный класс, унаследованный от Component (раздулся втрое и стал вообще неподдерживаемым)
5) приведён к текущему виду и отмечен как // DONTTOUCH. Кстати, такие комментарии в Task List window — великое дело.

Придумаете как это написать красивее?

    public delegate void DirectoryCallback(
      string source, ref string destination,
      ref bool newDestinationContainer, out bool skipSubitems);

    public delegate void FileCallback(
      string source, ref string destination,
      bool newDestinationContainer);

    public static void VisitAll(
      string source, ref string destination,
      DirectoryCallback directoryCallback, FileCallback fileCallback)
    {
      if (source.EndsWith("\\") || source.EndsWith("/"))
      {
        VisitAllInternal(
          source, ref destination,
          directoryCallback, fileCallback,
          !Directory.Exists(Path.GetDirectoryName(destination)));
      }
      else
      {
        fileCallback(
          source,
          ref destination,
          !Directory.Exists(Path.GetDirectoryName(destination.TrimEnd('\\','/'))));
      }
    }

    private static void VisitAllInternal(
      string source, ref string destination,
      DirectoryCallback directoryCallback, FileCallback fileCallback, bool newDestinationContainer)
    {
      bool skip = false;
      if (directoryCallback != null)
      {
        directoryCallback(source, ref destination, ref newDestinationContainer, out skip);
      }

      if (!skip)
      {
        if (fileCallback != null)
        {
          foreach (string fileName in Directory.GetFiles(source))
          {
            string destFile = destination + fileName.Substring(source.Length);
            fileCallback(fileName, ref destFile, newDestinationContainer);
          }
        }

        foreach (string dir in Directory.GetDirectories(source))
        {
          string sourceDir = dir + "\\";
          string destDir = destination + sourceDir.Substring(source.Length);
          VisitAllInternal(sourceDir, ref destDir, directoryCallback, fileCallback, newDestinationContainer);
        }
      }
    }

Пример использования (хотя для такой простой задачи это оверкилл):

    public static void Copy(string source, string destination)
    {
      VisitAll(source, ref destination,
        delegate(string dir, ref string destDir, ref bool newDestinationContainer, out bool skip)
        {
          if (newDestinationContainer || !Directory.Exists(destDir))
          {
            Directory.CreateDirectory(destDir);
            newDestinationContainer = true;
          }
          skip = false;
        },
        delegate(string file, ref string destFile, bool newDestinationContainer)
        {
          File.Copy(file, destFile, !newDestinationContainer);
        });
    }

Здравствуйте, Lonely Dog, Вы писали:

Когда занимаюсь одной и той же задачей больше N дней (где N зависит от интересности задачи, от 1 до 5-7), то мотивация сильно падает, и, как следствие, эффективность.
Поэтому стараюсь делать несколько дел сразу, по очереди на них переключаясь.

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


А если все хорошо и спешки особой нет, то:

1. описываю задачу в рамках пользовательских требований
2. прикидываю архитектуру в общих чертах
3. пишу приемочные тесты по требованиям
4. потихоньку пишу код, проходящий тесты
5. если появились еще требования (например, для кода нужна еще подсистема какая-то), то сначала пишу заглушки и mock`и, откладывая реализацию
6. иногда декомпозировать не удается, тогда злюсь Потому что не умею удерживать в голове "макаронный" код с высокой связанностью.

Здравствуйте, Sinix, Вы писали:

J>>У меня та же проблема. Но с увеличением опыта количество выброшенного кода уменьшается.
S>Не везде и не всегда. Для библиотечного кода — точно. Приходится писать гору прототипов, следить чтобы кодом было удобно пользоваться и чтобы он не был сложен для использования.

Эло не противоречим моему утверждению.

S>Вот вам практический пример.
S>Придумаете как это написать красивее?

Избавился бы от делегатов в пользу лямбд и от ref-параметров в пользу возврата звачений. Ну и вообще может быть стоило бы придумать универсальный алгоритм для обхода деревьев со значением-аккомулятором. Хотя я не очень вникал.

Здравствуйте, jenyavb, Вы писали:

J>У меня та же проблема. Но с увеличением опыта количество выброшенного кода уменьшается.

А у меня увеличивается, поскольку все больше ухожу в экспериментальные области. Ну, конечно же никакой код я не удаляю, он просто скапливается в неком отстойнике, но продакшен идут только тщательно отполированные вещи. Года полтора назад ездил на интервью в Autodesk и беседовал с ихним CTO. Так он тоже очень любит программировать и отрабатывать всяческие идеи. Но конечно же, ни одной строчки из его кода не идет в продукты — если что-то и получается, то все тщательно передизайнивается и переписывается другими людьми. В общем-то, я стремлюсь к тому же, то есть, фактически к нулевой производительности.