Способы сломать «Синдром совершенного программиста» [закрыто]

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

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

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

Расставьте приоритеты . Обо всем по порядку. Сосредоточьтесь на том, что имеет значение.

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

• Правильный код
• Обслуживаемый код
• Чистый код
• Простой, элегантный код
• Эффективный код

Может быть, в таком порядке. Тем не менее, первый пункт является наиболее важным. Без этого код бесполезен. Что вы делаете с программой, которая не работает правильно?

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

Вы можете подумать о чем-то вроде хорошего кода . Что это? Что за люди пишут это? Как написать хороший код ? Это очень просто Напишите код, который работает . Рабочий код - это хороший код. Все остальное приходит позже.

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

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

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

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

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

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

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

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

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

Легко увязнуть в том, чтобы код выглядел идеально и соответствовал всем стандартам, которые вы только можете придумать. Это случается со всеми нами. Глядя на код, который я написал пару недель назад, я думаю о внесении изменений. Добавьте свойство здесь, измените метод там. И, похоже, это происходит в конце проекта. Но если вы слишком зациклены на этом, вы можете в конечном итоге сделать баг с ошибкой. Я делал это пару раз в начале своей карьеры. Пара сеансов исправления ошибок в 3 часа ночи вылечила меня от этой проблемы.

Сделай это наоборот.

Вместо "что можно сделать лучше?" искать "что меня бесит?" пока ничего не делает.

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

Заставьте это работать, сделайте это чистым, сделайте это ТВЕРДЫМ, сделайте это производительным.

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

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

Производительный код почти всегда наименее важен для языков с управлением памятью (Java, семейство .NET, большинство функциональных языков и т. Д.). В этих средах цель состоит в том, чтобы написать правильный код («правильный» здесь определен как выдающий ожидаемый результат во всех ожидаемых случаях, ибыть понятным и хорошо структурированным, и, следовательно, обслуживаемым), а производительность вторична (обычно она будет в некоторой степени исходить из правильного кода). Во всех случаях алгоритм работает, когда он «достаточно хорош». Помните, «преждевременная оптимизация - корень всего зла»; оптимизация, в которой вы не уверены, что вам понадобится, просто тратит время, запутывает код и, как правило, предотвращает прогресс. Сначала он должен работать, затем, как только он заработает, вы запускаете его и видите, как быстро он работает. Если это не достаточно быстро (как определено некоторым тестом, который является опубликованным требованием), вы улучшаете его до тех пор, пока не сделаете это, а затем остановитесь .

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

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