- (SVN)Разрешение конфликтов папок SVN - надо было удалить скрытую папку .svn там где был конфликт, потом туда же CheckOut, а не грохать все.
- (SVN)В коммитах не забывать про *.csproj - они хранят настройки проекта, это обязательно к расшарке
- (SVN)Переимнование папки в каталоге не приводит автоматически к перименованию папки SVN, требуется именно выполнить комманду SVN->rename и потом коммитить либо пользовать VisualSVN
- (SVN)Перед коммитом или переименованием папки надо обязательно делать апдейт
- (NET)Обязательно изучить пространство имен System.Collections.Generic, понимать вообще генерики в частности нотацию IDictionary
- (C#) Не забывать потенциальный конфликт имен классов и пространств имен, например как с Console, не допускать.
- (С#,NET) Надо освоиться с Dictionary - много времени ушло на простейший foreach
- (Бардак) Правка замены регулярных выражений, надо убрать краевые скобки, после дебага и иего завала вдруг приходит вопрос такой, а что тут неправильно? value = value.Replace(@"^""([\S\s]*)""$","");, теперь билдится, но не работает, естественно если почемуто Regex.Replace заменяется на string.Replace - нечему валиться, ну и понятно, что когда нужно убирать кавычки, а код затирает все - это обречено на провал
- (regex) Неправильная конструкция [--] - непонимание конструкции
- (Бардак) Для регексов .net использовалась неподходящая туловина для дебага
- (Бардак) При столкновении с проблемой в регексе не было желание системно подумать в чем проблема и переписать регекс с ноля, начались напластования "вариантов" кода.
- (Бардак) Повторяется нежелание понять суть и стопорение на синтаксисе или не знании конкретного метода:
- при формировании расширения применения свойств: непонимание того что есть псевдокод, использование первого попавшегося и абсолютно неподходящего метода выпавшего в интеллисенсе, отсуствие как и с транзакциями заготовки оболочки общей логики метода
- так и не дописана была сигнатура №2 - отложена как "сама собой и просто" и недописанная
- задача про документирование и тестирование DictionaryExtensions - после 20 минут и задачи "разобраться что к сему в коде и убрать лишние методы" вопрос "почему столько оберток одного и того-же", хотя было сказано почему "не было параметров по умолчанию" и "одного и того же" оказалось так и покрыто мраком, то есть понимания работы класса как не было так и нет.
Резюме
- При цейтноте низкая устойчивость к стрессу - 2 реакции - ступор без кодинга "попытка думать" при этом код не пишется вообще никакой это когда задача с ноля, 2-я - буздумные правки кода, изменения тестов, использование чего попало из подсветки и автоподстановки в полуработающем коде.
- Отсутствие системного видения задачи, увлеченность собственно кодированием, не зависимо от сложности задачи, снижение общей дисциплины - теряются требования, неправильный порядок действий, отсутствие самоконтроля тестами.
- Очень низкий уровень алгоритмического видения, неумение пользоваться на бумажке типовыми вещами типа блок схем, деревьев решений или зависимости требований, как следствие аномальный порядок выполнения, сцепление условий. Что еще множится и трояется в сочетании с 1 и 2 пунктами.
- Позитив: больше глядится в подсказки, чуть легче читается код, более быстрое формиование типовых конструкций, более частый и грамотный цикл коммит-апдейт.
Рекомендации
Общая:
Высока вероятность проф. непригодности для выполнения задач системного и невизуального прикладного программирования. Отсутствие опыта абстрактного анализа и программирования без моментального визуального эффекта. На данный момент НЕ компенсируется уже знанием синтаксиса языка и общими классами, конструкциями .NET. Ибо проблема в самом умственном подходе и общих навыках, на данный момент профиль конечно больше про веб-мастеринг и визуализацию, где внешний эффект важнее средств достижения и примитивен по алгоритмам (как только это усложняется появляется код например а-ля обхода инлекса файлов с очумелой логикой, а это javascript+DOM, то есть все знакомо).
Соответственно 1-я рекомендация выделить ограниченный срок как постановщику так и исполнителю на принятие решения о продолжении работ исполнителя над кодом. И выявить нужно 2 вещи - а) способность все же мыслить программными алгоритмами и редуцировать их как по порядку, так и необходимости оперций, способность декомпозировать алгоритм на простые элементы и писать псевдокод, б) дисциплинированность при выполнении задач (2-е чуть получше).
Исполнителю:
- Обязательно перечитать этот блог, замечания в SVN
- Просмотреть весь итоговый написанный им совместно с старшим программистом код, вспомнить как же формировались решения.
- Изучить по документации все синтаксические конструкции и структуры использованных в коде классов
- Не постесняться и не полениться записать вопросы и "не могу вспомнить почему..." возникшие при чтении замечаний и кода - это точно те вещи в которые потом снова будет "вляп"
- Найти время по верхам пробежаться по основной библиотеке классов .NET, по основным пространствам имен, чтобы иметь представление о том, какие собственно направления охвачены уже базовыми классами
- Придумать себе ритуал или четкую инструкцию на случай вподания в ступор или хаотичное кодирование. Главное научиться ловить себя на этом и четко вставать на паузу, думать что делать.
- Как замечать эти состояния:
- при наличии четкой задачи и требований в течение 5 минут не написано ни одной буквы
- документация читается и из нее НИЧЕГО не оседает в голову, поиск ведется по случайно выбранным из контекста словам, а не по полному описанию задачи
- при неработающих тестах идет уже третья правка кода в одном месте БЕЗ анализа причин сбоя и без динамики в выполнении тестов
- заминка с тем что "не знаю какой тут надо класс использовать" а при этом полное отсутствие канвы где же его думается поиспользовать
- Что нужно предпринять (рекомендации расписаны именно исходя из дефекта в алгоритмике и замыкательстве на коде)
- Если ступор - пробежать глазами требования и понять - может в них все же есть простые требования которые можно уже выполнить и забыть, также требования могут содержать подсказки
- Если заминка вызвана незнанием класса заставить себя написать псевдокод с псевдовызовами, чтобы потом уже подставить правильные имена, но чтобы канва получилась
- Если нет общей канвы, отвлечься от кода, переменных и попробовать на бумаге разрисовать алгоритм работы процедуры на более высоком уровне, а потом писать код
- Если в голове хаос и ступор знать, что старший программист не поможет, и понять что ПСЕВДОКОД который дает выход на РЕАЛЬНЫЕ ВОПРОСЫ к старшему В ЛЮБОМ СЛУЧАЕ МОЖНО ЛЕГКО НАПИСАТЬ ПРОСТО В ПРАВИЛЬНОМ ПОРЯДКЕ СОБИРАЯ ТРЕБОВАНИЯ В АЛГОРИТМ.
- Часто ступор над уже каким-то но не рабочим кодом ознгачает, что лучше код полностью стереть чтобы не мешал и писать с ноля но не в лоб, а через блок схему и псевдокод.
- Что точно делать нельзя:
- Задавать вопросов отражающих полное непонимание задачи или халявное к ней отношение - конкретный вопрос бывает только про конкретный неизвестный класс или конструкцию кода или про работу неких внешних задействованных систем, все остальное - это признак лени, ступора и нежелания отвлечься от самого кодирования и подумать над смыслом задачи самому, плюс такие вопросы тупо отвлекают и злят.
- Менять тесты (кроме случаев явных багов в тестах)
- Нарушать общий порядок работы - файлы, набор классов - комит - сигнатуры вызовов, интерфейс - коммит, тесты - коммит, далее цикл - (чота изменил - тесты по другому - коммит) иначе пропускается значимый шаг и в итоге задание невыполнено.
- позволять себе что то использовать и не понимать что это, использовал Console.WriteLine("") - будь добр посмотреть все методы-свойства Console, поиспользовал IDictionary<string,string> будь добр и IDictionary изучить и что такое генерики "<>" и т.д.
