Я изучил значительный объем программирования, однако он всегда находился в научной среде (не в области компьютерных наук), полностью самоучка, и никто не мог направить меня в правильном направлении. Таким образом, мое путешествие по кодированию было ... грязным. Теперь я заметил, что всякий раз, когда я создаю какую-то программу, к концу я понимаю, как я мог бы сделать это гораздо более элегантно, гораздо более эффективно и таким образом, чтобы в будущем было гораздо более гибким и простым в управлении. В некоторых обстоятельствах я на самом деле вернулся и перестроил вещи с нуля, но обычно это практически невозможно. Хотя большинство моих программ до сих пор были относительно небольшими, кажется довольно громоздким полностью переписывать большие программы каждый раз, когда вы что-то создаете.
Мне просто интересно, это нормальный опыт? Если нет, как вы можете предотвратить это? Я пытался планировать вещи заранее, но я не могу предвидеть все, пока не начну разрабатывать некоторый код.
Ответы:
Это чувство совершенно нормально и ожидаемо. Это значит, что ты учишься. Почти каждый раз, когда я начинаю новый проект, я начинаю в одном направлении, и в конце концов заканчиваю проектировать его по-другому.
Обычная практика - сначала разрабатывать прототип, прежде чем начинать с реального. Также часто пересматривают старый код и реорганизуют его. Это проще, если ваш дизайн модульный - вы можете легко перепроектировать куски за раз без необходимости полностью разрушать ваш старый дизайн.
Для некоторых людей это помогает сначала написать псевдокод . Другие считают полезным начать с написания комментариев, описывающих, что будет делать код, а затем писать код, как только появится общая структура. Эти две вещи помогут вам лучше спланировать свой дизайн и могут избежать необходимости переписывания.
Если вы являетесь частью команды, процесс проверки имеет решающее значение для процесса проектирования. Попросите кого-нибудь просмотреть ваш код, чтобы вы могли узнать, как улучшить ваш дизайн.
источник
Это очень распространенный опыт
Большинство людей, с которыми я общаюсь, и я сам, чувствую себя так. Из того, что я могу сказать, одна из причин этого заключается в том, что вы больше узнаете о предметной области и инструментах, которые используете при написании кода, что позволяет вам распознать множество возможностей для улучшения после того, как вы уже написали свою программу.
Другая причина заключается в том, что у вас в голове может появиться представление об идеальном решении для чистого кода, и тогда вам мешает реальный мир и его грязные ограничения, вынуждающие вас писать несовершенные обходные пути и взломы, которые могут оставить вас недовольными.
«У всех есть план, пока они не получат удар в лицо».
Что с этим делать
В какой-то степени вам придется научиться признавать, что ваш код никогда не будет идеальным. В этом мне помогло то, что «если я ненавижу код, который написал месяц назад, это значит, что я выучил и стал лучшим программистом».
Чтобы облегчить проблему, нужно постоянно искать потенциальные улучшения, поскольку вы постоянно работаете и проводите рефакторинг. Убедитесь, что вы нашли хороший баланс между рефакторингом и добавлением новых функций / исправлением ошибок. Это не поможет с большими проблемами дизайна, но, как правило, оставит вам более отточенную базу кода, которой вы можете гордиться.
источник
Научитесь рефакторингу - искусству постепенного улучшения кода. Мы все учимся все время, поэтому очень часто понимают, что код, который вы написали самостоятельно, мог бы быть написан лучше.
Но вы должны иметь возможность трансформировать существующий код для применения этих улучшений без необходимости начинать с нуля.
источник
Если у вас есть отличные статические требования и вы их хорошо понимаете, и у вас есть время для подробного анализа, у вас есть шанс, что вы сможете придумать хороший дизайн, которым вы все равно будете довольны, когда закончите.
Даже в этом блаженном случае вы можете изучить новые языковые возможности, которые помогли бы улучшить дизайн.
Однако, как правило, вам не так уж и повезло: требования будут менее чем звездными и неполными, и, хотя вы думали, что поняли их, оказывается, что есть области, в которых вы сделали неверные предположения.
Затем требования изменятся, когда пользователи увидят ваши первоначальные результаты. Тогда что-то, что пользователи не контролируют, изменится, например, налоговое законодательство.
Все, что вы можете сделать, это дизайн, предполагая, что все изменится. Рефакторинг, когда вы можете, но понимаете, что время и бюджет часто будут означать, что ваш конечный результат не так элегантен, как это было бы, если бы вы знали в начале, что вы знаете сейчас.
Со временем вы научитесь лучше понимать требования, которые вы получите, и поймете, для каких частей вашего дизайна, вероятно, потребуется гибкость, чтобы воспринимать изменения.
В конце, тем не менее, примите, что изменение является постоянным, и проигнорируйте приступ, который говорит: «Я мог бы сделать это лучше» Гордитесь и радуйтесь, что вы предоставили решение вообще.
источник
Что вы можете сделать, это создать одноразовый прототип, прежде чем начинать делать «настоящий» проект. Быстро и грязно. Затем, когда вы получите прототип, подтверждающий концепцию, вы узнаете о системе и о том, как все делать правильно.
Но не удивляйтесь, если через N лет вы вернетесь к этому коду и подумаете «что за бардак».
источник
Запомните эту мантру:
Идеальное решение не всегда является идеальным решением. Идеальным решением является тот , который получает статус «достаточно хорошо» с наименьшим количеством работы.
Если вы ответите «да» на все эти вопросы, значит, ваше программное обеспечение «достаточно хорошее», и нет никаких оснований переписывать его с нуля. Вместо этого примените уроки дизайна, которые вы выучили, к следующему проекту.
Для каждого программиста совершенно нормально иметь в прошлом пару грязных программ. За мою карьеру в качестве разработчика программного обеспечения несколько раз происходило то, что я смотрел какой-то код, задавался вопросом «Какой идиот написал этот беспорядок?», Проверял историю версий и заметил, что это был я несколько лет назад.
источник
Соблазнительно думать, что идеальное планирование даст вам идеальный дизайн / архитектуру программного обеспечения, однако оказывается, что это категорически неверно. Есть две большие проблемы с этим. Во-первых, «на бумаге» и «код» редко совпадают, и причина в том, что легко сказать, как это следует делать, а не делать это на самом деле . Во-вторых, непредвиденные изменения в требованиях становятся очевидными в конце процесса разработки, о чем нельзя было говорить с самого начала.
Вы слышали о гибком движении? Это способ мышления, в котором мы ценим «реагировать на изменения», а не «следовать плану» (среди прочего). Вот манифест (это краткое чтение). Вы также можете прочитать о Big Design Up Front (BDUF) и о подводных камнях.
К сожалению, корпоративная версия «Agile» является фальшивой (сертифицированные мастера Scrum, тяжелый процесс во имя «Agile», форсирование Scrum, 100% покрытие кода и т. Д.), И обычно приводит к изменениям процесса asinine, потому что менеджеры Подумайте, Agile - это процесс и серебряная пуля (чего нет ни у одного). Прочитайте проворный манифест, послушайте людей, которые начали это движение, таких как дядя Боб и Мартин Фаулер, и не впитывайте бессмысленную версию «корпоративного гибкого подхода».
В частности, вы обычно можете просто выполнить TDD (Test Driven Development) для научного кода , и есть большая вероятность, что ваш программный проект окажется чертовски хорошим. Это связано с тем, что успешный научный код в основном имеет ультраиспользуемые интерфейсы, а производительность является второстепенной (а иногда и конкурирующей) проблемой, и поэтому вы можете избежать неприятностей с более «жадным» дизайном. TDD отчасти заставляет ваше программное обеспечение быть универсальным , потому что вы пишете, как вы хотите, чтобы вещи назывались (в идеале) до того, как вы на самом деле их реализуете. Он также предоставляет небольшие функции с небольшими интерфейсами, которые можно быстро вызывать простым способом «ввод» / «вывод», и это дает вам хорошую возможность для рефакторинга в случае изменения требований.
Я думаю, что мы все можем согласиться, что
numpy
это успешное программное обеспечение для научных вычислений. Их интерфейсы маленькие, удобные в использовании, и все прекрасно сочетается. Обратите внимание, чтоnumpy
справочное руководство явно рекомендует TDD: https://docs.scipy.org/doc/numpy-1.15.1/reference/testing.html . В прошлом я использовал TDD для программного обеспечения SAR (Synthetic Aperature Radar), и я также могу утверждать, что он работает очень хорошо для этой конкретной области.Предостережение: часть разработки TDD работает не так хорошо в системах, где фундаментальный рефакторинг (например, решение о том, что ваше программное обеспечение должно иметь высокую степень параллелизма) будет трудным, как в распределенной системе. Например, если вы должны были разработать что - то вроде Facebook , где у вас есть миллионы пользователей одновременно, делая TDD (диск вашего дизайна) было бы ошибкой (все еще хорошо использовать после того, как у вас есть предварительный проект, и просто сделать «тест первого развития «). Важно подумать о ресурсах и структуре вашего приложения, прежде чем переходить к коду. TDD никогда не приведет вас к высокодоступной распределенной системе.
Учитывая вышесказанное, должно быть несколько очевидно, что идеальный дизайн на самом деле невозможен, поэтому погоня за идеальным дизайном - игра для дураков. Вы действительно можете только приблизиться. Даже если вы думаете, что можете изменить дизайн с нуля, вероятно, все еще есть скрытые требования, которые не показали себя. Кроме того, переписывание занимает как минимум столько же времени, сколько потребовалось для разработки оригинального кода. Это почти наверняка не будет короче, так как вполне вероятно, что новый дизайн будет иметь непредвиденные проблемы самостоятельно, плюс вам придется заново реализовать все функции старой системы.
Еще одна вещь, которую следует учитывать, это то, что ваш дизайн действительно имеет значение только тогда, когда меняются требования .Неважно, насколько плох дизайн, если ничего не изменится (при условии, что он полностью функционален для текущих случаев использования). Я работал над базовой линией, в которой было 22 000 операторов переключения строк (функция была еще длиннее). Был ли это ужасный дизайн? Черт возьми, это было ужасно. Мы это исправили? Нет, все работало нормально, и эта часть системы никогда не вызывала сбоев или ошибок. Он был затронут только один раз за два года моего участия в проекте, и кто-то, как вы уже догадались, вставил в коммутатор еще один чехол. Но не стоит тратить время на то, чтобы починить то, к чему так редко прикасаются, просто это не так. Пусть несовершенный дизайн будет таким, какой он есть, и если он не сломался (или постоянно ломается), то не исправляйте его. Так что, может быть, вы могли бы сделать лучше ... но стоит ли это переписывать? Что вы получите?
НТН.
источник
Я полностью согласен с ответом, предоставленным Андреасом Каммерлохером, но я удивлен, что никто еще не предложил изучить и применить некоторые лучшие практики кодирования. Конечно, это не серебряная пуля, но использование открытого подхода, шаблонов проектирования, понимания, когда ваш код пахнет и так далее, сделает вас лучшим программистом. Исследуйте, как лучше всего использовать библиотеки, фреймворки и т. Д. Наверняка есть еще много всего, я просто выхожу на поверхность.
Это не значит, что вы не будете рассматривать свой старый код как полный мусор (вы на самом деле увидите, что самые старые программы даже больше мусора, чем без этого знания), но с каждым новым программным обеспечением, которое вы пишете, вы увидите Вы улучшаете. Также обратите внимание, что с течением времени количество лучших практик кодирования увеличивается, некоторые просто меняются, и вы никогда не достигнете совершенства. Примите этот или совсем путь.
Еще одна хорошая вещь - это исправление кода. Когда вы работаете в одиночку, легко срезать углы. Если у вас есть второй человек, который просматривает ваш код, он сможет указать, где вы не следуете этим рекомендациям. Таким образом, вы создадите лучший код и узнаете кое-что.
источник
Чтобы добавить к другим отличным ответам здесь, одна вещь, которую я считаю полезным, это знать, куда вы хотите попасть .
Редко дается добро на серьезный рефакторинг сам по себе. Но вы часто можете выполнять небольшие операции по рефакторингу по ходу работы «под радаром», работая над каждой областью кодовой базы. И если у вас есть цель, вы можете воспользоваться этими возможностями, чтобы шаг за шагом двигаться в правильном направлении.
Это может занять много времени, но большинство шагов улучшат код, и конечный результат будет того стоить.
Кроме того, чувство, что вы могли бы сделать лучше, является хорошим знаком ! Это показывает, что вы заботитесь о качестве своей работы и что вы оцениваете ее критически; так что вы, вероятно, учитесь и улучшаете. Не позволяйте этим вещам беспокоить вас - но не прекращайте их делать!
источник
Вы случайно наткнулись на одно из величайших испытаний (приключений) человечества - мост между человеком и машиной. Мост между человеком и физической структурой, например, гражданским строительством, продолжается уже более 200 лет.
Поскольку разработка программного обеспечения стала общепринятой лишь в 90-х годах, ей примерно 30 лет. Мы узнали, что это не столько инженерная дисциплина, сколько социальная наука, и мы только начали.
Да, вы попробуете TDD, Рефакторинг, Функциональное программирование, Шаблон репозитория, Источник событий, MV что-то, Java Script (<- Делайте это, это безумие), Привязка модели, Нет Sql, Контейнеры, Agile, SQL (<- сделать это это мощно).
Там нет ни одного исправления. Даже эксперты все еще цепляются за соломинку.
Добро пожаловать, и будьте осторожны, это одинокое место; но абсолютно увлекательно
источник
Я собираюсь пойти немного против зерна. Это невероятно часто , но это не приемлемо . Это говорит о том, что вы не признаете хорошие способы организации своего кода во время его написания. Ощущение исходит от того, что ваш код не прост .
Ваш опыт был моим долгое время, но в последнее время (последние пару лет) я производил больше кода, который не дает мне ощущения, что мне нужно все выбросить. Вот примерно то, что я сделал:
Мой код теперь более «процедурный», и я имею в виду, что он организован по тому, какие действия он выполняет, а не по структурам данных, которые он использует. Я использую объекты в языках, где автономные функции не могут быть заменены на лету (C # и Java не могут заменить функции на лету, Python может). Сейчас у меня есть тенденция создавать больше служебных функций, которые просто отбрасывают раздражающий шаблон, чтобы я мог фактически прочитать логику своего кода. (Например, когда мне нужно было обработать все комбинации элементов в списке, я поместил индекс зацикливания на метод расширения, который возвращает
Tuple
s, чтобы исходная функция не была загромождена этими подробностями реализации.) Теперь я передаю гораздо больше функций в качестве параметров, вместо того, чтобы функция обращалась к какому-либо другому объекту для его извлечения. (Вызывающий извлекает или создает его и передает его.) Теперь я оставляю больше комментариев, которые объясняют вещи, которые не очевидны, просто глядя на код , что облегчает следование логике метода. Я пишу тесты только в ограниченных случаях, когда меня волнует логика того, что я только что сделал, и я избегаю использования мошенничества. (Я делаю больше тестов ввода / вывода на изолированных кусочках логики.) В результате получается код, который не идеален , но на самом деле кажется, что все в порядкедаже через 2 или 3 года. Это код, который довольно хорошо реагирует на изменения; незначительные вещи могут быть добавлены или удалены или изменены без разрушения всей системы.В какой-то степени вы должны пройти период, когда все в беспорядке, чтобы у вас был некоторый опыт, чтобы уйти. Но если вещи все еще настолько запутаны, что вы хотите выбросить все это и начать все сначала, что-то не так; ты не учишься.
источник
Помня, что ваше время ограничено. И ваше будущее время также ограничено. Будь то работа, учеба или личные проекты, когда речь идет о рабочем коде, вы должны спросить себя, «переписывает ли это лучшее использование моего ограниченного и ценного времени?». Или, может быть, «это наиболее ответственное использование моего ограниченного времени»?
Иногда ответ будет однозначно да . Обычно нет. Иногда это будет на заборе, и вам придется использовать свое усмотрение. Иногда это хорошее использование вашего времени просто из-за того, чему вы научитесь, делая это.
У меня есть много проектов, как рабочих, так и личных, которые могли бы получить пользу от переноса / перезаписи. У меня также есть другие дела.
источник
Это совершенно нормальная часть обучения. Вы понимаете ошибки, как вы идете.
Так вы поправляетесь, и вам не следует этого избегать.
источник
Вы можете дать себе опыт узнать, что соблазнительное желание переписать, как правило, непродуктивно. Найдите какой-нибудь старый, волосатый, не элегантный проект с открытым исходным кодом средней сложности. Попробуйте переписать его с нуля и посмотрите, как вы это делаете.
В конце концов, ваш инстинкт переключится с мысли «я мог бы переписать эту систему намного лучше» на мысль «грубость этой системы может указывать на некоторую сложность, которая не сразу очевидна».
источник