Проекты в нашей отрасли - сложные. Особенно если речь идёт о стыке алгоритмистики, бизнес-логики и пользовательского интерфейса.
Посему я лично не поручусь за себя, что могу обеспечить АНАЛИТИЧЕСКУЮ целостность решения. По молодости я пытался порождать "сферических коней в вакууме" и искать максимально общие правильные решения. Но с годами я понял, что я лично - не могу это осилить. Мысли разбегаются как тараканы. Начинаешь уходить в глубины деталей. Там и увязаешь.
Да и требования порой бывают противоречивые.
Я плохой математик. Никакой. В общем-то - посредственный программист и, уж конечно, - никакой аналитик. Я не умею решать задачи "сейчас и в общем".
Я скорее - "технарь" с "большим объёмом памяти" и набором сложившихся практик и типовых решений. (Как было подсказано - "типовые узлы" деталей и механизмов - сидят у меня в голове)
Посему - когда я натыкаюсь на заковыристую ошибку, то я поступаю следующим образом:
Я КОНЕЧНО сначала долго и вдумчиво трассирую систему, изучаю значения переменных и её поведение и стараюсь проникнуть в суть вещей. И понять логику системы. В этот момент я зачастую смотрю на систему и как на "белый" ящик и как на "чёрный".
Если мне это хоть как-то удаётся, то я поступаю так - http://18delphi.blogspot.com/2013/03/blog-post_54.html
Если не удаётся.
А это может быть по многим причинам:
1. Код написан коллегами, которые сейчас недоступны.
2. Пробелы в ТЗ.
3. Неясность логики.
4. Непонятные граничные условия.
5. Непредсказуемость данных.
6. Непредсказуемость поведения пользователя.
7. Сам писал "это", но забыл.
Тогда я поступаю следующим образом:
1. Прогоняю все доступные тесты. Убеждаюсь, что они срабатывают. Если не срабатывают, то разбираюсь с ними. Если не удалось разобраться, то отключаю их.
2. Смотрю на проблемное место.
3. Понимаю в каком месте логика пошла не так.
4. Разбиваю эту логику на несколько ветвей.
5. Те ветви, которые я не понимаю - я покрываю assert'ами (http://18delphi.blogspot.com/2013/04/blog-post.html).
6. Сосредотачиваюсь на ветке для исходной ошибки. Покрываю её тестом.
7. Убеждаюсь, что тест не проходит.
8. Пытаюсь исправить ошибку.
9. Убеждаюсь, что она исчезла. Руками.
10. Прогоняю тест и убеждаюсь, что он прошёл.
11. Прогоняю остальные тесты и смотрю - какие прошли, а какие нет.
12. Если тесты не прошли, то возвращаюсь к первому шагу.
13. Если тесты прошли - отправляю ошибку в Группу Качества.
14. Жду ответа от Группы Качества. Если они написали новые ошибки, то рассматриваю их отдельно. Если они вернули ЭТУ ошибку, то возвращаюсь к первому шагу.
15. В итоге - процесс обычно сходится.
P.S. как дополнительный "бенефит" - база тестов всё пополняется и пополняется.
Посему я лично не поручусь за себя, что могу обеспечить АНАЛИТИЧЕСКУЮ целостность решения. По молодости я пытался порождать "сферических коней в вакууме" и искать максимально общие правильные решения. Но с годами я понял, что я лично - не могу это осилить. Мысли разбегаются как тараканы. Начинаешь уходить в глубины деталей. Там и увязаешь.
Да и требования порой бывают противоречивые.
Я плохой математик. Никакой. В общем-то - посредственный программист и, уж конечно, - никакой аналитик. Я не умею решать задачи "сейчас и в общем".
Я скорее - "технарь" с "большим объёмом памяти" и набором сложившихся практик и типовых решений. (Как было подсказано - "типовые узлы" деталей и механизмов - сидят у меня в голове)
Посему - когда я натыкаюсь на заковыристую ошибку, то я поступаю следующим образом:
Я КОНЕЧНО сначала долго и вдумчиво трассирую систему, изучаю значения переменных и её поведение и стараюсь проникнуть в суть вещей. И понять логику системы. В этот момент я зачастую смотрю на систему и как на "белый" ящик и как на "чёрный".
Если мне это хоть как-то удаётся, то я поступаю так - http://18delphi.blogspot.com/2013/03/blog-post_54.html
Если не удаётся.
А это может быть по многим причинам:
1. Код написан коллегами, которые сейчас недоступны.
2. Пробелы в ТЗ.
3. Неясность логики.
4. Непонятные граничные условия.
5. Непредсказуемость данных.
6. Непредсказуемость поведения пользователя.
7. Сам писал "это", но забыл.
Тогда я поступаю следующим образом:
1. Прогоняю все доступные тесты. Убеждаюсь, что они срабатывают. Если не срабатывают, то разбираюсь с ними. Если не удалось разобраться, то отключаю их.
2. Смотрю на проблемное место.
3. Понимаю в каком месте логика пошла не так.
4. Разбиваю эту логику на несколько ветвей.
5. Те ветви, которые я не понимаю - я покрываю assert'ами (http://18delphi.blogspot.com/2013/04/blog-post.html).
6. Сосредотачиваюсь на ветке для исходной ошибки. Покрываю её тестом.
7. Убеждаюсь, что тест не проходит.
8. Пытаюсь исправить ошибку.
9. Убеждаюсь, что она исчезла. Руками.
10. Прогоняю тест и убеждаюсь, что он прошёл.
11. Прогоняю остальные тесты и смотрю - какие прошли, а какие нет.
12. Если тесты не прошли, то возвращаюсь к первому шагу.
13. Если тесты прошли - отправляю ошибку в Группу Качества.
14. Жду ответа от Группы Качества. Если они написали новые ошибки, то рассматриваю их отдельно. Если они вернули ЭТУ ошибку, то возвращаюсь к первому шагу.
15. В итоге - процесс обычно сходится.
P.S. как дополнительный "бенефит" - база тестов всё пополняется и пополняется.
Комментариев нет:
Отправить комментарий