воскресенье, 30 января 2011 г.

Касяки 2011-01-31

  1. (SVN)Разрешение конфликтов папок SVN - надо было удалить скрытую папку .svn там где был конфликт, потом туда же CheckOut, а не грохать все.
  2. (SVN)В коммитах не забывать про *.csproj - они хранят настройки проекта, это обязательно к расшарке
  3. (SVN)Переимнование папки в каталоге не приводит автоматически к перименованию папки SVN, требуется именно выполнить комманду SVN->rename и потом коммитить либо пользовать VisualSVN
  4. (SVN)Перед коммитом или переименованием папки надо обязательно  делать апдейт
  5. (NET)Обязательно изучить пространство имен System.Collections.Generic, понимать вообще генерики в частности нотацию IDictionary
  6. (C#) Не забывать потенциальный конфликт имен классов и пространств имен, например как с Console, не допускать. 
  7. (С#,NET) Надо освоиться с Dictionary - много времени ушло на простейший foreach 
  8. (Бардак) Правка замены регулярных выражений, надо убрать краевые скобки, после дебага и иего завала вдруг приходит вопрос такой, а что тут неправильно? value = value.Replace(@"^""([\S\s]*)""$","");, теперь билдится, но не работает, естественно если почемуто Regex.Replace заменяется на string.Replace - нечему валиться, ну и понятно, что когда нужно убирать кавычки, а код затирает все - это обречено на провал
  9. (regex) Неправильная конструкция [--]  - непонимание конструкции
  10. (Бардак) Для регексов .net использовалась неподходящая туловина для дебага
  11. (Бардак) При столкновении с проблемой в регексе не было желание системно подумать в чем проблема и переписать регекс с ноля, начались напластования "вариантов" кода.
  12. (Бардак) Повторяется нежелание понять суть и стопорение на синтаксисе или не знании конкретного метода:
    1. при формировании расширения применения свойств: непонимание того что есть псевдокод, использование первого попавшегося и абсолютно неподходящего метода выпавшего в интеллисенсе, отсуствие как и с транзакциями заготовки оболочки общей логики метода
    2. так и не дописана была сигнатура №2 - отложена как "сама собой и просто" и недописанная
    3. задача про документирование и тестирование DictionaryExtensions - после 20 минут и задачи "разобраться что к сему в коде и убрать лишние методы" вопрос "почему столько оберток одного и того-же", хотя было сказано почему "не было параметров по умолчанию" и "одного и того же" оказалось так и покрыто мраком, то есть понимания работы класса как не было так и нет.
Резюме
  1. При цейтноте низкая устойчивость к стрессу - 2 реакции - ступор без кодинга "попытка думать" при этом код не пишется вообще никакой это когда задача с ноля, 2-я - буздумные правки кода, изменения тестов, использование чего попало из подсветки и автоподстановки в полуработающем коде.
  2. Отсутствие системного видения задачи, увлеченность собственно кодированием, не зависимо от сложности задачи, снижение общей дисциплины - теряются требования, неправильный порядок действий, отсутствие самоконтроля тестами.
  3. Очень низкий уровень алгоритмического видения, неумение пользоваться на бумажке типовыми вещами типа блок схем, деревьев решений или зависимости требований, как следствие аномальный порядок выполнения, сцепление условий. Что еще множится и трояется в сочетании с 1 и 2 пунктами.
  4. Позитив: больше глядится в подсказки, чуть легче читается код, более быстрое формиование типовых конструкций, более частый и грамотный цикл коммит-апдейт.
Рекомендации
Общая:
Высока вероятность проф. непригодности для выполнения задач системного и невизуального прикладного программирования. Отсутствие опыта абстрактного анализа и программирования без моментального визуального эффекта. На данный момент НЕ компенсируется уже знанием синтаксиса языка и общими классами, конструкциями .NET. Ибо проблема в самом умственном подходе и общих навыках, на данный момент профиль конечно больше про веб-мастеринг и визуализацию, где внешний эффект важнее средств достижения и примитивен по алгоритмам (как только это усложняется появляется код например а-ля обхода инлекса файлов с очумелой логикой, а это javascript+DOM, то есть все знакомо).
Соответственно 1-я рекомендация выделить ограниченный срок как постановщику так и исполнителю на принятие решения о продолжении работ исполнителя над кодом. И выявить нужно 2 вещи - а) способность все же мыслить программными алгоритмами и редуцировать их как по порядку, так и необходимости оперций, способность декомпозировать алгоритм на простые элементы и писать псевдокод, б) дисциплинированность при выполнении задач (2-е чуть получше).

Исполнителю:
  1. Обязательно перечитать этот блог, замечания в SVN
  2. Просмотреть весь итоговый написанный им совместно с старшим программистом код, вспомнить как же формировались решения.
  3. Изучить по документации все синтаксические конструкции и структуры использованных в коде классов
  4. Не постесняться и не полениться записать вопросы и "не могу вспомнить почему..." возникшие при чтении замечаний и кода - это точно те вещи в которые потом снова будет "вляп"
  5. Найти время по верхам пробежаться по основной библиотеке классов .NET, по основным пространствам имен, чтобы иметь представление о том, какие собственно направления охвачены уже базовыми классами
  6. Придумать себе ритуал или четкую инструкцию на случай вподания в ступор или хаотичное кодирование. Главное научиться ловить себя на этом и четко вставать на паузу, думать что делать. 
    1. Как замечать эти состояния:
      1. при наличии четкой задачи и требований в течение 5 минут не написано ни одной буквы
      2. документация читается и из нее НИЧЕГО не оседает в голову, поиск ведется по случайно выбранным из контекста словам, а не по полному описанию задачи
      3. при неработающих тестах идет уже третья правка кода в одном месте БЕЗ анализа причин сбоя и без динамики в выполнении тестов
      4. заминка с тем что "не знаю какой тут надо класс использовать" а при этом полное отсутствие канвы где же его думается поиспользовать
    2. Что нужно предпринять (рекомендации расписаны именно исходя из дефекта в алгоритмике и замыкательстве на коде)
      1. Если ступор - пробежать глазами требования и понять - может в них все же есть простые требования которые можно уже выполнить и забыть, также требования могут содержать подсказки
      2. Если заминка вызвана незнанием класса заставить себя написать псевдокод с псевдовызовами, чтобы потом уже подставить правильные имена, но чтобы канва получилась
      3. Если нет общей канвы, отвлечься от кода, переменных и попробовать на бумаге разрисовать алгоритм работы процедуры на более высоком уровне, а потом писать код
      4. Если в голове хаос и ступор знать, что старший программист не поможет, и понять что ПСЕВДОКОД который дает выход на РЕАЛЬНЫЕ ВОПРОСЫ к старшему В ЛЮБОМ СЛУЧАЕ МОЖНО ЛЕГКО НАПИСАТЬ ПРОСТО В ПРАВИЛЬНОМ ПОРЯДКЕ СОБИРАЯ ТРЕБОВАНИЯ В АЛГОРИТМ.
      5. Часто ступор над уже каким-то но не рабочим кодом ознгачает, что лучше код полностью стереть чтобы не мешал и писать с ноля но не в лоб, а через блок схему и псевдокод.
  7. Что точно делать нельзя:
    1. Задавать вопросов отражающих полное непонимание задачи или халявное к ней отношение - конкретный вопрос бывает только про конкретный неизвестный класс или конструкцию кода или про работу неких внешних задействованных систем, все остальное - это признак лени, ступора и нежелания отвлечься от самого кодирования и подумать над смыслом задачи самому, плюс такие вопросы тупо отвлекают и злят.
    2. Менять тесты (кроме случаев явных багов в тестах)
    3. Нарушать общий порядок работы - файлы, набор классов - комит - сигнатуры вызовов, интерфейс - коммит, тесты - коммит, далее цикл - (чота изменил - тесты по другому - коммит) иначе пропускается значимый шаг и в итоге задание невыполнено.
    4. позволять себе что то использовать и не понимать что это, использовал Console.WriteLine("") - будь добр посмотреть все методы-свойства Console, поиспользовал IDictionary<string,string> будь добр и IDictionary изучить и что такое генерики "<>" и т.д.

Комментариев нет: