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

86

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

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

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

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

новичок
источник
51
«Но, похоже, я не гениальный программист, как в кино» . Ваша ошибка - верить тому, что вы видите в фильмах о разработчиках программного обеспечения, хакерах и обо всем, что связано с технологиями реального мира.
Стивен С
160
Поздравляем! На сегодняшний день вы официально настоящий программист! Говорить, что ты ужасен, - одна из самых важных ступеней в этой профессии. Я не могу преуменьшить это: каждому профессиональному программисту сказали, что то, что они написали, было ужасно в тот или иной момент, и это как-то жалит, когда вы новичок в этом, но это правда, и вы услышите это еще много раз в курсе вашей карьеры! Давай, ты только что присоединился к профессии. Хорошие программисты берут эти уколы и учатся не совершать одних и тех же ошибок (вместо этого они каждый раз делают разные!)
Джимми Хоффа
15
@newbie, когда вы новичок, и вы создали немного эго и недостаточно облажались, чтобы понять, что вы плохие, я плохой, мы все плохие в этом, потому что это действительно сложно. Если у вас осталось какое-то эго, оно уйдет на второй план после того, как вы совершите больше ошибок. Серьезно, поднимите руку, если вы профессиональный инженер и случайно сдули базу данных, прежде чем поднять руку
Джимми Хоффа
14
Разочарованный? Какого черта вы будете разочарованы? Мой бывший технический директор назвал меня в статье, которую он написал (он не назвал меня конкретно, но все в нашей команде знали, о ком он говорит), и при первой же возможности я процитировал статью в одном из моих ответов здесь . Также я злой разработчик, описанный в этом вопросе . Я призвал ОП опубликовать вопрос, и я даже ответил на него;)
Яннис
19
Помните, люди, только потому, что кто-то сказал, что код был плохим, не делает это правдой. Услышав «ваш код - беспорядок», ОП заслуживает «и вот почему». Затем анализ может начаться.
Тони Эннис

Ответы:

175

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

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

оборота onlineapplab.com
источник
27
Вы правы! Я смеюсь над своим кодом 2 года назад. Так что, думаю, я тоже буду смеяться над моим кодом через два года. Я просто стал немного эмоциональным об этом. Во всяком случае, я постараюсь стать лучше.
новичок
5
@newbie: Ну вот. Это то, что вам действительно нужно знать. Мой девиз: «Я никогда не был так хорош, как через два года», вот уже более десяти лет. И я еще не ошиблась. Я не научился этому намного дальше в моей карьере, чем ты. Ваш коллега оказал вам большую услугу.
PDR
27
Я думаю, что шесть месяцев должно быть достаточно времени, чтобы ненавидеть ваш код. Я волнуюсь, что когда-нибудь я смогу найти код, который я написал шесть месяцев назад, и не найду того, что я ненавижу в этом. Это был бы признак того, что я не вырос как программист.
zzzzBov
37
2 года! Я могу смеяться днем ​​над кодом, который я написал утром.
dan_waterworth
9
Я также сказал бы, что проверки кода являются невероятно полезными процессами. Как говорится в этом ответе, если вы вообще хороший программист, со временем вы тоже подумаете, что это ужасный код - это естественно. Я бы также сказал, что ваш рецензент кода не подходит к процессу рецензирования должным образом. Предполагается, что это будет процесс конструктивной критики, в котором передаются знания, а не отрицательный процесс наказания, когда программист, которого проверяют, чувствует себя незначительным. Это сводит на нет много хорошего, что может прийти из обзора.
Mattygabe
68

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

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

btilly
источник
хорошая статья :) так что я просто имею дело с моим эго.
новичок
2
@newbie Точно. Когда вы получаете критику вашего кода, он может расстроить вас, только если ваше эго связано с качеством этого кода. Отделите свое эго от кода, и проблема исчезнет.
btilly
5
Я согласен гордиться тем, как хорошо вы учитесь, но вы также должны гордиться тем, как вы кодируете. Если вы не гордитесь тем, как кодируете, вы не станете лучше.
Брайан Оукли
1
И вы также должны быть осторожны с гордостью за обучение, так как это может привести к тем же проблемам, если вы на самом деле не так хороши в обучении.
Нико Бернс
Я думал, что гордость была одним из 7 смертных грехов? Что со всеми, кто рекомендует это в наши дни? Как насчет того, чтобы просто чувствовать, что ты хорошо поработал?
40

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

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

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

Максимус Минимус
источник
2
Стремление к «выполнению работы» - к посредственности. Вы правы, это работает и может быть эффективным - просто посмотрите на китайские продукты. Но стремление сделать что-то великое - это то, что делает 20 лет программирования стоящим в то время как друг. Оглядываясь назад на 20 лет, что это показывает - выполнение работы или выполнение работы с гордостью?
кингданго
9
Это всегда о «выполнении работы», если вы не пишете какой-то странный арт-проект на основе кода. Написание «хорошего кода» против «посредственного кода» - это компромисс между выполнением немедленной задачи и повышением удобства сопровождения кода для выполнения работы в будущем. Игнорирование этого ведет к перфекционизму, который приводит к тому, что ничего не делается. Посредственный код, написанный быстро, лучше, чем хороший код, написанный медленно для одноразового скрипта.
Gort the Robot
8
Подобно денежным долгам, технический долг скоро возрастает, и изучение того, как управлять техническим долгом, является одним из основных навыков программиста в реальном мире. Любой, у кого достаточно времени, чтобы каждый раз совершать совершенную работу , либо невероятно хорош, либо серьезно отработан, либо обманывает себя.
Марк Бут
1
Достигнуть правильного баланса может быть трудно, особенно потому, что эффект от посредственного дизайна часто намного более заметен, чем эффект от слишком большого количества времени, затрачиваемого на доработку дизайна, когда посредственный проект оказался бы вполне адекватным в течение его полезного срока службы.
суперкат
1
Это действительно огорчает меня, потому что «выполнение работы» и «техническое совершенство» не обязательно должны быть отдельными мирами, которые вы изображаете. Лично я не испытываю особого удовлетворения от того, что мой кусок кода, который был выпущен, является полностью неуклюжим и таким образом из-за нехватки времени и, как вы выразились, чтобы «выполнить работу» ,
crmpicco
39

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

Есть:

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

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

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

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

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

оборота ZJR
источник
3
Буквально хохочу. настолько хорошо. roflcopters
кингданго
1
AMD64 и x86 не принуждаются силой вашей прозы. - просто восхитительно.
Сэм Бринк
+1 за прохождение урока по SQL
HLGEM
28

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

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

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

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

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

Kryptic
источник
26

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

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

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

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

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

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

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

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

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

сойка
источник
2
+1 для того, чтобы соединить это воедино и reviews you provideпотому, что критическое отношение к другим может быть важной практикой, помогая лучше критиковать свой собственный код и получать лучшее качество.
Джимми Хоффа
2
«90% программистов в фильмах настолько фальшивые, что у меня слезы к концу последовательности». 90%? Какие фильмы вы смотрите? : П.И. не видел ни одного фильма, который точно показывает, что мы делаем. А потом были «Рыба-меч» и «День независимости» ...
Ник Бугалис
Хорошо изложено и кратко так!
кингданго
16

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

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

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

Павел
источник
9
« Всегда найдется кто-то, кто не знает чего-то, что вы делаете, и всегда найдется кто-то, кто знает что-то, чего вы не знаете » - потрясающе; +1.
Максимус Минимус
Да, и я хочу узнать все, что я могу
новичок
@ MH: Я бы добавил, что мудрый человек, как правило, узнает гораздо больше из неправильности, чем из правоты. Это не значит, что нужно пытаться ошибаться в вещах, но не следует расстраиваться из-за этого, если кто-то воспользуется возможностью учиться.
суперкат
10

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

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

  • Аргумент против этого (если, конечно, у вас есть на то веские основания)
  • Почувствуйте себя очень счастливым, потому что вы только что узнали что-то новое, и ваш будущий код обязательно будет более крутым, поскольку теперь вы знаете, как сделать его менее беспорядочным благодаря их советам.
Омега
источник
Он не стал комментировать :( Но вот мой код -> codereview.stackexchange.com/questions/18719/…
новичок
почему вы думаете, что это грязно?
новичок
7
@newbie: Тогда этот рецензент не очень хорош. Как кодер должен что-то улучшать, не зная, в чем проблема (даже не догадываясь!)?
Омега
1
Хорошо, спасибо ... Я тоже не программист jquery. Я программист Java ....
новичок
1
В этот раз ему доступен только мой код. В любом случае, вы правы, я попрошу более подробную информацию об этом. Спасибо :)
новичок
8

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

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

Эдди Б
источник
5

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

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

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

Майкл Шоу
источник
4

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

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

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

Эрик Реппен
источник
Аминь. И знание твоих вещей требует ... ну ... усилий, чтобы ты знал свои вещи. Но обязательно наденьте свой воротник, это то, что делают все элитные дети в эти дни. : /
кингданго
Да, я думаю, что я просто дал совет где-то еще, чтобы более опытные разработчики первыми признали, что они не правы. Я могу рисковать несколькими личностями.
Эрик Реппен
4

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

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

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

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

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

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

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

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

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

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

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

Fortyrunner
источник
3

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

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

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

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

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

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

Дима
источник
3

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

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

Прошлый:

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

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

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

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

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

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

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

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

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

Matt
источник
3

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

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

How to be better? 

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

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

Авинаш Кумар
источник
3

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

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

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

Tony Ennis
источник
Иногда чувства могут быть трудными, но я надеюсь, что буду реагировать именно так.
Томас Падрон-Маккарти
3

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

Структура

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

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

Стиль

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

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

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

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

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

Стивен
источник
3

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

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

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

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

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

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

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

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

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

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

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

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

Rarst
источник
1

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

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

Хишам
источник
0

TL; DR

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


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

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

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

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

skopp
источник