Легкий способ бросить писать идеальный код

26 Сен
2011

Возможно заголовок этой статьи может ввести вас в заблуждение, но думаю, что большинство тех, кто достаточно долго занимается программированием, поймет о чем пойдет речь далее.
Зададим себе несколько вопросов. Часто ли я переписываю свой код с нуля, пытаясь его улучшить? Часто ли я меняю дизайн приложения во время его разработки? Задерживаюсь ли я на каждом методе (или функции) достаточно долго, пытаясь продумать все аспекты его использования? Считаю ли я, что абсолютно любое программирование служит мне уроком и источником опыта? Стараюсь ли я в новом коде всегда использовать что-то новое, чтобы саморазвиваться? Обращаю ли я больше внимание на лаконичность/красоту кода, чем на лаконичность/красоту приложения в целом?
Если вы на большинство этих вопросов ответили положительно, поздравляю — вы страдаете от того же недуга, что и я. От перфекционизма.

Как перфекционизм может разрушить вашу жизнь


Давайте начнем с того, что идеалов в нашем мире не существует. Свыкнитесь с этой идеей, попытайтесь с этим жить. Никакие ресурсы никогда не позволят вам написать идеальное приложение, или просто идеальный код, как бы вы этого не хотели и как долго не старались.
Я сам тоже был уверен в том, что возможно писать идеальные приложения, доводить код на стадии разработки до состояния, когда я мог бы посмотреть и сказать «отлично!», делать приложения сразу так, чтобы в них не было никаких ошибок, неуправляемых состояний. Я делал все очень долго, каждый раз досконально изучая проблему, пытаясь найти самое красивое решение.
И проблема заключалась в том, что мои знакомые программисты, у которых было опыта меньше, чем у меня, чаще заканчивали какие-то проекты. И свои, и на заказ. При этом я всегда внутри себя думал, что «вот, написали говнокод, все глючит, тут не так, там не очень хорошо и кто только за это денег заплатит». Но время шло, эти люди добивались какого-то успеха, их проекты со временем формировались во что-то «юзабельное» и один взлетел очень высоко. Их проекты росли.
А мои — нет. Точнее моих проектов и не было. Всё, что я делал, в какой-то момент останавливалось на каком-то участке, который мне казался неразрешимым. Мне не хотелось его решать так, как приходило в голову, я хотел все обдумать. И брал отсрочки.
С работой, конечно же, по этой причине все не заладилось с самого начала. Я брал небольшие заказы за маленькие деньги и старался выполнить их максимально качественно, конечно же, при этом я срывал все мыслимые и немыслимые сроки. Один свой проект я затянул почти на год. Серьезно, целый год я постоянно над ним думал, но никак не мог доделать.
К чему я пришел через 7 лет программирования? Я считал себя профессиональным разработчиком, я много чего знал, умел больше других, но… При этом у меня не было законченных проектов, точнее были, но лишь 1% от задуманных. Моя работа шла довольно туго, я получал меньше денег, чем хотел, чувствовал внутреннюю неудовлетворенность.
Фактически, стремление к идеалу поставило меня в такое положение, когда я думал «вхолостую», очень много мыслей и времени тратилось, а «выхлоп» был почти нулевой.

Лень или не лень


Важный вопрос, который меня всегда волновал, лень ли моя проблема, или в что-то другое?
Суть в том, что я мог оттягивать момент начала работы почти бесконечно, но при этом я всегда находился в состоянии осмысления задачи. Постоянно, это значит прерываясь только на сон. Чтобы я не делал, где бы не находился, я постоянно думал над проектами, но не садился их делать, пока не находил какую-то мысль, какое-то решение, с которого я мог бы начать.
При этом все другие аспекты моей жизни не подвергались такому маниакальному идеализму. Т.е. я могу прибраться в квартире, поехать по важному делу на другой конец города в любой момент, мог подрабатывать на физической работе. И никогда у меня не было такого, чтобы я вместо этих дел лежал в постели целый день.
Сделав вывод, что мое затруднение избирательно, я пришел к тому, что это не может быть «обычной» ленью. Проблема находится где-то глубже.
Но, возможно, сама проблема стоит на лени, как на фундаменте, ведь на самом деле, как бы вы не убеждали себя в обратном, реализация обычно сильнее напрягает мозг, чем просто осмысление задач. Конечно, это справедливо только в рамках проекта, а не отдельной функции/метода, когда надо обдумать конкретное решение и просто его записать.
Для простоты можно подытожить выше написанное тем, что это не лень.

Я совершенствую себя


Эта фраза на самом деле, как не посмотри, губительна. Если у вас есть идея, или вы получили идею от того, кто ждет реализации, но вы подходите к её реализации с точки зрения самосовершенствования — это провал.
По сути, этот подход является инерцией обучения программированию в целом. Когда вы еще неуверенный в себе программист, каждый новый код, который вы пишете, является ступенькой в вашем развитии. Каждая новая задача является упражнением для мозга, вы открываете что-то новое, пытаетесь применить что-то, о чем где-то прочли, или где-то подсмотрели.
И это хорошо. Но хорошо только в самом начале, когда вы только поднимаетесь по лестнице обучения. Но в какой то момент нужно сказать себе: «Эй, постой. Ты уже не учишься, это — работа. Ты должен писать код, а не пытаться найти в этом какую-то пользу для себя самого». Но многие забывают себе это сказать. Я тоже себе этого не говорил.
Если вы подходите к программированию реального проекта, как к упражнению — это плохо.
Вы будете совершенствоваться всегда и везде, но если это для вас внутренне будет одной из целей и она будет превалировать, вы будете обречены вечно заниматься обдумыванием и переписыванием кода, в то время, как «война закончилась, пока командование составляло план».

Каждая новая строчка кода лучше предыдущих двух


Почему-то мой мозг отказывался понимать тот простой факт, что одним только переписыванием проблему не решить. Топтаться в четырех строках кода, стараясь найти тонкий баланс между красивым кодом внешне и по логике, это плохо. Это потеря времени.
Безусловно, если вы напишете какой-то код, увидите ошибки, удалите его, перепишете заново, учитывая недостатки, то код станет лучше. Так можно делать, да я так и делаю довольно часто. Но только на «коротких дистанциях».
Проблема начинается тогда, когда вы на этапе «проектирования» удаляете код целыми папками. Либо вообще удаляете весь проект и начинаете к нему подступать с другой стороны. Пользы от этого не больше, чем от того, что вы будете выкидывать бутерброды до тех пор, пока масло на него не ляжет в форме правильного квадрата. Почти никогда у вас на раннем этапе не получится идеальный дизайн приложения. Просто держите это в голове.
Еще одной разновидностью этой проблемы является стойкое нежелание использовать чужой код. Особенно, если он слишком сложен для вас, либо наоборот, он, на ваш взгляд, слишком прост.
На эту тему уже много всего сказано, но подытожить все можно только одним — используйте чужой код, если это позволяет задача. Не пишите код, который можно было просто использовать. Потому что у вас не всегда получится реализовать этот код лучше, быстрее, а главное, что он никогда не будет таким же оттестированным и проверенным как тот, который опубликован, как библиотека, или отдельное приложение.
Это справедливо не всегда, поскольку идеального кода не существует, некоторые библиотеки могут действительно быть плохими, медленными, реализовывать не лучший подход. Но если ваш проект позволяет использовать сторонние решения, если они достаточно малы, реализованы отдельными модулями, то на некоторые недостатки можно закрыть глаза.
Кстати, что касается сторонних библиотек, иногда вы можете увидеть чужой код, который по сравнению с вашим выглядит очень красиво, который хорошо продуман, у него высокая отказоустойчивость и т.д. и т.п. Вы можете назвать его идеальным. Но в ста процентах случаев, если это код достаточно большого приложения, вы можете быть уверены, что этот код не писался таким с самого начала, а был отточен уже при опытном использовании.
Не переписывайте код по сто раз. Люди изобрели всякие разные полезные вещи в программировании, которые помогают упростить исправление и редактирование рабочего кода. Рефакторинг. Используйте их, используйте TDD, хотя в начале это будет сложно и будет казаться бессмысленным. Избавляйтесь от привычки переписывать код в нерабочем приложении.

Вечное проектирование


Если у вас есть идея, или работа, следует приступить к ней немедленно, если у вас нет других занятий. Не нужно вынашивать идею, не нужно ждать, пока она созреет. Это все — глупости. Переходите от теории к практике не больше, чем за одни сутки.
Подходя к проектированию следует продумать только основные моменты. Кроме того, что у вас будет за приложение вообще, вам следует знать ответы на такие вопросы: Где я буду писать код бизнес-логики? Какова будет структура используемых баз данных? Какие библиотеки для каких задач мне нужно использовать?
Если вы начинаете проектирование с того, что создаете документ, текстом в нем описываете все задачи, которые вы хотите реализовать, там же пытаетесь составить схемы, попутно продумывая какие-то частные вопросы по будущему коду, либо начинаете думать как реализовать те места, которые не являются основными в вашем проекте, а является «окружением» (например, фреймворк), если все это у вас занимает больше двух-трех суток и вы еще не приступили к программированию — предупреждаю, скорее всего разработка затянется навечно.
Кстати говоря, на ранних этапах создание таких обширных документов — бессмысленно. Нет, правда, серьезно. Это пустая трата времени, пока вы не начали действительно работать над решением задач и программированием. Конечно, часто в работе используют ТЗ, скажете вы. Но тут вы окажетесь не правы. ТЗ это документ, цель которого объяснить задачу так, чтобы разные исполнители могли её понять целиком и оценить, а заказчик мог представить, что он получит на выходе. Если у вас нет раздвоения личности и вам не нужно объяснить задачу вашему второму «Я» — не начинайте разработку с создания бессмысленных записок. Это трата времени, это все уже есть в вашей голове, нет смысла это куда-то записывать. Вы не забудете все вдруг, если будете работать над приложением. Начинайте писать код.
Безусловно, сани нужно готовить летом. Но если готовить их так, что и зиму пропустите, то это просто трата времени. Если ваш склад ума таков, что вы задумываетесь над проблемой слишком основательно — постарайтесь меньше думать. Не думайте, а просто пишите код, вы все равно поймете проблемы в процессе и успеете их решить быстрее, чем если бы вы выявили их вслепую.
Я считаю, что MVC и стал так популярен, потому что он как бы сказал всем программистам: «Стой! Не думай больше над дизайном, просто используй это и отталкивайся от него». Осталось только поверить в то, что MVC это достаточно «авторитетно» для вас и одна из проблем отпадет. Поступайте также и касаясь паттернов программирования.

Я пишу не код, а приложение


Всегда помните, что на ваш код почти во всех случаях 99% населения земли будет глубоко наплевать. Вы продаете и даете пользователям не свой код (если вы не разработчик программных библиотек, конечно), а то, что получается в результате его выполнения.
Не старайтесь акцентировать внимание на том, насколько хорош ваш код, если это не влияет на реальные характеристики вашего приложения. Реальными характеристиками являются скорость выполнения и отсутствие грубых ошибок. Но тут тоже все не так просто.
Преждевременная оптимизация губительна. Нужно примерно представлять себе, какое место в вашем приложении будет «узким», но не стоит каждую строку кода писать так, чтобы она выполнялась быстрее. Это просто тратит слишком много вашего времени. Не делайте этого, лучше оптимизируйте ваш код, когда он уже будет готов. Оптимизируйте рабочий код.
Что касается ошибок, просто смиритесь с тем, что они будут всегда. Ошибки сегодня находят в программах, которые развиваются и поддерживаются годами, а иногда и десятилетиями. Ошибки будут всплывать там, где вы их не ожидали. Где вы их ожидали, вы наверняка и на автомате сделаете проверки. С опытом приходит понимание, какие места будут проблемными, и решения будут всплывать автоматически. Нет необходимости стараться все доскональна изучить, чтобы исключить все ошибки. Запомните, что поправить ошибку в 90% случаев проще, чем её предупредить и сделать нужные проверки. Лучше поправьте ошибки на этапе тестирования (или разрабатываете через тесты), чем тратить время исправить ошибки в коде, который вы еще не написали.
Старайтесь всегда мыслить в рамках всего приложения в целом, а не отдельного участка. Продумайте только то, что непосредственно будет являться частями вашего будущего приложения. Не старайтесь продумать весь код. Не старайтесь доводить его до совершенства. Лучше будет, если вы сделаете приложение, которое будет выполнять свои задачи, но будет иметь не самый лучший код, чем не иметь ничего, кроме недописанного кода, который вы месяцами доводите до ума.
Делайте проекты, а не пишите код. Направьте свою дотошность в правильное русло, попробуйте придумать, как можно сделать что-то существующее лучше. Что-то на уровне проектов, а не кода. Попробуйте придумать то, что кому-нибудь может понадобится, но чего еще не существует. Может быть вам придет в голову идея нового проекта, который изменит весь мир, но вы не сможете её реализовать, потому что не сможете дописать код, или даже начать!

Идеалов нет, делайте GEA!


Поскольку идеал недостижим, то старайтесь доводить приложение до минимально приемлемого уровня, достаточно хорошего. Когда приложение действительно работает. Потому что на самом деле только это важно, а код это лишь инструмент.
Пока вы будете стремиться сделать что-то очень хорошо, вас всегда будут обгонять на повороте те, кто делают лишь достаточно хорошо, чтобы этим можно было пользоваться. Вы будете удивлены, но большинство того софта, что вы используете каждый день, на самом деле не идеально, даже если работает очень хорошо. Некоторые программы вообще могут быть написаны очень «плохо», по вашим меркам. Но они работают. И вы их используйте.
Если ваше стремление к идеалу обусловлено тем, что вы ищете определенного рода признания, либо хотите убедить себя в том, что вы хороший программист, то я уверяю вас, вам гораздо больше уверенности придадут отклики на ваше законченное приложение, чем на строки кода, на которые всем, даже коллегам, будет наплевать.
Делайте быстро, старайтесь как можно быстрее сделать так, чтобы приложение работало, выполняло свои цели. После этого начинайте заниматься доведением кода до ума. Исправляйте ошибки. Приводите код к читаемости, пишите комментарии, документацию. Но не делайте все наоборот. Ибо это увеличивает срок разработки в разы, а иногда и на порядки.
Эта статья не включает в себя какие-нибудь 10 шагов, чтобы победить перфекционизм. Да и таких шагов не существует. Никакие методики, никакие статьи лично мне не смогли помочь. Поэтому эта статья просто говорит вам — программируйте уже наконец! Это единственное решение.
Если вы страдали от перфекционизма больше 5 лет, то ваш код, который вы будете писать не задумываясь, будет достаточно хорош с первого раза. Достаточно хорош, чтобы сделать приложение.
Если вы откладывали или обдумывали какие-то идеи, но еще не приступили к их реализации, или застопорились на каком то моменте, потому что не можете придумать, как это сделать идеально, просто садитесь и пишите код. Потому что когда-нибудь наступит момент, когда будет уже поздно начинать.
Post scriptum:
Эта запись в первую очередь адресована тем, кто занимается разработкой и программированием без четко спланированного менеджмента. Если у вас есть руководитель, который просто говорит вам, что нужно делать, а чего не нужно, возможно вы никогда не столкнетесь с проблемами, описанными выше.
Однако, реальность такова, что тем, кто страдает перфекционизмом очень сложно работать под чьим-то управлением, сложно заниматься простым кодингом, поскольку желание сделать все по своему (идеально) будет всегда перевешивать. И перфекционизм будет проявлять себя и в отдельных задачах, даже если вы не единственный разработчик в команде.
По материалам Хабрахабр.



загрузка...

Комментарии:

Наверх