Невольно становится программистом: как это сделать правильно? [закрыто]

Мой опыт - электротехника, точнее DSP. Компания, в которой я сейчас работаю, выполняет множество разнообразных проектов, в основном создание аналогового оборудования. Будучи несколько ближе к компьютерам, чем все остальные здесь, я часто пишу код как для встроенных устройств (с которыми я прекрасно справляюсь), так и для ОС Windows или Linux. Это последняя для меня чужая территория.

Я умею кодировать и знаю несколько языков (C / C ++, Java, немного VB.NET), но я использовал их только для моделирования алгоритмов при обработке сигналов и изображений, нейронных сетей и других подобных приложений. Для меня программирование было вычислительным инструментом больше всего на свете. Тем не менее, я получаю все больше и больше проектов, в которых мне приходится писать полноценное программное обеспечение, и я не знаю, как это сделать, потому что мне никогда не приходилось это делать, и я никогда не был достаточно заинтересован. Я сам видел довольно много инженеров, которые были в определенной степени преобразованы в программистов из-за требований работы, и большинство из них не были настолько хороши в том, что они делали. Я уверен, что многие люди сталкивались с тем же.

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

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

Pragmatic Programmer также очень полезный ресурс, и он довольно короткий, но я предлагаю вам прочитать его после Code Complete.

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

Моя компания делает это все время ... и это сводит меня с ума.

«Я разработчик программного обеспечения, как мне стать EE?»

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

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

Нельзя сказать, что вы не можете быть достаточно приличными сами по себе, если потратите время. Просто оцените объем материалов, чтобы не перегружать себя, и A. Quit или B. Внесите основной технический долг в свои приложения, сделав основные сокращения в процессе обучения.

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

Попробуйте Amazon.com, у них хорошие обзоры книг.

Книги : главное - читать (хорошие) книги на своем языке. Как только вы узнаете свой язык, вы можете получить « Более эффективный X» или «Y best Practices» и так далее. Я считаю кулинарные книги очень хорошими в преодолении пробелов, которые у вас могут быть. Итак, я думаю, это как минимум три книги, которые вам нужно получить. Одно: делайте упражнения и кодируйте ката, чтобы улучшить ваше понимание языка. Конечно, вам нужен хороший шаблон xUnit .

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

Итог: это требует времени. Не спешить.

Вы засасываете кодирование. Да.

Но - это не значит, что вы не можете поставить программное обеспечение, которое делает людей счастливыми;)

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

Используйте хорошую IDE. Это очень важно, так как это поможет вам отформатировать код и отследить опечатки / простые ошибки.

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

Используйте SVN , часто совершайте коммиты, чтобы вы могли отменить свои изменения (когда вы что-то испортите).

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

И, конечно же, самое главное, чтобы сохранить кодирование, кодирование, кодирование .

PS: если вы умеете писать код на C ++, который работает, и вы пишете нейронные сети (!) - тогда ваш мозг хорошо подходит для программирования;) Удачи!

Здесь есть хорошие ответы.

Большое преимущество в вашу пользу - это тот простой факт, который вы хотите знать.

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

Таким образом, когда вы вернетесь к коду через год или больше, вы не будете думать: «Кто сделал этот беспорядок?» Вы сможете найти вещи и изменить их без особого риска поломки. **

Хороший способ начать - найти различные примеры программ и проработать их. Тогда вы можете адаптировать их к вашим потребностям.

** Одна из моих самых больших проблем - работать с кодом, написанным людьми, которые не думали, что форматирование или именование имеют значение.

В то время как есть много хороших ресурсов о том, как делать, а что нет, в конце самое важное - увидеть много кода и поработать с ним, а также понять, насколько легко или сложно его поддерживать для себя.

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

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

Одной вещью, которую я действительно рекомендовал бы для изучения качественного кодирования и архитектурных проблем, были бы учения "Дяди Боба" (Роберт Мартин). У него есть несколько видео за $ 1 , которые хороши по размеру, если возможно, слишком капризны, а также некоторые хорошие книги.