gifts2017

12 навыков, которые помогут найти причину ошибки, если непонятно, из-за чего она происходит

Опубликовал Компания Нэти (Neti) в раздел Программирование - Практика программирования

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

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

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

Давайте попытаемся разобраться и составим примерный алгоритм действий поиска решения. А так же выясним, какие умения помогают эффективно решать такие проблемы.

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

 

Термин

Сначала хочу пояснить одно понятие употребляемое мной:

Модели работы механизмов - здесь это представление как может работать конкретный механизм внутри платформы с технической стороны. Например, особенности процессора вывода СКД (система компоновки данных), ошибки времени выполнение запросов, отображение управляемых форм.

Для эффективного решения трудноанализируемых проблем нужно:

  • Обширная база моделей работы алгоритмов в голове. Знание моделей позволяет быстро строить гипотезы о работе исследуемого механизма. Что помогает вообще понять где и из-за чего может быть ошибка.

  • Умение видеть проблему максимально широко в любой момент времени. К примеру, не зацикливаться на конкретном решении возникших подпроблем, возможно при другом варианте этих новых проблем и нет.

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

  • Мотивация на результат. Умение добиваться цели.

  • Развитые аналитические способности, в т. ч. осознанное или интуитивное применение основных инструментов анализа.

 
Тренировка

  1. Постоянное изучение и формирование моделей на основе данных встречаемых задач.

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

    • Рекомендуется записывать в некую базу знаний и/или рассказывать кому-то о проблеме и ее решении. При подобном описании становятся лучше видны пробелы в знаниях, а так же опыт прочнее закрепляется в голове. Дополнительно, если вы своим опытом кому-то помогли, то этот опыт лучше «индексируется» в голове по ключевым словам проблемы.

  2. Изучение любой информации о внутренней работе типовой функциональности платформы. Изучение особенностей системы.

    • Изучайте любую информацию, которую можно найти о работе внутренних механизмов платформы. В том числе списки ошибок платформы (файлы ErrPlatform_*.htm) и темы форумов про них же.

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

Для решения любых задач (особенно на этапе выдвижения предположений) помогает опыт в похожих областях. Так что, изучая что-то, вы получается навыки не только исследуемой области, но и косвенно увеличиваете шансы быстро решить проблемы в области с совпадающей логикой. (Правда возможно и то, что вам какой-то опыт наоборот помешает. Но я надеюсь вы умеете рационально оценивать применимость знаний).

  1. Пополнение моделей работы дополнительным чтением выборочных статей. Можно тратить хотя бы полчаса времени в день для чтения статей не по теме рабочих задач.

  2. Развитие аналитических способностей. Например, это можно сделать с помощью логических и дедуктивных игр. Можно поставить такие игры к себе на телефон и решать 1-2 задачки за день. Так же можно решать задачки на анализ ситуации, подобные тем, что ходят по интернету в виде тестов от google для менеджеров продукта. Кроме того, можно начать изучать элементы и инструменты анализа проблем.

  3. Развитие самомотивации. Помогает самоанализ, что же привлекает тебя в твоей работе вообще и искусственное подчеркивание данных аспектов во время приступов лени. Видеть результаты своего труда, например, копить базу записей решенных задач. (Но не забываем, что иногда просто надо временно переключиться на другую задачу или просто дать 5 минут мозгу отдохнуть).

  4. Всегда пытайтесь оценить для себя сколько займет времени завершить задачу по текущему пути поиска решения. Понятно, что это оценка при большом количестве неизвестных будет чаще совсем неправильная и больше на ощущениях. Но если вы начнете хоть как-то оценивать, то вы научитесь как минимум трезво смотреть на текущий процесс и научитесь осознаннее чувствовать перспективность направления дальнейшего поиска.



Подготовка к процессу

  1. Перестать переживать. Есть конечно полезный стресс, но чаще переживания только мешают думать. Так что лучше отключиться от страхов и переживаний типа «А Вася бы это сделал за пять минут», «Я не успею вовремя и все провалю».

    Есть просто результат, эффективность, прибыль и полученный по итогам опыт. Что-то одно может перевешивать. Главное, чтобы вы и человек ответственный за затраты понимали риски и возможное соотношение этих показателей.

    (про переживания советую почитать на Хабре)

  2. Выгрузить все текущие дела из головы, хотя бы на бумагу. Дела имеют привычку ни с того ни с сего всплывать в голове и отвлекать вас. Поэтому запишите их куда-то, чтобы не забыть и мозг успокоиться. Вообще рекомендую посмотреть методику GTD (Getting Things Done).

  1. Дать проблеме имя. Сформировать для себя четкое понимание, что за проблему мы решаем. Как это не странно, но непонимание, что мы в итоге исправляем и для чего, наиболее частая проблема затягивания решения.

  2. Определить правильный мотив. Проверить мотивацию на решение. Если мотивация «отработать» до конца дня, то задача вряд ли решиться. Если нет никакой мотивации на решение, то можно создать себе мотивацию самостоятельно. Например, решить для себя, что по итогам вы опубликуете проблему и решение на каком-нибудь известном сайте или поспорить с кем-нибудь, что вы сможете побороть проблему за час.

  3. Определить конечную цель. Надо определить четкие критерии результата, при котором задача будет считаться решенной. А далее уже ориентируясь на цель прокладывать пути поиска решений проблемы.

  4. Таймбоксинг. Если примерное время и вообще возможность решения проблемы не ясны и это демотивирует вас, то можно воспользоваться методом таймбоксинга. Метод заключается в определении для себя периода времени, в котором вы будете решать проблему и будете решать ее с полной самоотдачей. То есть, «Максимально сосредоточенно пытаюсь решить ее 2 часа, а потом переключаюсь на другую задачу». Это, во-первых, помогает проще и быстрее начать решать проблему, так как уменьшает моральное давление (вы как бы только пробуете). Во-вторых, помогает активизироваться, типа «у меня только 2 часа».

Продолжение следует...

PS:  Друзья, голосуйте и оставляйте комментарии!

Автор статьи: Андрей Макаров, компания Neti
Оригинал статьи:
на сайте Аутсорсинг1С.рф 

См. также

Вознаграждение за ответ
Сумма: 0 $m
Добавили:
Makc *** (makc2k) (1.00 $m)
Подписаться Добавить вознаграждение
Комментарии
1. Владимир Литвиненко (VladimirL) 12.12.13 03:32
Полезная статья. Вроде бы интуитивно понятные вещи написаны, но, как было верно замечено, применяют их обычно не анализируя и не рассматривая как часть общей системы работы/обучения. Всегда полезно разложить всё по полочкам и посмотреть "сверху".

Уже не в первый раз встречаю совет ознакомиться с GTD. Надо будет выйти за пределы Вики и книжки почитать.
2. Франко Деллиани (Franco) 12.12.13 09:52
Благодарю!
Иногда самые оригинальные идеи решений находятся при смене деятельности - например, когда наступает время шагать домой или прерваться на обед. Думаю, этому как раз помогает 'Умение видеть проблему максимально широко в любой момент времени'. То есть смог посмотреть на свою работу с другой точки зрения.
Flashback1979SE; +1 Ответить 1
3. Kirill Kazakevich (kirmancino) 13.12.13 16:39
Интересная статья.
Вообще, моделирование и оценка модели помогают решать проблемы не только в программировании, но и в жизненных ситуациях. Чем больше ты знаешь, тем более комплексное твое вИдение.
Как говорится - за деревьями видишь лес.
andmakarov; +1 Ответить 1
4. Елена Пименова (Bukaska) 13.12.13 17:02
(3) kirmancino, Это как? Сто верст до небес... и все лесом-лесом...
5. Артем Гусаров (Flashback1979SE) 16.12.13 08:42
(2) Franco, запостой решение приходит во время езды между клиентами))))) или домой, но чаще по дороге к клиенту))))). Ведь частенько времени в обрез)
6. Makc *** (makc2k) 16.12.13 13:09
Замечательная статья! Концепция обучения новичка подразумевает лишь подачу основ. То есть говорят - учи, но странно, что вооще никто не хочет научить человека учиться, это считается должно прийти с опытом. Если бы детям в школе давали материал по способам запоминания, алгоритмике решений, и т. д. у нас бы интелект нации был бы на очень высоком уровне.
Niberu; angur; ikekoval; andmakarov; +4 Ответить
7. Сергей Маслов (LexSeIch) 17.12.13 04:51
Мир этому дому!
Статья интересная и полезная (и не только для программистов). Жду продолжения.
8. Dragon Ago (DragonAgo) 18.12.13 09:07
Хорошие идея по работе программиста. Раньше переживала, а сейчас беру себя в руки, выслушиваю всех и пишу, рисую на бумаге, затем анализирую, и лишь потом начинаю творить. Но лучше всего всегда иметь ТЗ, чтобы сто раз не приходилось изменять наработанное, у пользователей хотелки постоянно растут. А в большинстве случае они просят такое, что волосы дыбом. Фильм Профессионал нарисуйте мне 9 перпендикулярных линий прозрачным цветом =)))
9. DAnry (DAnry) 18.12.13 17:29
Спасибо за статью. Безусловно она имеет право на существование. Так сказать научная организация интелектуального труда програмиста. Плюс элементы психологического тренинга.
Но мне кажется не следует усложнять.
10. Иван (SinglCOOLer) 23.12.13 07:55
хорошо написано, показал начинающему разработчику, он нашел себя в статье
11. Алексей Роза (DoctorRoza) 23.12.13 08:59
Пока написано ни о чем, в стиля аля Ошо. Может в других статьях что то дельное будет.
12. Андрей Макаров (andmakarov) 23.12.13 21:23
Спасибо за комментарии!

В статье нет особо глубоких идей или техник. Все достаточно знакомо.
Но по моему опыту, больше всего бесполезно потраченного времени как раз и получаются из-за ошибок в простых казалось бы для понимания вещах.
Причем человек вроде как все понимает, но в нужный момент начинает делать все не так.
Поэтому проговаривание и анализ основных проблем как раз и помогает поставить в памяти очередную, но более видимую зарубку. И шанс увидеть ее и обнаружить не оптимальность своих текущих действий становиться больше.
13. OneS (OneS) 25.12.13 08:14
Статья ни о чем, самое главное в ней подпись с указанием фирмы.

Ступор начинающего одноэсника порождается не знанием предметной области, объектно-ориентированного программирования вообще и реализации в конкретной платформе в частности и неумением пользоваться отладчиком. Поэтому и рецепт один: много работать над своими знаниями и умениями.
Прикрепленные файлы:
KapasMordorov; AlenaR; Spacer; +3 Ответить 1
14. Андрей Макаров (andmakarov) 25.12.13 10:43
(13) OneS, спасибо за ваш комментарий.
Но проблема, которая рассматривается, как раз и написана про ту ситуацию, когда, цитирую: "по какой-то .. причине мы не можем пробежаться по коду отладчиком и понять весь алгоритм".
Это чаще всего как раз проблемы платформы.
15. OneS (OneS) 25.12.13 11:48
(14) andmakarov, а теперь процитируем всю фразу:
или по какой-то другой причине мы не можем пробежаться по коду отладчиком и понять весь алгоритм (или не хотим, так как слишком много кода и столько времени тратить просто не рентабельно).

Вот неумение в купе с незнанием и отбивает всё желание.

Проблемы платформы ищутся в доступном информационном поле: коллеги, интернет. У Вас как бы есть про изучение, но для начинающего реально важно научиться постановке правильного вопроса, что бы получить внятный ответ.






16. Владимир Насыров (Spacer) 25.12.13 12:25
(11) DoctorRoza, вот с этим согласен. Не нашел в статье того что ожидал увидеть прочитав название.
Автор заметил проблему, хорошо ее описал, и на этом фактически остановился приведя лишь общие рекомендации.
17. Андрей Макаров (andmakarov) 25.12.13 12:41
(15) OneS, да, про ситуации, когда не рентабельно пробегаться по всему коду с отладчиком, возможно я зря написал :) В этом случае правильнее всегда пробивать заказчика на, то чтобы разобраться до конца в коде.
(Это у меня просто была ситуация, когда проблему надо было решить сейчас и быстро, а проверка результата "чтобы все было хорошо" брал на себя заказчик).
Но вообще вы правы, что такая ситуация неправильная и от нее надо открещиваться и разбираться до конца.
Спасибо за указание на этот момент!

За умение задавать вопросы отдельное спасибо. Да, это я не описал.
18. Андрей Макаров (andmakarov) 25.12.13 12:43
(16) Spacer, это первая часть статьи.
Вторая часть будет непосредственно про процесс анализа и решения таких проблем, а так же про фиксацию результатов.
Надеюсь там необходимой информации будет больше :)
19. Александр Шкут (alex_shkut) 25.12.13 18:03
А мне статья понравилась. Это как-раз опыт человека, который видит и понимает весь комплекс решения задачи. Взгляд глобально на процесс. Способ мышления топ-менеджера. Прочитав статью до конца люди теряют смысл заголовка, а ведь без этой преамбулы основной смысл этой книги будет во много непонятен... Да, книги. Потому как это только вступление.
20. Владимир Кузнецов (mr.Kot) 30.12.13 10:34
Не однозначная статья, полезна будет не всем, наверное, многое от мировозрения читателя зависеть будет.
21. OneS (OneS) 02.01.14 10:11
Кстати, очень полезно не замыкаться только на 1С. ООП изучить на питон и C#, запросы по классическим учебникам по SQL. Вместо механического запоминания тут нужно писать вот так, придёт ясность и понимание физики процесса. Что, опять же, избавит от ошибок и стресса. :)
22. Татьяна Крестьянкина (oleg212) 03.01.14 00:19
23. Lubov Filippova (laf) 07.11.14 02:11
+Спасибо за статью. Подписываюсь на продолжение.
24. Ula1c (ula1c) 07.11.14 14:28
А мне очень понравилось - дать проблеме имя. Точно работает на успокоение, т.к. имя очерчивает границы проблемы в твоей жизни.
25. tisa tisas (tisas77) 07.11.14 14:39
26. Роберт В е р т и н с к и й (v3rter) 20.04.16 12:38
Программирование - это инструмент. Конечному потребителю интересно то, что вы этим инструментом умеете.
Сильный навык в узкой предметной области в сочетании даже со слабым навыком программирования нередко зарплатее сильного навыка программирования.
Учите предметную область. Ту самую, с которой предполагаете работать - продажи, бухгалтерия, складской учет, производство и т.д.