Что плохого в творческом кодировании? [закрыто]

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

Сообщество людей здесь и в Stack Overflow, похоже, отвергает любые нюансы несовершенства. Моя цель - написать респектабельный (и, следовательно, поддерживаемый и функциональный) код, улучшая мои навыки. Тем не менее, я творчески кодирую.

Позвольте мне объяснить, что я имею в виду под «творческим кодированием»:

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

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

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

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

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

Я искренне ценю ваш вклад, независимо от того, что вы думаете по этому вопросу.

Изменить: Спасибо всем за ваши ответы. Я чему-то научился у каждого из них. Вы все были самыми полезными.

Нет ничего плохого в code-test-refactor-repeat, просто скажите людям, что вы создаете прототип.

С другой стороны, для более крупных проектов вы обнаружите, что некоторая мысль, придаваемая дизайну заранее, сэкономит вам много времени в цикле «ой-дерьмо-сейчас-что»!

PS: методы построения диаграмм помогают вам выучить навыки визуального мышления, которые ценны, даже если никто, кроме вас, никогда не видел свои диаграммы.

Я всегда предпочитаю понятный, читаемый, простой код любому визуально представленному, кодированному UML-коду, с дизайном по шаблону, где класс / интерфейс включают имена шаблонов, такие как «ItemVisitor» (?!). Шаблоны проектирования, методы ОО и все остальное должны формализовать правила. Эти правила исходят из здравого смысла.

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

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

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

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

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

Кажется, вы:

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

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

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

Кроме того, я не знаю, о каком "профессиональном сообществе развития" вы говорите, но на вашем месте я бы посоветовал им вернуться в свои башни из слоновой кости, чтобы вы могли продолжить свою работу!

Брэд, ты не одинок. Я знаю очень хороших программистов, которые работают точно так же, как вы описываете. :)

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

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

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

Я думаю, что стоит дополнить ответы выше цитатой Алана Дж. Перлиса из предисловия известной книги MIT «Структура и интерпретация компьютерных программ», обычно называемой «SICP»:

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

Есть хороший умный и плохой умный.

Хороший Умный - высокое соотношение между умными строками кода и строками в неумной альтернативе. 20 строк кода, которые спасают вас от написания 20000 - это очень хорошо, умно. Good Clever - это спасение работы.

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

Просто чтобы заметить: Bad Clever почти никогда не называют «Bad Clever»; он часто путешествует под псевдонимами «красивый», «элегантный», «лаконичный» или «лаконичный».

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

Работа, на которой я работаю около 8 месяцев, действительно является моим первым опытом работы в команде разработчиков над одним проектом. До сих пор, буквально вся моя карьера была в качестве программиста-одиночки, которому не приходилось сталкиваться со всем, что связано с командной работой. Даже когда я работал в группе, это всегда была довольно разрозненная работа - у меня был мой проект, который был MINE, или мой раздел, который был MINE, и т. Д. Это была интересная кривая обучения, так как я быстро освоился с действительно совместная командная рабочая среда.

Вот главное, что я понял: если не очевидно, что вы делаете, вы, вероятно, пишете о следующей головной боли коллеги. Большая часть «ориентированной на процессы» суеты, которую вы видите здесь, связана с тем фактом, что многие из нас были коллегами с головной болью. И большая часть теории управления процессами программного обеспечения связана с минимизацией этой головной боли.

Так что такие вещи, как планирование заранее согласованного плана и т. Д. ... Это о наличии команды на борту и в синхронизации. Если вы команда, вы уже синхронизированы с самим собой, и в этом нет необходимости.

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

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

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

Две перспективы:

1. Никто не должен поддерживать живопись.

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

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

Но мне любопытно:

Сообщество людей здесь и в Stack Overflow, похоже, отвергает любые нюансы несовершенства. [..] Мой процесс, кажется, идет вразрез с тем, что является приемлемым в профессиональном сообществе разработчиков, и я хотел бы понять, почему.

Как кто-нибудь в Stack Overflow узнает ваш процесс? И что вы подразумеваете под "отклонить"? Естественно, код, размещенный в сообществе программистов, будет подвергнут критической проверке. Но если кто-то обнаружит области, где ваш код может быть улучшен, это может быть только хорошо, верно?

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

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

Что я делаю очень часто, так это решаю проблему, возможно, с наименьшим возможным кодом, что обычно приводит к явно ненужным зависимостям или другим проблемам проектирования. Затем я преобразовываю рабочий код в красивый код.
Например, я уменьшаю зависимости между различными модулями для создания кратких интерфейсов и задаю вопрос, где данные должны храниться, пока каждый модуль не зависит только от очень минималистичных абстракций других модулей. Можно сказать, я откладываю окончательное решение, какой модуль должен нести ответственность. Я откладываю абстракцию.
Слишком много внимания уделяется разделению проблемы на отдельные обязанности, на различные абстракции, не очень хорошо. Это заставит вас изгибать вашу реализацию в соответствии с созданными вами абстракциями. Код работает, если он дает желаемые результаты и его можно поддерживать. Дизайн работает, если вы можете реализовать его с помощью хорошего кода. Если код не работает, вы меняете его. Ergo, если дизайн не работает, вам также нужно его изменить. Вы можете только увидеть, работает ли дизайн, как только вы его реализовали.

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

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

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

Помимо этого, интересно и весело исследовать границы, чтобы увидеть, что там можно найти. Однажды, работая над Mini на ассемблере, я обнаружил, что вы можете создавать сопрограммы, которые могут переключаться с одной на другую с помощью одной инструкции. Затем я выяснил, как создать самодостаточность, которая могла бы сделать два шага вперед, один шаг назад и т. Д. Было ли это полезно? Я сомневаюсь в этом. Не в этом дело.

Однажды я услышал лекцию Эдсгера Дейкстры о творчестве в программировании. Он упомянул, как студент нашел способ сделать n-битное вращение n + m-битного слова. Это было сделано с 3 битами. Сначала вы меняете n битов, затем меняете m битов, а затем меняете все n + m битов. Полезно? Умный? Да.

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

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

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

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

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

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

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

• Каждый раз, когда я обновляю эту схему, требую ввод и вывод функций / методов, а также доступные слоты в классах. Это ускоряет повторное использование битов: мне не нужно каждый раз погружаться в код, чтобы проверить, что именно входит и выходит. Даже если это в комментариях, мне все равно придется просматривать, чтобы получить комментарии

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

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

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