В последнее время я получаю профессиональную работу, общаюсь с другими программистами и заводлю друзей в индустрии. Единственное, я на 100% самоучка. Это заставило мой стиль чрезвычайно отклоняться от стиля тех, кто должным образом обучен. Это методы и организация моего кода, которые отличаются.
Это смесь нескольких вещей, которые я делаю. Я склонен смешивать несколько парадигм программирования. Вроде Функциональный и ОО. Я склоняюсь к функциональной стороне больше, чем к ОО, но вижу использование ОО, когда что-то имеет больше смысла как абстрактная сущность. Как игровой объект. Далее я тоже иду простым путем, когда что-то делаю. И наоборот, иногда кажется, что код, который я вижу у профессиональных программистов, сложен ради этого! Я использую много замыканий. И, наконец, я не лучший комментатор. Мне легче читать мой код, чем читать комментарии. И в большинстве случаев я просто заканчиваю читать код, даже если есть комментарии. Кроме того, мне сказали, что из-за того, как просто я пишу свой код, его очень легко читать.
Я слышал, что профессионально подготовленные программисты продолжают говорить о таких вещах, как модульные тесты. Что-то, что я никогда не использовал раньше, поэтому я даже не представляю себе, кто они и как они работают. Много и много подчеркиваний "_", которые мне не по вкусу. Большинство техник, которые я использую, прямо от меня, или несколько книг, которые я прочитал. Ничего не знаю о MVC, я много слышал об этом, например, с backbone.js. Я думаю, что это способ организовать приложение. Это просто смущает меня, потому что к настоящему времени я создал свои собственные организационные структуры.
Это немного боли. Я не могу использовать шаблоны приложений вообще, когда узнаю что-то новое, например, в Ubuntu Quickly. У меня проблемы с пониманием кода, который я могу сказать от кого-то обученного. Полное OO-программирование действительно оставляет неприятный привкус во рту, но, похоже, это то, что строго использует ВСЕ.
Это оставляет меня не настолько уверенным во взгляде на мой код или на вопрос, вызову ли я искры при присоединении к компании или, возможно, внесу свой вклад в проекты с открытым исходным кодом. На самом деле, я довольно напуган тем, что люди в конечном итоге будут проверять мой код. Является ли это просто нормальным явлением для любого программиста, или я действительно должен изменить свои методы?
Ответы:
Хорошо. Осознание того, что люди будут смотреть на ваш код, заставит вас стараться изо всех сил.
Программирование стало невероятно большой областью. Существуют десятки тем, инструментов, ниш и специализаций, некоторые из которых сами по себе являются карьерой. Существует множество возможностей для изучения и изучения, и когда вы работаете с другими программистами, всегда найдется то, что вы знаете, а они - нет, и то, что они знают, а вы нет. Это хорошая вещь.
Если вы беспокоитесь о том, что ваш опыт неполон, вы можете предпринять множество шагов, чтобы исправить это путем формального обучения и сотрудничества с обученными экспертами. Но, похоже, вы боитесь, что есть какой-то измеримый рубеж, после которого люди говорят: «Хорошо, теперь, когда я освоил это, я официально программист». Нет такой вехи. У меня определенно были моменты, когда я думал «да, теперь я где-то» после того, как узнал что-то новое, но нет волшебного списка вещей, которые вы должны знать и делать, чтобы называть себя программистом.
Я много знаю о программировании, я использовал дюжину языков во многих проектах, и тем не менее подмножество знаний в области программирования, которые я могу назвать своими, крошечное. И мне это нравится. Честно говоря, вы не программист. Программист - это то, чему вы постоянно учитесь.
Проведите честную инвентаризацию своих навыков, своих сильных и слабых сторон. Получайте отзывы от людей с большим опытом, чем вы. Ищите позиции, которые хорошо сочетаются с тем, где вы думаете, но не бойтесь идти на работу, которая немного выходит за рамки вашего текущего мастерства. Если вы берете только работу, о которой уже знаете все, вы никогда не научитесь на работе.
источник
Когда вы начнете разрабатывать приложения в сотрудничестве с другими разработчиками, некоторые из этих недостатков личного стиля будут мешать.
Если вы начнете работать в магазине, который использует нижнее подчеркивание, вы будете использовать нижнее подчеркивание. Каждый, независимо от своего предыдущего опыта, придерживается стандарта магазина для стиля кодирования.
Если ваш стиль кодирования не слишком очевиден, вам лучше привыкнуть писать четкие и краткие комментарии, объясняющие, как работает ваш код, чтобы другие разработчики могли им следовать.
Если вы ничего не знаете о модульных тестах, купите хорошую книгу. Есть много хороших книг по модульному тестированию. То же самое с MVC.
Профессиональные разработчики программного обеспечения знают, как хорошо играть с другими, не засоряя песочницу. Самые лучшие знают, как читать и писать код независимо от стиля.
источник
Программирование имеет художественный компонент и дисциплину. Художественная составляющая состоит в том, чтобы придумать лучшие подходы и реализовать их; дисциплина заключается в том, чтобы убедиться, что вы сделали это правильно, и что другие могут понять ваш код и улучшить его при необходимости.
Художественный компонент - это весело: вы делаете это, потому что вам это нравится. Естественно, это та часть, которой вы учите себя в первую очередь.
Компонент дисциплины - скорее неприятность: вы делаете это по необходимости. Тем не менее, это жизненно важный компонент работы в команде: вы не можете уйти от этого, по крайней мере, до некоторой степени. Как только ваш код интегрирован с кодом ваших товарищей по команде, ваша гибкость, чтобы «изменить вещи по желанию», погрузится в нос. Тем не менее, вам нужна возможность уверенно изменять свой код в ответ на изменяющиеся требования или устранять ошибки. Вот тут-то и приходят различные «скучные» тесты: с большим количеством тестов легко проверить, ломает ли ваше последнее изменение что-то или нет.
Стиль кода также приобретает все большее значение, поскольку соблюдение общего стиля облегчает чтение кода для всех. В более крупных компаниях вы найдете ночные задания, которые автоматически проверяют соответствие стандартам кодирования, и отправляют вам по электронной почте неприятные предупреждения, когда вы отклоняетесь.
Возвращаясь к вашему вопросу, концентрация на художественном компоненте - естественная ранняя стадия развития программиста. Может потребоваться несколько лет работы в отрасли, прежде чем вы начнете ценить компонент дисциплины. Вам не нужно активно смотреть на «изменение ваших методов», хотя: они будут естественным образом меняться в процессе работы в команде.
источник
На ваш вопрос, да, вы всегда должны стремиться изменить свою технику, чтобы охватить уникальный проект и новые технологии.
@ assfallows: «Честно говоря, программист - это не то, чем вы являетесь. Программист - это то, чем вы постоянно учитесь». это действительно все и конец всего кодирования.
Замечательно, что вы замечаете области, где вы делаете что-то отличное от других, особенно когда вы видите, что это стандарт. Вы заметили Unit Testing и MVC - и теперь ваш следующий шаг должен быть о них узнать. Посмотрите, как они работают, что вам нужно для их реализации, и постарайтесь понять, когда это хороший дизайн для их реализации.
Это постоянно развивающаяся область с новыми языками и моделями, поднимающимися и опускающимися. Если вы знакомы с аспектом кодирования, начните изучать часть дизайна. Узнайте, что делает их хорошими и когда их использовать.
Конечно, присоединение к команде - это большое преимущество - вам всегда нужны другие глаза, чтобы взглянуть на ваш код, чтобы определить области, которые вы бросили или не продумали все последствия.
источник
Вам не нужно быть большим комментатором. Но вы должны быть хорошим коммитером (да, начните использовать какую-то VCS - я рекомендую Git).
Стиль - это то, что ВСЕГДА развивается. Не беспокойся об этом. Вы узнаете, что такое код многоразового использования, а что нет. Но вы должны практиковаться и получать помощь для этого.
Попробуйте помочь в каком-нибудь проекте с открытым исходным кодом на Github. Некоторые люди там очень милые и попытаются вам помочь. Это лучший совет, который я могу вам дать.
источник
Как бы вы узнали, что изменить без обратной связи от более опытных программистов?
Заставлять других людей проверять вашу работу может быть непросто, особенно в первые несколько раз, но это лучший способ получить конструктивную критику, необходимую вам для улучшения ваших навыков. Есть сайт SE для обзоров кода , который может оказаться полезным. Попросить умных друзей взглянуть на ваш код - еще один хороший способ получить обратную связь.
источник
Самое главное - развивать гибкость. Чем больше вы знакомы с фундаментальными понятиями, тем более отзывчивым вы можете быть на любом языке, подходе к программированию, стиле или среде.
Мастерство заключается не столько в изучении каждой вещи, сколько есть, а в обучении / как / чтобы решить проблему в различных ситуациях.
И лучший рецепт для этого - практика. У вас всегда должен быть проект; если вы между оплачиваемых концертов, возьмите личную игрушку. Свободное время на выходные? Пройдите через «Привет мир» для языка или платформы, которые вы никогда не использовали раньше. Ищите способы многому научиться одновременно. Например, создайте что-нибудь в Google App Engine, и вы сразу узнаете о базах данных на Python, BigTable и столбцах. Вы также получите хорошую дозу «профессионального» стиля Google.
Хороший полководец знает, как применить свою выученную тактику и накопленный опыт в различных условиях. Похоже, у вас есть какая-то тактика и опыт, но вам нужно столкнуться с незнакомой местностью. Вероятно, это единственный лучший способ выяснить, что вы знаете и что вам нужно узнать дальше.
И если вам нужен «профессиональный» стиль, возьмите несколько «профессиональных» проектов. Найдите проект с открытым исходным кодом, который вам нравится, назначьте себе изменение и приступайте к нему. Будьте готовы к сомнительным рецензентам, но помните, что большинство людей в этой области не получили того, что они имеют для гладких социальных навыков. Суть в том, чтобы показать себя как можно большему из того, кем вы хотите быть. И вам нужно выстроиться достаточно хорошо, чтобы сделать это самостоятельно. Ни один класс не может научить вас. На самом деле, сегодня происходит слишком много уроков и недостаточно твердой компетенции в реальном мире.
источник
На мой взгляд, нет необходимости беспокоиться о том, что другие подумают о вашем коде, если вы сосредоточитесь на объективных показателях его качества. Это
В качестве первого принципа, ваша цель всегда должна быть сосредоточена на объективных качествах, а не на мнении других. Сосредоточение внимания на мнении других - это путь к посредственности и, как вы испытываете, беспокойство.
Единственная причина заботиться о мнениях других - это способность хорошо интегрироваться с ними (или в рабочей среде). Если вы ставите перед собой задачу улучшить объективные качества своей работы, то вам не нужно бояться реакции других - это просто возможность учиться или, на худой конец, практические детали, с которыми нужно иметь дело. ,
Будьте верны себе !! Продолжайте учиться и наслаждаться тем, что вы делаете.
источник
Ты напоминаешь мне себя после того, как я поступил в колледж, чтобы стать инженером-программистом. Если вы хотите стать программистом, я бы сказал, занять позицию. Вам нужно будет прокомментировать свой код, написать модульные тесты, полностью понять объектно-ориентированный код. Но сейчас у вас нет реальной причины для этого. Пока вы просто работаете над небольшими личными проектами. Где вы не должны отвечать никому, кроме себя. Вы не будете расти дальше как разработчик.
Взяв на себя большие проекты, над которыми много людей работают, и им приходится отвечать на вопросы руководства, такие как «Является ли эта ошибка выпуска бесплатной? Потому что мы собираемся выпустить ее для клиента». Вы будете расти как программист / инженер. Вы получите несколько сильных ударов. Вы можете найти вещи, которые вы упомянули, более ценными, и вы можете найти новые вещи, которые раньше никто не имел. Вы будете расти.
Даже мой колледж не смог научить меня этим вещам, хотя они и пытались.
Для модульного тестирования ищите Test Driven Development.
Для комментирования подумайте о коде, который вы написали после того, как ушли. И время, которое другие люди потратят на его реинжиниринг.
Для объектно-ориентированных языков. Пойми хотя бы это. Это инструмент, который вы можете использовать для решения проблем более читабельным способом.
Удачи: D
источник
Короче говоря, лучший способ узнать , как правило , чтобы болтаться с кем - то вы можете узнать с . Если вы чувствуете, что ваши навыки не на высоте, то лучше всего общаться с людьми, которые лучше вас. Конечно, гораздо лучше, чем уйти и изолировать себя дальше.
Тем не менее, я думаю, что вы рисуете очень упрощенную и вводящую в заблуждение картину. Далеко не все «профессионально обученные» программисты действительно хороши. То, что они что-то делают, не обязательно означает, что это правильно.
И многое (но не все) из того, что вы говорите, действительно звучит так, будто вы тот, кто может научить их трюку или двум.
Это звучит здорово для меня. Лучшие кодеры - те, кто использует правильный инструмент для работы. Я всегда выбирал кого-то, кто знает обе парадигмы, и использует каждую из них там, где это имеет смысл, над тем, кто религиозно использует только одну парадигму.
Опять же, простота это хорошо . Не сделать код сложным , пока он не нуждается , чтобы быть сложным. Некоторые люди действительно имеют тенденцию делать вещи сложные из какой - то ошибочной идеи элегантности, или потому , что «мы будем нуждаться в этом дополнительную функциональность позже». Как правило, лучше сделать простейшую вещь, которая решает вашу проблему.
Что и как следует комментировать, очень субъективно. Здесь нет настоящего «правильного» или «неправильного», но при работе в команде важно писать код, который может понять вся команда, а не только автор кода. И иногда приходится идти на компромиссы, чтобы соответствовать стилю кодирования команды. Это не обязательно означает, что вы должны писать больше комментариев, это просто означает, что это то, что вы и ваша команда должны будете согласовать.
Ну, спроси их. :) Тестирование вашего кода имеет важное значение, и модульные тесты являются популярным и полезным инструментом для этого.
Как и в случае с комментариями, это субъективно и зависит от языка. В C и C ++
lowercase_with_underscoresэто довольно распространенное соглашение об именах. Во многих других языках вы практически никогда не увидите подчеркивания. Но в конце концов, это действительно не важно. Независимо от того, вызывается функцияwrite_to_logили нет,WriteToLogона не будет иметь значения. Кто-то должен будет просто смириться с этим и соответствовать тому, о чем там договорилась команда.Как и в модульных тестах, никогда не прекращайте учиться. Вы работаете вместе с людьми, которые знают вещи, которых вы не знаете, и которые происходят из другого происхождения, чем вы. Учитесь друг у друга. Ясно, что вы можете их научить, но есть вещи, о которых вы не знаете или о которых никогда не слышали, и которым они могут вас научить. Это не значит, что вы (или они) плохой программист. Это означает, что хороший программист - это тот, кто стремится совершенствоваться и учиться у других.
То же самое здесь, и я - то, что вы бы назвали «профессионально обученным» (степень CS). Люди, которых учили программированию, отличаются так же, как и люди, которые самоучки. Похоже, вы работаете с теми, кому действительно нужно выучить несколько новых трюков.
И то и другое. Конечно, страшно, когда другие смотрят (и судят), что ты сделал. Но это также очень познавательно. Они могут сказать вам, что они сделали бы иначе, или почему они сделали бы это иначе. Они могут помочь вам улучшиться, и они могут также чему-то научиться сами. Покажите им код, который решает проблему лучше, чем их «предпочтительное» решение, и, надеюсь, они пойдут «о, это здорово. Как вы узнали, как это сделать? Как вы это называете? Я должен сам использовать эту технику» "
источник
Это не полный ответ, у вас уже есть несколько хороших. Однако есть пара моментов, которые для меня выглядят немного запутанными и не были учтены.
Мне кажется, что вы путаете декларативное и императивное программирование, а не функциональное и объектно-ориентированное программирование. Если вы имеете в виду, что вы склоняетесь к декларативному программированию и избегаете необходимости, то это хорошо. Декларативный стремится устранить побочные эффекты, которые должны сделать ваш код легче для понимания.
Современные языки программирования часто поддерживают декларативную модель программирования. Например, в C # использование Linq приводит к декларативному стилю, потому что вы не говорите, как получить то, что вы хотите; ты говоришь только то, что хочешь.
Современные языки часто являются мультипарадигмальными языками. Редко кто-нибудь использует «чистый» язык. Многие функциональные языки поддерживают объекты и побочные эффекты. Языки, рассматриваемые как объектно-ориентированные, часто не накладывают ограничения на то, что все является объектом.
Что вы подразумеваете под полным ОО? Я никогда не работал над "чистым" ОО-кодом. Возможно, вы можете дать нам более подробную информацию о том, что вам не нравится. Может помочь иллюстрация из проекта с открытым исходным кодом.
OO-программирование дает нам много возможностей для поддержки таких вещей, как абстракция данных, инкапсуляция, обмен сообщениями, модульность, полиморфизм и наследование. Если бы я посмотрел на кодовую базу, которая этим не воспользовалась, это оставило бы во рту неприятный вкус.
источник
Краткий ответ: да.
Учить себя почти все хорошо.
Фильтруйте с хорошим смыслом, хороший совет.
WRT изучает профессиональное программирование, да.
Что у тебя на уме?
Конференции, семинары, сертификация, диплом?
У каждого есть цена / выгода.
Когда рентабельность инвестиций хорошая, если у вас есть ресурсы, сделайте это.
Взвесьте советы по степеням, учитывая источник: у людей с / без них есть личные интересы.
Поговорите с полдюжиной каждого.
Изолирована ли академия от промышленности? Часто.
Степень бесполезна? Долларово трудно спорить.
Выпускники почти всегда зарабатывают больше денег, но следите за кредитами колледжей.
Знание мудрым? Может быть.
Если вы ненавидите школу, вы не получите больше, чем положили.
Если вы чувствуете, что степень - это достойная цель для вас, возможно, это так.
Копайте глубже и узнайте о программе обучения, стоимости, окружающей среде. Убедитесь, что у вас есть интерес, обязательства, время и ресурсы. Вы, вероятно, ходили в школу тринадцать лет, так что еще четыре? Они будут самыми дорогими, и основной человек, на которого вы положитесь, чтобы сделать их самыми ценными, - это вы.
Затраты могут быть довольно страшными, но они рассказывают только часть истории, потому что есть много грантов и стипендий за заслуги, нужды и сто других причин.
Если вы идете, выберите умных профи и бутонов.
источник
Второй вопрос - могу ли я использовать свой собственный стиль?
У вас есть два вопроса.
Первый в вашем названии. Пожалуйста, смотрите мой предыдущий ответ.
Второй подробно описан примерно в пяти параграфах, где вы характеризуете, как ваш стиль отличается от профессионального стиля с пунктами, перечисленными ниже:
Подводя итог, я думаю, вы спрашиваете, нормально ли, что вы используете подход Фрэнка Синатры - «Я сделал это по-своему». Я чувствую амбивалентность, когда вы называете кодекс других людей профессиональным, но вы не согласны с этим. Стиль - важная личная проблема, и споры о том, что такое хороший код, бесконечны и часто являются пустой тратой времени. Некоторые проблемы могут быть проще, если ваша группа использует письменное соглашение о кодировании. Пожалуйста, проверьте:
http://en.wikipedia.org/wiki/Coding_conventions
Существует этикет для убийства чужого кода, и это еще одна вещь, над которой вы должны работать с вашей командой. Наденьте свою толстую кожу и надейтесь, что они не слишком жестоки, но что бы вы ни делали, не вступайте в войну.
Вы прокомментировали беспокойство по поводу того, что другие видят ваш код. Будьте готовы, потому что они не только увидят это, но и перепишут, и расскажут вам, что не так с вашим стилем. Ваши коллеги могут быть гибкими или жесткими. В любом случае, я рекомендую вам не переписывать их код для стиля и не ставить каждую точку стиля на согласование.
Причины для того, чтобы иметь унифицированный код (и унифицированное обучение), заключаются в том, чтобы увеличить скорость и продуктивность разработки и в некотором роде институционализировать изучение лучших практик. Такие проблемы, как camelCase или use_underbars, могут показаться тривиальными и мелкими, но есть преимущества для согласованности.
Пожалуйста, будьте готовы к модульному тестированию и разработке через тестирование. Когда вы одни, а не участвуете в платных проектах, это больше похоже на хобби. Ваши вещи не должны совпадать с тем, что делают другие люди. Если ваш код не работает, ничего страшного. Но когда вы участвуете в команде, код, который вы пишете, может влиять на всю команду, особенно если он попадает к клиентам.
Точно так же, если ваша команда использует MVC, пожалуйста, узнайте об этом, надеюсь, из тех же источников, на которые они ссылаются. Методы структурирования программ могут иметь огромное значение, как было показано экспериментом. Снова, возьмите пример и лидерство от своей команды.
Если ваша команда использует backbone.js, вы тоже его используете. Ваша команда - как утки, летящие в строю. Объединение в ряд помогает им расходовать меньше энергии, делает их более безопасными и помогает им добиваться того, что они делают более эффективно. Аналогия рушится, если вы сильно ее настаиваете, но есть большие преимущества в использовании общих инструментов, методов и согласованности решений команд.
источник
Приведенный совет весьма полезен, но я стараюсь помнить, что моей основной целью является создание «рабочего программного обеспечения», которое будет полезно для моих пользователей. Моя аудитория обычно НЕ группа программистов - это деловые люди, которые готовы платить деньги за автоматизированное решение (пользователям нет дела до ОО-методологий, фреймворков, модульных тестов, комментариев к коду и т. Д. одержим.)
Я нашел идеалы Agile Manifesto полезными в моей карьере (www.agilemanifesto.org)
источник
Я полностью отношусь к этому вопросу. У меня точно такие же чувства и очень похожий фон (но не точно такой же). Я должен быть обучен профессионально (или, скорее, академически), поэтому я должен знать о ОО программировании и т. Д. Программирование не было моей основной темой, но я это сделал. Я изучал ОО на некоторых своих курсах и вообще не понимал причину этого. Фактически, единственный раз, когда я понял ОО, был, когда я делал коммерческую работу и был принужден к ней двумя великими наставниками.
Я уверен, что мой профессор был в равной степени блестящим, но вы видите реальную выгоду на практике в коммерческой среде по сравнению с функциональным программированием, но у вас нет шансов увидеть его в курсе, который предназначен для запуска, обучения и окончания в течение нескольких месяцев. , У меня не было возможности поработать над структурой, основанной на MVC, но я уверен, что она будет такой же, то есть я смогу подобрать концепции, работающие из книги, но я пойму ее преимущества, когда увижу ее в использовании в коммерческая среда. И я полностью согласен с вами, зачем использовать OO, MVC и любую другую сложную структуру, если вы можете решить проблему более простым способом. Мой совет: не стесняйтесь работать, потому что это подвергнет вас другой ситуации и позволит вам понять одни и те же вещи в другом свете.
Конечно, я изучил синтаксис и понятия в моем академическом прошлом, но именно в коммерческом мире я начал учиться программировать.
источник