Как бы вы отреагировали, если бы кто-то сказал вам, что ваш код - беспорядок?

Я хороший программист, или я так думал раньше. Я всегда люблю программировать. И я хочу узнать много нового о программировании, чтобы сделать меня лучшим программистом. Я изучал программирование в течение 1 года, а сейчас я работаю программистом почти 2 года. Короче говоря, у меня почти 3 года опыта программирования.

Наша команда состоит из 5 программистов, 4 из нас новички, 1 имеет опыт работы более 3 лет. Мы работаем над программой уже почти год, и никто никогда не просматривал мой код, и мне дали страницу для работы. У нас никогда не было обзора кода, и мы все новички, поэтому мы не знаем, как выглядит чистый код. Я думаю, что программисты учатся самостоятельно?

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

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

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

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

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

Прочитайте http://www.perlmonks.org/?node_id=270083, если вы не знаете, о чем я говорю.

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

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

Отказ от ответственности: ничего из этого не следует читать как «плохой код в порядке».

Код каждого - беспорядок, и хороших программистов нет.

Есть:

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

Они вряд ли, если вообще когда-либо, в конечном итоге будут одним и тем же человеком.

И есть программисты, которые должны расти и:

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

Это не искусство, это ремесло.
Мы считаем само собой разумеющимся, что вы умны: вы программируете компьютеры, черт возьми.
Тем не менее AMD64и x86не вынуждает сила вашей прозы. Держите вещи простыми.

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

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

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

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

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

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

Это хорошо. Это намного лучше, чем иметь такую ​​реакцию, как «мой рецензент понятия не имеет, о чем он говорит», «мой рецензент слишком разборчив» или просто «мой рецензент не любит меня» и игнорировать их. Это отношение хорошо.

Но, похоже, я не гениальный программист, как в кино.

Не уверен, какие фильмы вы смотрите, но 90% программистов в фильмах настолько фальшивые, что у меня слезы к концу эпизода.

Можете ли вы дать мне совет, как стать лучше?

Читать и практиковаться. Проверьте книги, такие как Code Complete или The Pragmatic Programmer . Поищите на Амазоне похожие книги.

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

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

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

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

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

Как и в любой области, есть те, кого считают экспертами. Если бы этих людей не было, у нас не было бы чему поучиться. Предполагая, что этот человек действительно эксперт, я бы послушал, что он говорит, и спросил, что он посоветует вам сделать, чтобы улучшить свой код. Никогда не забывайте, однако, что он не единственный, кто может оказать свою помощь; нам повезло, что существует множество таких ресурсов, как SE / SO.

Беспорядок довольно субъективен. Лучшее, что вы можете сделать, это спросить этого человека (или отчет о проверке): почему это грязно? (с их точки зрения, то есть)

Они обязательно ответят вам, и вы сможете:

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

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

Our team is composed of 5 programmers, and 4 of us are new

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

Чтобы быстро ознакомиться с некоторыми довольно стандартными правилами кодирования, Стандарты участников сообщества Linux должны дать вам представление об уровне ответственности, к которому следует стремиться в отношении вашего продукта. Обратитесь к ПОЛУЧЕНИЮ КОДА ПРАВА.

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

«Если рецензентов достаточно, все проблемы легко решить».

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

I feel so sad and hurt. 

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

Вы ответили на свою проблему ... Вы не тестируете!

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

В этом заключается The Rub

«Мы развернули нашу программу в программе без тщательного тестирования».

Cribbing UML Creator Грэди Буч ...

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

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

Одним из наиболее важных аспектов программирования {и жизни} является знание ваших сильных и слабых сторон. Если вы не работаете над своими слабостями, у вас не будет всестороннего набора навыков.

Outro ... У тебя все хорошо - Только не скули. Двигайтесь вперед в развитии своего ремесла и позвольте своей страсти к программированию поддерживать вас. Удачи :-)

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

Они также не должны просто сказать «Ewwww» и оставить все как есть. Всегда есть причина, почему что-то не так в программировании. Например, неправильно оставлять много закомментированного кода повсеместно, но это неправильно, потому что он загромождает код и затрудняет его чтение, а не потому, что кто-то так сказал в книге.

Ваш код не вы. Помни это.

Я собираюсь быть членом здесь и советовать на основании ... ну, очевидное. Очевидно, ваш код - беспорядок, или вопрос, который вы задаете: «ПОЧЕМУ кто-то говорит, что мой код - беспорядок?» Но вы не оспариваете предположение. Ты просто ведешь себя обиженно и, откровенно говоря, там может плакать, но нет никакого чувства, когда дело доходит до оправдания программирования.

Но на самом деле, почему ты спрашиваешь? Вы знаете, что ваш код отстой, или вы задали бы другой вопрос. Если бы кто-нибудь сказал мне, что мой внутренний веб-код вонял, я бы посмеялся и сказал: «Хорошо, что с ним?» Если бы они сказали мне мой вонючий JavaScript, я бы дал социальному программисту эквивалент толстой губы, и я бы никогда не попросил совета о том, как реагировать, потому что маленькие сучки явно ошибаются!

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

Помните это: худший код, который вы когда-либо увидите, ваш собственный!

Джефф Этвуд из codinghorror.com много писал об этой теме, вы можете начать здесь: http://www.codinghorror.com/blog/2009/07/nobody-hates-software-more-than-software-developers.html

Если вы хотите улучшить, начните читать материал о стиле кодирования, шаблонах, рабочих процессах, в основном обо всем, на что вы способны. Также изучите больше языков программирования, посмотрите, как они работают. Если вы делаете ООП, прочитайте это: http://en.wikipedia.org/wiki/Design_Patterns

Также поговорите с другими программистами и сделайте парное программирование или посмотрите другой код.

Делать ошибки неизбежно, повторять их есть.

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

Скорее всего, они заботятся о своей профессии, они заботятся о своей работе, они заботятся о своей команде, и они заботятся о вас.

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

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

Попробуйте посмотреть код, который вы написали в начале своей карьеры. Как это выглядит для вас сейчас? Выглядит ли это так же хорошо, как вы думали, когда написали это;)

Прежде всего, вы должны понимать, что программирование - это итеративный процесс, очень похожий на написание статьи или книги. Сначала вы пишете «черновик» вашей программы, чтобы заставить ее работать. На этом этапе ваш код будет беспорядок. Таким образом, вы рефакторинг, чтобы сделать код чистым. Затем вы профилируете и видите, что вам нужно оптимизировать, чтобы сделать это быстро. Хитрость заключается в постоянном рефакторинге, иначе беспорядок будет расти. Вы должны регулярно чистить свой код, так же, как вы должны убирать свой дом.

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

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

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

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

Наконец, я настоятельно рекомендую прочитать «Чистый код» Роберта С. Мартина. Он расскажет вам, почему ваш код беспорядок, и что вы можете сделать, чтобы его убрать.

Можете ли вы дать мне совет, как стать лучше?

Ответ Джея, который рекомендует книги, хороший, однако, похоже, вы уже на поворотном этапе на работе.

Прошлый:

Наша команда состоит из 5 программистов, 4 из нас новички, 1 имеет опыт работы более 3 лет. Мы работаем над программой уже почти год, и никто никогда не просматривал мой код, и мне дали страницу для работы.

Настоящее время:

Теперь это жестко, и нам нужно одобрение и проверка кода, прежде чем мы будем вносить изменения в код.

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

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

На базовой линии это будет быстрый обзор с результатом, "да выглядит хорошо". Приложив немного более целенаправленных усилий, вы сможете отбросить идеи друг от друга: «Да, это работает, но вы могли бы подойти к этому таким образом, что сделало бы вашу цель более ясной ...». Делайте заметки на будущее, даже если код считается правильным для развертывания.

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

Это изменение культуры, которое вы сами не можете форсировать, но вы можете помочь подтолкнуть вещи в правильном направлении!

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

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

Ответ на это можно найти в новых генерирующих компаниях. Я был в таких компаниях, как Google и FaceBook, и вижу, что если вы будете неукоснительно следовать процессу Agile / Scrum, то вы сможете писать более качественный код и улучшать его каждый спринт.

How to be better? 

Ответ - постоянный рефакторинг. В современных инструментах разработки, таких как visual studio, есть множество инструментов, которые помогут вам в этом процессе. Если вы следуете процессу разработки программного обеспечения Scrum, то, например, вы написали плохой код в цикле спринта 1, и кто-то указал во время проверки, что он плохой, тогда в спринте 2 у вас есть возможность реорганизовать код.

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

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

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

Можете ли вы привести конкретные примеры того, что называется "беспорядок"?

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

Структура

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

Это типы ошибок, которые предназначены для выявления, инструментов тестирования и подобных продуктов. Они четко определены, и вы или ваши инструменты можете принимать объективные решения относительно их достоверности / правильности.

Стиль

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

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

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

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

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

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

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

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

Я думаю, что обработка негативных отзывов состоит из двух частей.

1. Определите характер поднятого вопроса (-ов) и что вы должны извлечь из него

Когда я проверяю или проверяю свой код, я сортирую информацию о проблемах кода примерно в таких сегментах:

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

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

2. Определите, какие (если таковые имеются) изменения в коде будут сделаны в результате проверки

После обработки информации принимается решение о ее действии и необходимости изменения кода. Это не обязательно ваше решение, ваше мнение может иметь или не иметь значения в зависимости от участвующих сторон и специфики вашей ситуации (стаж работы и т. Д.). Но возможные результаты примерно таковы:

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

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

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

Я прошел через эту ситуацию, и я могу понять.

TL; DR

Как бы вы отреагировали, если бы кто-то сказал вам, что ваш код - беспорядок?

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

• Старый добрый экспертный обзор. Попросите разные команды с разным коллективным мышлением, уровнями опыта и / или уровнями агрессивности пересмотреть ваш код.
• Просто чтобы немного прояснить, что я имею в виду под «разными» группами сверстников: диаспора StackExchange, вероятно, самая известная, профессиональная и уважаемая группа из-за относительной трудности становления ее частью по сравнению, скажем, с Reddit. Reddit имеет тенденцию быть очень агрессивным в более популярных sub-reddits - но как ни странно, subreddits программирования довольно дружелюбны (из того, что я испытал).

Хороший, пожалуй, лучший пример агрессивного, гангстерского типа клик-менталитета - это толпа форумов XDK и худший из худших трофеев, которые я вручаю CyanogenMod для форумов Android / народного канала IRC.

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