Вот допустим, перед вами поставлена задача, которую вы ранее не решали.
Хотел бы узнать у коллег, сколько у вас (в процентах) уходит времени на:
1. Поиск в Инете нужной информации
2. Обдумывание (в том числе в нерабочее время)
3. Кодинг (реализацию)
Спасибо за ответы.
Здравствуйте, Kocur, Вы писали:
K>Вот допустим, перед вами поставлена задача, которую вы ранее не решали.
K>Хотел бы узнать у коллег, сколько у вас (в процентах) уходит времени на:
Всё зависит от задачи
Здравствуйте, Kocur, Вы писали:
K>Хотел бы узнать у коллег, сколько у вас (в процентах) уходит времени на:
K>1. Поиск в Инете нужной информации
K>2. Обдумывание (в том числе в нерабочее время)
K>3. Кодинг (реализацию)
п.1. обычно просто "поиск нужной информации". Как правило интернет здесь слабо помогает, только в простейших случаях.
Обычно п2. наибольший, примерно две трети всего времени. Кодинг самый короткий. Но вообще кодингом дело не заканчивается, за ним следует майнтенанс.
То есть, в упрощенном виде вот так
1 поиск информации (уточнение требований, ограничений и тд)
2 построение модели решения
3 кодинг (модель решения переводится в код)
4 майнтенанс
И это все происходит итерационно.
Но лучше строить работу примерно так
1. уточнить, что вообще нужно сделать, есть ли конечная цель, какой результат ожидается
Далее, если цель есть,
2. поставить гипотезу
3. подтвердить или опровергнуть при помощи доп. инфы (интернет, справочники, эксперимент и тд и тд). т.е. достижима ли цель
4. построение модели решения, если цель достижима
5. кодинг
6. майнтенанс
Если цели нет(открытая проблема), или цель недостижима, фактически есть проблема — то есть, неопределенность.
Начинается несколько итераций, целью будет собственно решение проблемы
Здесь формализовать довольно трудно, т.к. это до сих пор искусство
В целом неопределенность нужно исключить. Например так
1 гипотеза
2 исследования, эксперимент — выявление свойств проблемы: масштаб, характер, риски, локализация, поведение, временные и фазовые особенности и тд
3 модель проблемы
4 постановка целей/результаты
Например — много багов с точностью операций с плавающей запятой. Что за хрень? Пофиксить не получается — полгода убили, багов меньше не стало. Цель вроде бы есть, но не ясно, достижима ли она. Проблема — неизвестны причины возникновения багов с точностью.
Где искать проблему не всегда ясно. В данном случае была куча гипотез, из которых подтвердились только следующие
0. криворукие девелоперы
1. код работы с матрицами содержал косяк, который не виден был чз тесты
2. часть кода либы содержала ошибки, которые друг друга компенсировали, чз тесты были не видны
3. сервер втихаря вносил хаос, округлял младшие биты не в ту сторону
4. много дублирования и возможно мелкие ошибки в каждом из случаев
когда кое как пофиксили эти части, оказалось, что проблема все еще воспроизводится. Последняя гипотеза — последовательность вычислений содержала фундамендальный изъян — схема вычислений была упрощенной, корректной только для частного случая. Если менялся масштаб чисел, погрешность менялась случайным образом. Она подтвердилась.
Вернулись на исходную позицию, внесли основной фикс, около сотни багов ушло само собой. после этого 1, 2, 3 и 4 раскидали по спринтам, поскольку они только маскировали проблему, но не являлись причинами.
Здравствуйте, Kocur, Вы писали:
K>Вот допустим, перед вами поставлена задача, которую вы ранее не решали.
Вопрос довольно бессмысленный, так как ответ зависит от множества факторов и характера задач.
K>Хотел бы узнать у коллег, сколько у вас (в процентах) уходит времени на:
K>1. Поиск в Инете нужной информации
Задачи бывают разные. Если надо возиться с чьим-то частным и закрытым АПИ, то на это можно убить пол жизни. Например, чтобы найти как обойти то или иное ограничение в VS уходит очень много времени. В итоге скатываешься к декомпиляции и дебаджингу. Благо с каждой новой версией все больше и больше кода на дотнете.
K>2. Обдумывание (в том числе в нерабочее время)
Опять же зависит от задачи. Какие-то вещи обдумываются прямо про ходу кодирвоания. Какие-то требуют годов осмысления и кучи прототипов идущих в помойку.
K>3. Кодинг (реализацию)
А это вообще ведь перманентная. Нельзя тупо сидеть обдумывать код год, а потом взять все и без помарок написать.
Когда ты что-то обдумываешь ты не видишь моря мелких деталей. Начиная кодировать ты на них нарываешься и это заставляет тебя вносить в свои планы коррективы, а иногда и полностью от них отказываться.
Так код надо писать всегда. Возможно не рабочий код, а прототип, но все же.
В процесс создания сложного ПО всегда перемежаются моменты кодирования и моменты продумывания.
1. Если ты понимаешь, что не можешь охватить проблему прямо за компом — встань и пойди по думай.
2. Подумал — пойди попробуй написать.
3. Начал писать и понял, что твой план не учитывает некоторых фактов — снова встать и пойди еще раз подумай.
4. Если проблему можно осознать прямо за компом, не фиг вставать, пиши сразу.
5. Понял, что получается фигня... см. п. 1.
Лезть в интернеты имеет смысл когда знаешь что искать. Скажем как там в XAML-е что-то изобразить. Или какую месагу надо вызвать.
Опять же в интернеты надо лезть если нужные знания по алгоритмам, а их нет или они уже забыты. Но тут лучше сначала хотя бы какой-то обзор возможных вариантов получить. И тут лучше не интернеты, а книги и форумы вроде наших.
