Во-первых, я понимаю, что этот вопрос может быть несколько длинным и расплывчатым, и я прошу прощения за это. Вероятно, это основная проблема с коротким именем для любого, кто "получил его", но, поскольку мне не хватает в этом отношении, пожалуйста, потерпите меня при описании проблемы.
Так или иначе я занимаюсь программированием с 11 лет. Это означает, что я в основном учил себя всему с самого начала. Я получил техническое образование, но не строго в области компьютерных наук (я получил высшее образование в области фотоники). Конечно, у нас были курсы по программированию, но это было для меня главным образом, и я не изучал много нового. Я продолжал обучаться самому себе ради радости этого и всегда знал, что буду делать карьеру в программировании, но все мои проекты были довольно малы в то время. У меня не было проблем с тем, чтобы держать их в уме и поддерживать их.
Теперь я чувствую себя лидером в команде, но не в корпоративной среде - я работаю в университете, разрабатывающем научное программное обеспечение (на C ++) для инженерных приложений. Внезапно проект становится (относительно) большим, и у меня возникают проблемы с тем, чтобы сосредоточиться вокруг него большую часть времени. Я теряю много времени и сил в основном на две вещи:
- Когда мне нужно вернуться к разделу кода, над которым я некоторое время не работал, мне трудно вспомнить, как он работал. Я провожу много времени, просматривая заголовочные файлы для соответствующих классов и читая комментарии, которые я размещал по пути в исходных файлах. Хотелось бы, чтобы была какая-то форма "схемы", на которую я мог бы взглянуть и восстановить картину более легко;
- Когда я внедряю изменения, иногда я на полпути понимаю, что то, что я пытаюсь сделать, сломает вещи где-то еще (или, что еще хуже, это проявляется только во время выполнения в качестве сюрприза). Я возвращаюсь и начинаю делать это по-другому, только чтобы выяснить, что пренебрегал влиянием на какой-то другой компонент. Хотелось бы, чтобы была какая-то «диаграмма архитектуры», где я мог видеть, как все делается, как то, что я пытаюсь сделать, повлияет на другие компоненты и способ для меня детально планировать, прежде чем я начну вносить изменения.
У большинства людей, с которыми я работаю, такие же истории, как и у меня, - сильная техническая ориентация и иногда отличные навыки, но у них нет возможности организовать свою работу. Тем не менее, их проекты, как правило, намного меньше, чем у меня, поэтому они как-то справляются. Во всяком случае, для меня это означает, что я сам по себе, и у меня нет никого, кто мог бы научиться хорошей практике.
Я поступил в аспирантуру по управлению ИТ, и, хотя я нахожу это вполне удовлетворительным, он в основном предназначен для непрограммистов, он рассказывает о методологиях управления проектами, оценке бюджета / графика, архитектуре предприятия и т. Д., А не о разработке программного обеспечения и планировании как таковом. Это нормально, я тоже пытаюсь научиться этому. Конечно, некоторые инструменты (такие как UML) и типы процессов разработки программного обеспечения (каскадные, итеративные, гибкие ...) были представлены, но, очевидно, не очень подробно, и мне трудно решить, что мне выбрать и использовать ( и в какой степени).
Я читал много вопросов и ответов о разработке программного обеспечения для SO - многие делают это с использованием того или иного конкретного инструмента или методологии, и если бы я был убежден, что документация UML решит мои проблемы - я бы взял это и начать использовать это. Но некоторые люди клянутся этим, другие говорят, что это бесполезно. Я ищу ответ на более высоком уровне абстракции - есть ли способы решить две проблемы, с которыми я сталкиваюсь, и как вы лично это делаете? Чему я должен научиться, чтобы быть в состоянии сделать это, возможно, без привязки к какому-либо конкретному инструменту? Они приходят и выходят из моды время от времени, и я ожидаю, что их применимость варьируется в зависимости от типа проекта.
Большое спасибо за чтение, я не мог сказать, что я имею в виду более кратко (не хватает опыта разработки программного обеспечения и словарного запаса).