Я могу написать код ... но не могу хорошо спроектировать. Какие-либо предложения? [закрыто]

83

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

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

Именно здесь я считаю, что даже такие проекты, как topcoder / project euler, также не окажут особой помощи, они могут обострить вашу способность решать математические задачи - но вы можете стать академическим программистом; кто-то, кто больше интересуется красивыми, чистыми вещами, кто совершенно не заинтересован в повседневных повседневных вещах, с которыми сталкивается большинство разработчиков приложений.

Итак, мой вопрос: как мне улучшить свои дизайнерские навыки? То есть умение проектировать малые / средние приложения, которые уйдут в несколько тысяч строк кода? Как я могу получить навыки дизайна, которые помогут мне создать лучший редактор html или какую-нибудь графическую программу, например gimp?

design skills

— user396089
источник

1

«давайте признаем тот факт, что большинство приложений, созданных в школе, обычно имеют длину около 1000-2000 строк, что означает, что это в основном академическое упражнение, которое не отражает сложности программного обеспечения реального мира»: там, где я преподавал, у нас было два Семестровый программный проект, в котором команда из десяти студентов разработала довольно сложное приложение за период от 6 до 8 месяцев. Кроме того, многие компании (по крайней мере, в Германии) предлагают короткие контракты для студентов, которые хотят получить некоторую практику, прежде чем они закончат свое обучение.

— Джорджио

Дубликат моего предложенного дизайна обычно хуже, чем у моего коллеги - как мне стать лучше? и Как стать хорошим в объектно-ориентированном анализе и дизайне (OOAD)?

— комнат

87

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

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

Определите хорошего наставника . Нет ничего лучше, чем возможность поговорить о ваших проблемах с кем-то, кто уже заплатил их взносы. Руководство - это отличный способ помочь в ускоренном обучении.
Прочитайте , прочитайте еще немного, попрактикуйтесь в том, что вы читали, и повторяйте всю свою жизнь. Я занимаюсь этим более 20 лет и каждый день получаю удовольствие от изучения чего-то нового. Узнайте не только о первоначальном дизайне, но и о новом дизайне, тестировании, лучших практиках, процессах и методологиях. Все они в разной степени влияют на то, как ваши проекты будут выглядеть, принимать форму и, что более важно, как они сохраняются со временем.
Найдите время, чтобы повозиться . Либо принимайте участие в проекте скунса на вашем рабочем месте, либо попрактикуйтесь в свободное время. Это идет рука об руку с вашим чтением, применяя ваши новые знания на практике и наблюдая, как такие вещи будут работать. Это также материал для хорошей дискуссии с вашим наставником.
Занимайтесь чем-то техническим вне вашего рабочего места. Это может быть проект или форум. Что-то, что позволит вам проверить свои теории и идеи за пределами вашего непосредственного круга сверстников, чтобы сохранить свежий взгляд на вещи.
Будьте терпеливы . Признайте, что опыт заработка требует времени, и учитесь признавать, что вам нужно ненадолго отступить, чтобы понять, почему и где вы потерпели неудачу.
Веди дневник или блог о своих задачах, своих мыслях, своих неудачах и своих успехах. Это не является строго необходимым, однако я обнаружил, что для вас может быть очень полезно увидеть, как вы развивались с течением времени, как выросли ваши навыки и изменились ваши мысли. Я возвращаюсь в свои собственные журналы каждые несколько месяцев и смотрю на материал, который я написал 4-5 лет назад. Это действительно откровение, открывающее, как много я узнал за это время. Это также напоминание о том, что время от времени я ошибаюсь. Это здоровое напоминание, которое помогает мне улучшиться.

— S.Robins
источник

45

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

— Мерт Акчакая

2

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

— вс

1

@vski Есть много концепций, которые я мог бы включить, но вопрос в том, будут ли эти концепции сами по себе разумным путем зарабатывать опыт, необходимый для ОП, чтобы он считал себя усовершенствованным дизайнером. В рамках своего ответа я вижу рефакторинг как практику (согласно моему второму пункту). Так же практикуется Чистый код, Test First, BDD и многие другие концепции. Я придерживался подхода, согласно которому необходимо много навыков и опыта, чтобы развиваться до такой степени, что навыки проектирования будут развиваться и расти с накоплением опыта и знаний с течением времени. :)

— С.Робинс

2

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

— Лев

2

«Всегда пытался. Всегда терпел неудачу. Неважно. Попробуй еще раз. Сбой снова. Сбой лучше». --- Сэмюэл Беккет.

— Питер К.

16

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

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

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

Теперь я продолжаю делать новые ошибки и учиться на старых.

— Амадей Хейн
источник

10

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

— Беван

11

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

— Кевин Клайн
источник

2

ИМХО дизайн в эмерджентном дизайне - это прекрасно, но без дисциплины вы рискуете создать «эмерджентные спагетти» Проблема с предварительным дизайном заключается в том, что люди рассматривают его как предложение «все или ничего», что дает плохую репутацию, когда дела идут плохо. Это напоминает мне об одном из Джоэла статей , где он упоминает , что дизайн важен. Что необходимо, так это то, что дизайн достаточно для того, чтобы изменить ситуацию к лучшему, не отнимая у вас ни времени, ни ресурсов, ни вашего шанса увидеть, как красивые поддерживающие конструкции органически появляются через чистый код.

— С.Робинс

@ S.Robins: Я чувствовал, что OP по-прежнему атакует проекты, достаточно маленькие, чтобы их можно было очень хорошо выполнить с помощью TDD и непрерывного рефакторинга. Таким образом, он может изучить дисциплину, необходимую для того, чтобы узнать, сколько дизайна необходимо для более сложных проектов.

— Кевин Клайн

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

— С.Робинс

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

— Джорджио

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

— Джорджио

7

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

См. Например, http://sourcemaking.com/antipatterns/software-development-antipatterns .

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

Будьте супер-скептически настроены по поводу добавления «еще одного маленького хака». Еще один здесь, еще один там, и код становится неосуществимым.

Оцените открытый / закрытый принцип .

Пишем тесты (как в TDD). Они заставляют вас продумывать свой дизайн еще до того, как вы его на самом деле внедрили.

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

— Конрад Моравский
источник

4

Один принцип, который я считаю очень важным для хорошего дизайна, - это декомпозиция: если класс слишком большой (больше, скажем, 300-400 строк кода), разбейте его на более мелкие классы; если метод слишком большой (скажем, более 50 строк кода), разложить его; если проект содержит более 50 классов, разложите его.

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

— Джорджио
источник

1

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

— жер

1

@jer: Это эмпирическое правило, конечно. Метод, вызывающий 100 других методов, - это, как вы говорите, просто соединение вещей (это вызов списка подфункций). Я больше думаю о методах, которые содержат некоторую реальную логику: обычно это плохой знак, если вам приходится многократно прокручивать назад и вперед, чтобы понять, что делает метод. То же самое, если вы посмотрите на определение класса с большим количеством членов (а класс - это не просто большая плоская коллекция свойств).

— Джорджио

«проект содержит более 50 классов, разложите его» несерьезно

— динамично

@ yes123: это должно было дать идею. Это действительно зависит от того, что вы разрабатываете, на каком языке и т. Д.

— Джорджио

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

— Крейг Бовис

0

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

"Лучше"

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

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

И "счастливее"

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

— Стюарт Макли
источник

-1

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

Вы можете найти множество проектов с открытым исходным кодом для исследований.

в любом случае вам нужна практика.

— PCJ
источник

-1

Не живи в страхе

Стремитесь к простоте

Слушайте своих пользователей

Попробуйте много идей

Создай что-то, а потом сделай

Работайте над вещами, которые повышают ценность, оставляйте вещи, которые не

— erturne
источник

-1

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

— Крейг Бовис
источник