Как мне перейти от возможности писать код к тому, чтобы стать хорошим разработчиком?

Я разочарован отсутствием конкретных объяснений о том, как перейти от возможности писать сценарии (bash, awk) и писать простые приложения (c, php, python) к проектированию и разработке более крупного и более сложного программного обеспечения. Кажется, что с одной стороны есть книги по языку программирования, а с другой - книги по разработке программного обеспечения / управлению проектами, предназначенные для команд программистов.

Я прочитал много обоих. Я читал классику XP / Agile и имею приличное теоретическое понимание процесса разработки программного обеспечения. Мне нравится читать чужой код, и я могу очень хорошо следовать ему. Но когда у меня есть идея для проекта или я хочу перейти от «вот проблема / необходимость» к «вот решение», мой разум теряет сознание, и я не знаю, с чего начать.

Я просто взломаю это? Существуют ли какие-либо структурированные рабочие процессы для отдельных разработчиков, которые не работают в командах, или для большого программного обеспечения? У меня действительно нет никакого желания получить PMP или работать на компанию-разработчика программного обеспечения. Я просто ищу эффективный, действенный, практичный рабочий процесс.

На мой взгляд, вы становитесь хорошим разработчиком, имея опыт работы и работая с несколькими способами. Вы заявили, что у вас есть проблема перехода от «вот моя идея» к «вот мое решение». Это больше относится к методологиям разработки программного обеспечения, а также к тому, чтобы быть опытным разработчиком.

Использование методологии разработки программного обеспечения - это больше, чем просто взлом кода, и эти методологии обеспечивают структурированные рабочие процессы. Семейство Agile обеспечивает хорошую структуру для небольших групп разработчиков (или отдельных лиц), которым вы можете следовать, чтобы помочь вам перейти от фазы «идеи» к фазе «готового продукта».

За несколько лет я многому научился у других и благодаря работе над различными проектами, такими как:

• Сделайте все тестируемым, это сделает вашу жизнь намного проще;
• Вы не можете ожидать, что у вас будет идеальный дизайн и вы сможете разрабатывать корпоративные приложения / следующую самую большую игру / вставить сюда больше, не имея опыта в этом;
• Сложно спроектировать хорошее программное обеспечение, если у вас нет такого опыта и вы учились у других;
• У вас никогда не будет идеального дизайна в первый раз, даже если вы опытный разработчик - все меняется, и поэтому; ваш дизайн тоже может;
• Запишите вещи: написание / рисование / белая доска / рисование / все, что вам удобно, это облегчает жизнь, если у вас есть записанные вещи. Например, дизайн GUI, диаграммы классов и т. Д. По моему опыту, просто «взломать что-то вместе» может привести к катастрофическим сбоям;
• Не изобретай велосипед, тебе не нужно этого делать. Если вы пытаетесь реализовать свой собственный HashMap, вы, вероятно, делаете что-то не так. Исследуйте вещи и подумайте, прежде чем писать код.

Надеюсь, что это поможет.

Ну, на мой взгляд, как и в любой профессии, чтобы быть хорошим профессионалом, все, что нужно - кроме теоретического образования - это опыт .

Поскольку врач не может быть хорош только с классами, взятыми в медицинской школе, или юрист не может знать всю политическую сторону того, чтобы быть адвокатом только с его степенью, чтобы быть хорошим разработчиком, нужны опыт и время.

Опыт не приходит, читая сторонний код. Если у вас есть студент-медик, он / она сможет указать на множество процедур, заболеваний, лекарств и т. Д., Но фактическое применение этих вещей (когда применять одну процедуру, какое заболевание диагностировать и т. Д.) Только приходит с наблюдением и опытом.

Поскольку вы не хотите работать в большой компании (или в любой другой компании), я предлагаю вам начать с разработки небольших приложений, по одному шагу за раз. Самостоятельная разработка программного обеспечения занимает много времени, поверьте мне.

Еще одна вещь, которую я предлагаю вам, чтобы стать хорошим разработчиком / инженером программного обеспечения, - это содействие открытому программному обеспечению. Многие ребята зарабатывают немалые деньги (и опыт, кстати), помогая разрабатывать программное обеспечение с открытым исходным кодом и давая консультации после этого. Они сделали себе имя своими вкладами в открытый код.

Во всяком случае, я думаю, что нет никакого пути к получению опыта, и его нужно преследовать с дисциплиной и терпением .

Вы можете начать с улучшения кода других людей. Возьмите какой-нибудь проект и добавьте в него функцию. Вам нужно решить, что будет делать эта функция и как она должна это делать. Работая в рамках существующего кода, разработайте свое решение.

И не бойся взломать вещи. Много новых разработок делается путем улучшения (или, предпочтительно, переписывания) быстрых и грязных прототипов. Идите вперед и используйте все наихудшие практики и антипаттерны из книги, просто найдите то, что делает то, что вы хотите. Затем вернитесь и спроектируйте его правильно. Обычно я думаю: «Знаешь, лучший способ сделать это был бы ...», в то время как я жестко программирую некоторые параметры конфигурации в своем 800-строчном трехпроцессном уродстве.

Я знаю, что в настоящее время это не в моде, но методы структурного анализа действительно помогли мне разобраться в разработке программного обеспечения. Поиграйте с созданием нескольких пузырьковых диаграмм и DFD, чтобы почувствовать, как разбирать проблемы, и спроектировать различные части системы для совместной работы.

Как уже говорили другие, опыт приходит от написания кода. Но вам также следует, чтобы кто-то еще просмотрел ваш код, если это возможно. Более опытный программист может указать на проблемы в вашем коде и показать вам лучшие способы работы. Вклад в проект с открытым исходным кодом даст вам шанс сделать и то, и другое.

Для меня это помогает разбить большую часть программного обеспечения на более мелкие куски. А затем разбить эти куски на еще более мелкие части и так далее. Каждая программа представляет собой набор маленьких кусочков логики.

Рассмотрим блог, например. Вы хотите иметь возможность создавать и редактировать сообщения, которые могут читать другие. Сразу же вы можете разделить проект на административный и публичный разделы. Как минимум, администратору потребуются пользователи-администраторы, страница входа и раздел для управления блогом. Раздел для управления блогом может быть разбит на интерфейс CRUD (Создать, Читать, Обновить, Удалить). Создание нового сообщения в блоге потребует проверки, чтобы убедиться, что у пользователя-администратора есть нужные привилегии, форма, проверка формы и возможность сохранения в базе данных. И так далее.

Чем больше вы ломаете проблему или функцию, тем более управляемой она становится. Это разделяй и властвуй. После того, как вы смогли отобразить свое программное обеспечение таким образом, вы можете посмотреть, как разные его части взаимодействуют друг с другом. Где вы могли бы повторить код? Что можно абстрагировать? Это должен быть итеративный процесс как при планировании, так и при написании самого кода.

Я бы порекомендовал выяснить, каков ваш минимальный набор функций, и реализовать его, прежде чем добавлять к нему другие части. Вы захотите защищать код, чтобы будущие изменения не были слишком сложными, но в то же время вы не хотите реализовывать половинные функции, которые могут никогда не быть реализованы. Трудно пройти путь между тем, чтобы оставаться гибким и готовым безжалостно убивать своих любимых, заимствовать литературную ссылку. Добиться успеха в этом конкретном балансирующем акте можно только благодаря опыту.

И вот к чему все сводится, как уже упоминалось в других ответах: опыт. Единственный способ получить это - просто начать. Не беспокойтесь о том, чтобы сделать его идеальным с самого начала. Сначала заставьте код работать, затем сделайте его красивым, затем сделайте это быстро.

Кроме того, в отличие от этого параграфа, не думайте о безопасности в конце как о запоздалой мысли. Вы должны иметь представление о том, как ваше программное обеспечение может быть взломано, но для начала никогда не доверяйте никаким пользовательским данным.

Я знаю, вы говорите, что не хотите работать в софтверной компании, но это хорошее место, чтобы получить опыт, о котором говорят многие другие ответы. И хотите ли вы работать над большими проектами, знакомство с работой и стилем работы других людей - это хорошие вещи.

Например, вы не можете попробовать парное программирование самостоятельно. И если вы работаете в паре с кем-то умнее, чем вы, вы получаете дополнительное преимущество, получая от них лучшие практики, получая опыт в этой методологии.

Кстати, я стал практиковать работу с группами, где я чувствую, что я ниже среднего по опыту, навыкам и тому подобному. Это поднимает мою игру чрезвычайно. Это гораздо сложнее сделать это в одиночку или там , где ты «опытный» парень.

То, что вы ищете, это навыки решения проблем . Я заметил, что предполагается, что разработчик уже может сделать это, что глупо. К счастью, решение проблем - это общий навык, используемый в математике, исследованиях, повседневной жизни и так далее.

Прежде всего, вы должны следовать научному методу с некоторыми изысками.

1. У вас есть проблема (используйте инструменты и методы, чтобы помочь определить это)
2. Вы выдвигаете гипотезу решения (шаблоны и опыт помогают)
3. Проверьте гипотезу (у вас может даже не быть кода здесь)
4. Повторите шаги 2 и 3, пока гипотеза не подтвердится. Теперь у вас есть теория (рабочая программа для решения проблемы)
5. Разработайте эксперимент, чтобы подчеркнуть теорию, ища дыры (контрольные примеры!)
6. Если тесты пройдут, у вас есть решение! В противном случае промыть и повторить

Обратите внимание, что это довольно высокий уровень. Каждый шаг обычно включает несколько подэтапов, например, определение проблемы на самом деле. В качестве примера рассмотрим решение словесных задач по математике. Вы собираете факты (инструмент) и определяете, чего на самом деле хотите. Затем вы изучаете свои факты, пытаясь сопоставить их с решением.

Это в конечном итоге становится подпроблемой основной проблемы. Итак, следуйте инструкциям еще раз. Нам нужен промежуточный элемент, чтобы получить конечный результат, поэтому он становится нашей новой проблемой. Это разбивает проблему на маленькие, легко понятные разделы. Когда каждый кусок решен, решение соединено вместе.