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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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