Вопрос к программистам
Ни для кого не секрет, что сейчас IT-профессии считаются наиболее востребованными и "престижными" среди "простых" людей, овладеть одной из которой может, по большому счёту, каждый.
Такая мысль посещает периодически и меня. Несколько раз брался за самостоятельное изучение разных "языков", но, по тем или иным причинам, забрасывал. Чаще всего это связано с тем, что в какой-то момент возникает вопрос, ответа на который найти не можешь, а спросить некого. "Наставника", "ментора" у меня нет. И я сейчас говорю не о технических вопросах, а больше о самом "пути", "процессе работы".
В связи с чем я прошу IT-шную аудиторию Пикабу дать мне ответ: как у Вас организован рабочий процесс?
Если попробовать по порядку:
Как и в каком виде происходит поставка задачи? Как она формулируется?
Кто эти задачи "распределяет"?
Как вообще проходит рабочий день?
Ну, то есть, к примеру: я инженер-испытатель. Начальство (или смежный цех) ставит задачу - испытать на вибрационное воздействие некий узел. Сам узел в цеху №14, технические условия (документ, в соответствии с которым проходят испытания) чаще всего есть у меня "в наличии", либо выгружаю из архива. Беру узел, закрепляю на оснастке и стенде, настраиваю и включаю нужный режим, ставлю запись (если нужно) с датчиков и жду. По итогу ставлю свою электронную "подпись" на документе, подтверждающем прохождение испытаний. На всё это уходит основной объем рабочего времени. Испытания бывают разные, узлы разные, ТУ разные, оснастка и стенды тоже, но принцип всегда один - есть определенный физический параметр, воздействие которого надо проверить.
А как у программистов? Вот пришли Вы на работу (или по удаленке, не важно), как понять, чем заниматься? Я полагаю, "программа максимум" какая-то есть, допустим, разрабатываете игру для Android. Но в каждый конкретный момент времени - что? И как распределяется ответственность, если работаете в команде? Типа "Петя у нас за базы данных, а Вася за их наполнение", но кто из них определяет, в каком виде будет база?
Или, может, что-то типа "Напиши функцию, которая принимает объект с параметрами A,B,C,D, а выдаёт в формате N, где N - это (A/B)*C - D".
В общем, извините за сумбур, расскажите что-нибудь.)
Спасибо!
Без рейтинга
По большому счёту вопрос - не о программировании в узком смысле слова, а об управлении (программными, если придираться к словам) проектами.
Вообще программирование - это всегда автоматизация известной деятельности. Мне сейчас хуёв в панамку накидают за упрощения, но попробую всё же:
1. Надо понять чего хочет заказчик и зафиксировать функциональные требования - то есть выяснить какие данные программа может сожрать и какие новые данные она должна выдать.
2. Надо понять как раньше решал эту задачу заказчик - зафиксировать бизнес-правила - то есть узнать что в принципе допустимо, что - не допустимо и как с этим всем обращаться.
(Здесь пропущены разные интересные для больших программных продуктов шаги. Вам они в начале пути - примерно на уровне пояса.)
3. Разбить задачу создания программы на какое-то количество небольших частных задач - как минимум, дожен осуществляться ввод данных, их обработка и вывод результатов. Всё это - в соответствии с бизнес-правилами. Разбиение продолжается до тех пор, пока для каждой задачи не станет ясно как именно она дожна быть решена. Как минимум для каждой задачи должен быть прописан алгоритм решения хотя бы для основного хода событий (т. е. игнорируя ошибки) в понятном и доступном исполнителю (программисту) виде. Могут быть указаны основные структуры данных, общие для нескольких задач - просто чтобы не забыть. (На самом деле не только и не столько чтобы не забыть - но нам сейчас эти соображения похуй).
И вот мы подошли к самому программированию. Ура!
4. Делаем задачи, которые определили в пункте 3. Если мы всё спланировали хорошо, то у нас всё срастётся и задача будет решена.
Если что-то пошло не так, то надо понять почему и вернуться к самому корню проблемы для её правильного устранения - вплоть до пересмотра функциональных требований (что чаще всего всё же не нужно). При этом мы старое не выкидываем, а творчески преобразуем стараясь менять как можно меньше для достижения ожидаемого эффекта: чем меньше изменений, тем меньше работы - а нам лень. Впрочем, иногда лучше выкинуть почти всё (из разбиения на задачи) и сделать заново - но это либо самые первые крупные проекты, либо какая-то фатальная патология была на этапах 1-2.
5. Оценка результата. Испытания.
При необходимости сделать совсем сложную систему её можно разбить на несколько частей и ходить по пунктам по кругу для каждой из этих частей.
Начинать, естественно, надо по маленькому. Потому что если сразу по большому начать, можно обосраться и сильно из-за этого расстроиться. Поэтому сначала берётся задачник по программированию на языке XXX (бери Паскаль - не ошибёшься: базовые управляющие структуры и алгоритмы везде одни и те же, а решать-то всё равно сам будешь). Потом можно попробовать книгу вроде "Алгоритмы и структуры данных" поизучать - естественно, всё программировать, крутить-вертеть и чтобы оно писало что-то на экран. В результате может получиться методом наращивания мяса какой-нибудь супер-пупер-инженерный калькулятор, который умеет вычислять выражения даже с эллиптическими и гиперболическими функциями комплексного аргумента. Но начнётся он всё равно со сложения и умножения двух чисел.