Мой предложенный дизайн обычно хуже, чем у моего коллеги - как мне стать лучше? [закрыто]

69

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

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

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

Пожалуйста, просветите меня. Я буду очень признателен за вашу помощь.

user151193
источник
9
@Oded: Я думаю, что точка зрения OP заключается в том, что у них столько же лет опыта, что и у сотрудника, но сотрудник разрабатывает более качественные проекты, и OP хотел бы знать, как стать лучше, чтобы они хорошо, как сотрудник. Я думаю ...
FrustratedWithFormsDesigner
34
@Oded: Да, он не должен ожидать, что он станет мастером, не потратив 10 лет, но, с другой стороны, эти 10 лет не принесут ему много пользы, если у него нет источника, чтобы учиться у него. , Он пытается немного подрасти здесь; давайте не отговаривать его, пожалуйста?
Мейсон Уилер
6
Вы узнали что-нибудь из другого дизайна? Можете ли вы применить его в других ситуациях кодирования, которые у вас были? Смирись и узнай как можно больше у своего коллеги. Предлагаем обед.
Джефф
17
Я бы остался вокруг. Если вы можете учиться у коллеги, то сделайте это. Не позволяйте эго мешать возможности - что делать, если вы идете дальше и в конечном итоге работаете с парнями, которым нечему вас учить. У меня более 25 лет опыта, но я с радостью принимаю (и делаю свою долю в том, чтобы давать) конструктивную критику от программиста с 3. Я работаю с парнем, который лучше в его худший день, чем я в моих лучших, в результате обоих Эти люди, я лучший программист, чем 2 года назад.
Mattnz
7
Факт жизни заключается в том, что вы всегда найдете других, которые лучше вас. Не позволяйте этому тревожить вас, просто попробуйте все, что в ваших силах, чтобы стать лучше.
maple_shaft

Ответы:

69

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

У вас есть две действительно большие (и удивительно необычные) сильные стороны:

  • Вы способны объективно оценивать свои проекты по отношению к другим
  • У вас есть желание и усилия, чтобы сделать ваши проекты оптимальными

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

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

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

Изменить:
«Еще один совет, после того, как вы разберетесь с принципами и немного попрактикуетесь в их применении, я думаю, что здесь есть еще одна жемчужина из другого вопроса, говорящего о ценности изучения различных языков, которые имеют разные цели и правила:

В идеале каждый программист должен знать язык каждого класса. Что вы могли бы узнать:

  1. Основной язык ООП со статической типизацией: Java, C # (в основном используется в корпоративном программном обеспечении) и C ++ (системное программирование и сложные настольные приложения)
  2. Язык ООП на основе прототипа: Javascript (веб-программирование на стороне клиента)
  3. Процедурный язык: C (встроенное программное обеспечение и системное программирование)
  4. Функциональный язык: Haskell, ML или Lisp (функциональные языки хороши для высокопараллельного программного обеспечения).

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

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

Джимми Хоффа
источник
2
+1 Если кто-то может понять, почему , они на пути к великолепному дизайну (особенно если у них всего несколько лет опыта).
Даниэль Б
22
  1. Это совершенно нормально для нескольких людей, чтобы придумать дизайн разного качества. В прошлом меня приглашали судить конкурсы по разработке программного обеспечения, поэтому я воочию наблюдал за этим: даже самые простые разработки приводили к решениям совершенно разного качества, и все они были сделаны умными и опытными людьми.
  2. Чтение исходного кода является слишком низким уровнем, чтобы помочь вам улучшить свои навыки проектирования: код обращается к сложности на более низком уровне, чем общий дизайн.

Лучший способ улучшить разработку программного обеспечения - это разработка программного обеспечения * . Один из способов сделать это - посмотреть на конкурсы дизайнеров: TopCoder имеет архив из 100+ проектов компонентов, в комплекте с документацией по дизайну UML и реализациями на Java и / или C #. Подберите готовый компонент, который вам нравится, прочитайте спецификацию требований и попробуйте придумать оригинальный дизайн для удовлетворения требований. Потратьте час или два на размышления о проблеме и нарисуйте диаграмму классов, затем откройте выигрышный дизайн и прочитайте, что сделал автор. Сравните его дизайн с вашим, найдите различия и посмотрите, будет ли ваш дизайн лучше. Проверьте оценочную карту соревнования, чтобы увидеть, как судьи оценили дизайн. Это даст вам обратную связь, что вам нужно решить, как улучшить свои дизайнерские навыки.


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

dasblinkenlight
источник
1
Спасибо за то, что обратили внимание на TopCoder, интересная идея использовать его в качестве учебного пособия.
неонтапир
Не могли бы вы, пожалуйста, очень любезно предоставить ссылку на архив TopCoder archive of 100+ component designs,. Не могу найти такие файлы.
стартап
1
@ StepUp Вот оно . Вам может потребоваться войти для доступа к нему.
dasblinkenlight
Если я хочу увидеть красивый дизайн ASP.NET, где я должен увидеть? Я просто вижу "Найти компоненты" по предоставленной вами ссылке.
стартап
1
@StepUp ASP.NET слишком общий. Компоненты TopCoder более специфичны: анализатор SQL, оценщик выражений и т. Д.
dasblinkenlight,
11

Ну, не бросай свою работу. Лучше работать с кем-то, кто обладает лучшими навыками, чем вы, чтобы вы могли учиться у него или нее.

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

Чтобы улучшить дизайнерские навыки, лучше всего создавать проекты, а затем быть жестоким с самим собой, оценивая их и определяя, как их можно улучшить. Задайте себе такие вопросы, как: будет ли он работать и соответствует ли он требованиям во всех аспектах, можно ли его обслуживать, как я смогу это проверить, вызовет ли это проблемы с производительностью, насколько вероятно изменение требования и насколько хорошо будет проект быть в состоянии справиться с изменениями. Прочитайте о шаблонах дизайна, а затем попробуйте применить их к своим проектам. Рефакторинг безжалостно после создания первоначального проекта. Если вы разрабатываете базу данных вместе с приложением, много читаете о нормализации и настройке производительности БД, вы многое узнаете о дизайне базы данных, если узнаете, как заставить базу данных работать наиболее эффективно и результативно. Для приложений подумайте о принципах СУХОЙ и ТВЕРДЫЙ при выполнении вашего дизайна. Читайте об антипаттернах, чтобы знать, что следует избегать.

HLGEM
источник
3

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

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

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

Вы получите идеи о различных принципах дизайна из следующих источников: http://www.cs.wustl.edu/~schmidt/PDF/design-principles4.pdf Дизайн программного обеспечения в Википедии Google "Принципы проектирования программного обеспечения"

  • Понимать различные модели для проектирования программного обеспечения, такие как объектно-ориентированный дизайн или функциональный дизайн или проект структурированного анализа. Это могут быть совершенно разные подходы к решению задачи проектирования, и у каждого из них есть области, в которых они превосходят себя. Изучите их как инструменты для вашей панели инструментов. http://userpages.umbc.edu/~khoo/survey2.html

  • Убедитесь, что вы отделяете проект от реализации, попробуйте представить вещи, которые вы считаете хорошими проектами, чтобы отделить язык и особенности реализации от принципов проектирования более высокого уровня. И развивать свои «дизайнерские глаза» и коммуникативные способности.

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

Повеселись - не делай этого, если тебе не понравится хоть немного!

Линдси Морсилло
источник
2

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

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

Как только вы поймете это, извлеките принципы, лежащие в его основе. Задайте такие вопросы:

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

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

Мейсон Уилер
источник
2

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

Могу поспорить, деньги, что вы можете сделать что-то лучше, чем ваш сотрудник. Не для того, чтобы создать спичку или что-то в этом роде (Вы можете сделать Y лучше? Черт возьми, я могу сделать X лучше!), Но чтобы показать правду, что у каждого есть свои сильные и слабые стороны.

На моей работе работают 4 разработчика. Бывают моменты, когда два главных «программиста» могут создавать вещи, которые просто оставляют меня в пыли. Моя голова кружится, пытаясь обернуть мою голову вокруг их творений.

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

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

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

Сосредоточьтесь на сильных и слабых сторонах себя и своих сотрудников.

WernerCD
источник
1

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

Вы должны учиться у всех.

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

Не позволяйте профессионалу ревностно встать между вами и возможностью учиться.

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

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

    • Роберт К. Мартинг - Agile Принципы, Шаблоны и Практики (есть 2 версии, одна на Java и одна на C #. Неважно, какую вы выберете, идеи и принципы могут быть применены к любому объектно-ориентированному - и не только - исходный код)
    • Кроме того, у Роберта Мартинга есть 2 другие интересные книги: «Чистый код» и «Чистый кодер».
    • Даже если Мартин расскажет обо всех моделях современного дизайна в своей первой книге, вам нужно поискать оригинальную книгу «Банды четырех».
    • Наконец, есть и другие книги, которые сегодня высоко ценятся: «Растущее объектно-ориентированное программное обеспечение на основе тестов» или «Рефакторинг» М. Фезерса (я думаю) или «Написание сценариев эффективного использования» А. Кокберна и еще несколько, которые вы обнаружите в пути.

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

Паткос Чаба
источник
0

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

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

Короче говоря, «многолетний опыт» не всегда эквивалентен. Сделай так, чтобы твои годы чего-то стоили.

Филипп
источник
0

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

hotpaw2
источник