Я переписываю свой код приблизительно 10 раз перед окончанием. Эта несправедливость?

Есть две ситуации. (1) Я смог уверенно планировать наперед и изолировать свои абстракции. (2) Не получилось.

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

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

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

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

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

Рассмотрим, как смотреть на рельсы, cakephp или django (если вы используете язык сценариев; я не знаю никаких настольных языковых фреймворков. Извините!). Тогда посмотрите, как их части подходят друг другу.

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

Сначала спроектируйте .

Совершенно нормально. Независимо от того, как много я планирую на будущее, у меня очень часто бывает момент "Ага!", когда руки бьют по клавиатуре.

Так же часто это момент "О чем, черт возьми, я думал?".

Это все хорошо. Ты делаешь код получше.

Все предложения здесь верны, однако, помните, что в жизни программы есть момент, который "достаточно хорош". Легко попасть в ловушку бесконечного рефакторинга, только потому, что вы видите, что "да, это можно сделать лучше!". Что ж, посмотрите правде в глаза - если у вашей программы нет всего нескольких строк, то ВСЕГДА есть способ сделать это лучше.

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

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

Кроме того, ОЧЕНЬ ХОРОШАЯ практика - это, по крайней мере, заставить его работать перед тем, как переписывать. Тогда вы всегда можете вернуться к работающему предыдущему решению.

(с 12 лет я постоянно переписываю игру, которую пишу, и я не подхожу к концу...)

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

Если это помогает вам добраться до хорошего решения, то как оно может быть неправильным?

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

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

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

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

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

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

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

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

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

(Я также работаю над .NET компилятором в рамках проекта MOSA - www.mosa-projet.org.)

решите вашу проблему на бумаге ... не торопитесь печатать.

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

Некоторые из причин, по которым нужно использовать рефактор:

• Повышение производительности.
• Организация кода.
• Нужно писать свой код по-другому, чтобы что-то получилось.
• Чтобы сделать что-то по-другому, потому что это экономит много работы (например: использование MXML вместо ActionScript).
• Вы использовали неправильное имя для переменной.