Во-первых, я понимаю, что этот вопрос может быть несколько длинным и расплывчатым, и я прошу прощения за это. Вероятно, это основная проблема с коротким именем для любого, кто "получил его", но, поскольку мне не хватает в этом отношении, пожалуйста, потерпите меня при описании проблемы.
Так или иначе я занимаюсь программированием с 11 лет. Это означает, что я в основном учил себя всему с самого начала. Я получил техническое образование, но не строго в области компьютерных наук (я получил высшее образование в области фотоники). Конечно, у нас были курсы по программированию, но это было для меня главным образом, и я не изучал много нового. Я продолжал обучаться самому себе ради радости этого и всегда знал, что буду делать карьеру в программировании, но все мои проекты были довольно малы в то время. У меня не было проблем с тем, чтобы держать их в уме и поддерживать их.
Теперь я чувствую себя лидером в команде, но не в корпоративной среде - я работаю в университете, разрабатывающем научное программное обеспечение (на C ++) для инженерных приложений. Внезапно проект становится (относительно) большим, и у меня возникают проблемы с тем, чтобы сосредоточиться вокруг него большую часть времени. Я теряю много времени и сил в основном на две вещи:
- Когда мне нужно вернуться к разделу кода, над которым я некоторое время не работал, мне трудно вспомнить, как он работал. Я провожу много времени, просматривая заголовочные файлы для соответствующих классов и читая комментарии, которые я размещал по пути в исходных файлах. Хотелось бы, чтобы была какая-то форма "схемы", на которую я мог бы взглянуть и восстановить картину более легко;
- Когда я внедряю изменения, иногда я на полпути понимаю, что то, что я пытаюсь сделать, сломает вещи где-то еще (или, что еще хуже, это проявляется только во время выполнения в качестве сюрприза). Я возвращаюсь и начинаю делать это по-другому, только чтобы выяснить, что пренебрегал влиянием на какой-то другой компонент. Хотелось бы, чтобы была какая-то «диаграмма архитектуры», где я мог видеть, как все делается, как то, что я пытаюсь сделать, повлияет на другие компоненты и способ для меня детально планировать, прежде чем я начну вносить изменения.
У большинства людей, с которыми я работаю, такие же истории, как и у меня, - сильная техническая ориентация и иногда отличные навыки, но у них нет возможности организовать свою работу. Тем не менее, их проекты, как правило, намного меньше, чем у меня, поэтому они как-то справляются. Во всяком случае, для меня это означает, что я сам по себе, и у меня нет никого, кто мог бы научиться хорошей практике.
Я поступил в аспирантуру по управлению ИТ, и, хотя я нахожу это вполне удовлетворительным, он в основном предназначен для непрограммистов, он рассказывает о методологиях управления проектами, оценке бюджета / графика, архитектуре предприятия и т. Д., А не о разработке программного обеспечения и планировании как таковом. Это нормально, я тоже пытаюсь научиться этому. Конечно, некоторые инструменты (такие как UML) и типы процессов разработки программного обеспечения (каскадные, итеративные, гибкие ...) были представлены, но, очевидно, не очень подробно, и мне трудно решить, что мне выбрать и использовать ( и в какой степени).
Я читал много вопросов и ответов о разработке программного обеспечения для SO - многие делают это с использованием того или иного конкретного инструмента или методологии, и если бы я был убежден, что документация UML решит мои проблемы - я бы взял это и начать использовать это. Но некоторые люди клянутся этим, другие говорят, что это бесполезно. Я ищу ответ на более высоком уровне абстракции - есть ли способы решить две проблемы, с которыми я сталкиваюсь, и как вы лично это делаете? Чему я должен научиться, чтобы быть в состоянии сделать это, возможно, без привязки к какому-либо конкретному инструменту? Они приходят и выходят из моды время от времени, и я ожидаю, что их применимость варьируется в зависимости от типа проекта.
Большое спасибо за чтение, я не мог сказать, что я имею в виду более кратко (не хватает опыта разработки программного обеспечения и словарного запаса).
источник
Ответы:
Представьте, как будет чувствовать себя бедняга, который придет за вами - он даже не знает, как однажды узнает, как работает ваш код. Вместо того, чтобы пытаться расшифровать ваш код, вы должны просмотреть документацию, которую вы написали для данного модуля. Эта документация должна содержать достаточно точное представление о том, что делает модуль, почему. Это не «модуль начинает с инициализации трех массивов с использованием цикла triple for ...», а вместо этого: «этот модуль извлекает данные, собранные главным датчиком Fabulotron, перестраивает их в стандартный формат Neopolitan (шоколад, ваниль, клубника), и доставляет его в модуль анализа ".
В идеальном мире у вас будет проектный документ, в котором изложены различные модули в системе и описаны их соответствующие обязанности, и каждый из ваших модулей может просто обратиться к этому документу, чтобы объяснить, что они делают: «Этот модуль предоставляет Служба сбора данных Fabulotron, как описано в разделе 4.8 проектной документации: http://fabulotron.org/design/section4-8.html . " Если у вас нет чего-то подобного, начните записывать обзор каждого модуля во время работы над ним. Вам не нужно писать книгу - часто достаточно нескольких абзацев, чтобы вы могли ориентироваться.
Это может быть признаком того, что ваши модули слишком взаимосвязаны. Чем более независимыми вы можете сделать свои модули / классы / модули, тем меньше вероятность того, что вы столкнетесь с такой проблемой. Постарайтесь сделать интерфейсы между модулями как можно более явными и постарайтесь ограничить их только тем, что должно быть там. Интерфейс - это контракт - если вы знаете, что какой-то модуль выполняет свои обязательства, указанные в интерфейсе, вам не нужно больше ничего о нем знать. Это предотвращает изменения в модуле, над которым вы работаете, на другие модули.
Использование стандартных деталей может помочь в этом отношении. C ++ предоставляет стандартные части в форме стандартной библиотеки шаблонов, и использование этих частей, где это необходимо, позволяет работать на более высоком уровне абстракции. Если вы написали свой собственный код для управления структурами данных, такими как списки, вам и тем, кто следует за вами, придется постоянно читать исходный код, чтобы выяснить, что происходит. Если вместо этого вы будете использовать стандартные компоненты, предоставляемые STL, любой программист C ++ сможет быстро рассказать, что делает ваш код, не углубляясь в процедуры управления данными.
Другой тип стандартной детали - это шаблоны дизайна. Это стандартные концепции, которые можно использовать для краткости, чтобы объяснить, как работают отношения между двумя объектами.
источник
Я был профессиональным разработчиком только в течение короткого периода времени, и много боролся с тем, как это сделать, когда я только начинал. Я был в первую очередь самоучкой, даже через университет. К счастью для меня, люди, с которыми я работал, имеют большой опыт и смогли научить меня, как управлять большими проектами и работать с ними.
Одним из первых, что заставило меня сделать, было сесть и прочитать чистый код . Это фантастическая книга, которая помогла мне понять, как писать код, который я мог понять, когда вернулся к нему, или который мог понять кто-то другой.
Во-вторых, нужно было написать качественные тесты: Unit, Integration, Acceptance. Если ваш код хорошо протестирован, вы быстро узнаете, когда что-то сломали, и сможете быстро диагностировать проблему. В Интернете есть много хороших ресурсов для тестирования, и я не уверен, что лучше всего предложить вам.
Мои ключевые моменты - Тестирование и Чистый Код.
источник
Вот несколько идей высокого уровня для организации больших программных систем. Большая часть моего опыта связана с интернет-системами, но я думаю, что эти идеи применимы к инженерному программному обеспечению.
Прошло много времени с тех пор, как я работал с инженерным программным обеспечением, поэтому ваш пробег может варьироваться в зависимости от этих предложений. Удачи!
источник
Ответ - разработка программного обеспечения.
То есть для больших проектов вы должны следовать установленной последовательности сбора требований, определения процесса, спецификации и т. Д. Задолго до того, как будет выполнено какое-либо реальное кодирование.
Существуют различные методологии, используемые в зависимости от окружающей среды и культуры. Предприятия корпоративного типа, как правило, следуют « Рациональному унифицированному процессу » или подобным, технические стартапы, как правило, допускают некоторые вариации в Agile , а государственные ведомства - в некоторой степени перегруженную методологию Waterfall .
Во всех случаях этот процесс помогает вам точно определить, что вы делаете, и к концу проекта позволяет доказать, что вы это сделали.
источник
Я настоятельно рекомендую вам приобрести Enterprise Architect , который, хотя и не является бесплатным, предлагает академические цены. Это отличный инструмент для построения диаграмм проектов как на макро, так и на микроуровне. Он также может преобразовать ваши исходные файлы в диаграммы классов, что, вероятно, станет хорошим началом для вас при документировании и реорганизации того, как ваше приложение работает вместе.
Я также второй рекомендации @ Клее. Не отчаивайтесь предполагаемыми «гибкими» инструментами, поскольку они на самом деле являются просто лучшими практиками, которые также удобны (если не обязательны), если вы следуете гибкому процессу. Но непрерывная интеграция (например) важна независимо от вашей методологии. Кроме того, юнит-тесты (cppUnit?) Ваши друзья. Модульные тесты должны быть очень выполнимы, если вы тестируете логические классы, которые вызываются вашим пользовательским интерфейсом, а не тестируете пользовательский интерфейс напрямую. Существуют также инструменты, которые могут помочь вам автоматизировать тестирование пользовательского интерфейса, но я постараюсь сначала собрать все вместе.
Удачи!
источник
Я считаю, что ваша проблема имеет три измерения
Что касается первой проблемы, у вас могут быть программисты, которые не понимают концепцию того, что делает программа (это часто происходит в корпоративных установках). Но, исходя из вашего вопроса и домена, в котором вы находитесь, кажется, что вы и ваша команда контролируете то, что делает программа, но просто не можете быстро перевести ее в рабочую программу (приведу пример, я слышал о людях Я имею докторские степени по физике, у меня проблемы с пониманием указателей в программировании, и я уверен, что физика гораздо сложнее, чем C ++). Если это так, то ваша проблема в основном ориентирована на программу (вам должно повезти, что окружающие вас люди могут понять, что делает ваша программа, и могут оценить ее).
В случае программно-ориентированных проблем, одним из моих возмутительных предложений было бы перейти на более высокий уровень абстракции, чем C ++, например, выучить новый язык как Python или Haskell (Python довольно прост в изучении, и если у вас есть хорошие математики, Хаскель просто великолепен). Переход на более высокий уровень абстракции уменьшит размер вашего кода, будет легок для понимания и поддержки в долгосрочной перспективе и быстро приведет к изменениям. Таким образом, вы можете иметь 10 строк кода вместо оригинальных 50 строк кода. Кроме того, наличие специалиста по компьютерному программированию определенно поможет. Находясь в университете, вы также можете принять участие нескольких студентов в GUI и интерфейсах, чтобы вы могли больше сосредоточиться на функциональности. Я также рекомендую книгу Большого масштаба C ++ Software Design Джона Лакоса(Это довольно большая книга, вы можете стать опытным программистом Python за то время, которое у вас ушло на ее чтение)
Если вы разберетесь с первыми двумя измерениями вашей проблемы, третье будет решено автоматически. Так как я верю, что вы работаете над одним крупным проектом, с любым достойным программным обеспечением для управления проектами вы справитесь. Предварительное планирование необходимо. Если вы сразу начнете кодировать, вы можете слишком увлекаться программой, что вы забудете общую картину. Помнить вещи не будет работать для большого проекта. Поместите все в бумагу (или в компьютер). Используйте вики для обмена информацией. Что касается методологий, я предпочитаю гибкую методологию (просто agile - это стильное название для постепенной разработки программного обеспечения). Я также предлагаю нанять человека с опытом в этой области, чтобы он позаботился об этом, чтобы вы могли сосредоточиться на своей основной программе. Суть в том, что все методологии управления проектами - это просто способ обеспечить успех программы; так что вы можете выбрать кого-то, кто подходит вам и вашей команде, вместо того, чтобы выбирать то, что кто-то рекомендует лучше всего. Кроме того, следующее программное обеспечение может также помочь вам
Хотя вышеприведенные советы в определенной степени обойдутся вам в обучении. И, наконец, программирование проще, чем Photonic Engineering (хотя и не программирование на C ++)
источник
Как и ваш вопрос, любой полезный для вас ответ будет очень длинным и расплывчатым, но короткий ответ - «Разработка программного обеспечения».
Я предлагаю вам освободить немного свободного времени, насколько это возможно, если вы серьезно относитесь к карьере разработчика программного обеспечения, и начните с посещения сайта Стива Макконнелса . Программирование является простым и может преподаваться в течение семестра, разработка программного обеспечения на порядок сложнее и требует гораздо больше времени для изучения.
источник