Нужно ли писать красивый и правильный код?
На самом деле, для меня это очень трепетный вопрос. Я до сих пор не нашел однозначного ответа на него. Возможно, то что я буду писать ниже является полным абсурдом и это испортит вашу психику. Поэтому думайте сами, решайте сами. Но прочитать все-равно стоит)
Начну с истории, которая произошла со мной в общежитии, когда я учился в ВУЗе. У меня был сосед, который учил C++. Он учил его досконально, вылизывал как только мог. Он упорно разбирался во всех мелочах языка, он знал C++ лучше, чем свои 5 пальцев. Но! Пока он изучал все это, я быстренько поверхностно изучил html,css, js и начал брать заказы и получать за это деньги. А он продолжал изучать c++. А я зарабатывал деньги. А он.. ну понятно) Мой код был ужасен, но мои лендинги работали и, кажется я уже говорил об этом, приносили деньги.
После этого я понял несколько непоколебимых истин. По крайне мере, они непоколебимы для меня и до сих пор не поколебливались.
Ваша задача - делать работающее решение, а не писать красивый код.
Что нужно заказчику? Чтобы сайт работал, не падал, все кнопки кликались, заказы приносил. Ему пофиг что под капотом. Ему без разницы на каком языке вы писали и сколько строк кода написано.
Расскажу один пример. Мне надо было сделать срочно на рельсах отправку письма. Настроить SMTP у меня не получалось и я нашел плагин с милым названием Pony. Его просто подключаешь, пишешь одну строку кода и письмо отправляется. Рай! Но один знакомый программист сказал, что плагин плохо написан и не правильно что-то там использует. Но какая разница? Письма отправляются? Сайт работает и не падает? В чем проблема тогда?
Когда я с проектом lesson-web участвовал в стартап-тусовках, то там никто не спрашивал: "Сударь, а на каком языке написан ваш проэкт?", там главный вопрос: "А ваш проект денег принесет?". Люди смотрят на картинку проекта. Если он делает какие-то очень крутые штуки - он в фаворитах.
Но есть обратная сторона медали. Про красоту кода не стоит забывать и вот почему:
- Чтобы другие программисты могли быстро разобраться в вашем коде. Если писать абра-кадабру, то сторонний программист скорее повесится, чем будет разбираться в вашем коде) Именно поэтому, иногда проще написать свое решение, чем разбираться в чужом коде.
- Чтобы вы сами понимали что пишете. Очень часто приходится возвращаться к своему написанному ранее коду, поэтому стоит позаботиться о себе. Я лично выработал свой принцип написания, который удобен мне. Я часто пишу код не красиво, но осознаю последствия этих моментов.
- Черт знает зачем. Супер-пупер-мега программисты знают почему тот или иной код нельзя писать с точки зрения работы самого языка. Ну если там что-то где-то не туда поставить, то будет оперативку жрать или сайт будет медленнее работать или произойдет бой вселенского масштаба между mysql и браузером.
Это крутой уровень. И к нему стоит стремиться.
Но, если мой сайт все-равно работает даже без знания всего этого, то почему я не могу писать код "не правильно"?
Я бы сказал, что такой уровень необходим, когда вы делаете очень большие проекты, где даже небольшие ошибки могут нехило аукнуться. Поэтому нужно знать где можно делать ошибки, а где нет.
Если вы делаете интернет-магазины, то можно не париться особо.
При чем, программисты такого уровня, как правило, самые противные. Они считают, что они боги программирования, все вокруг халопы и не достойны жизни и уважения. Поэтому они чмырят всех направо и налево. На хабрахабре таких очень много)
- Чтобы устроится в веб-студию. В серьезную студию вас не возьмут с пробелами в знании кода. Пробовал...меня не взяли. Я больше практик. Могу решить задачу, а как - это уже не ваши проблемы. В студии придется ответить как вы будете делать ту или иную задачу и почему.
Я не говорю, что писать некрасивый код правильно. Я хочу сказать, что в этом нет ничего страшного. Просто вы что-то не знаете на данном этапе развития. Надо стремится к тому, чтобы знать как можно больше. Но красивый код - это прекрасное дополнение к тому, что вы умеете делать сайты или приложения.
Но в любом случае, главное - это делать результат. Все-таки, все проекты делаются для кого-то и этот кто-то хочет видеть красивый работающий интернет-магазин, который приносит деньги, а не шлак, который написан на прекрасно-вымеренном языке.
Перейдем к следующей истине:
Важно понять принцип реализации задач .
Если ты мыслишь масштабами тегов, свойств, переменных, то для тебя нет нерешаемых задач. Ты можешь что-то не знать, но в чем проблема загуглить и найти решение своей проблемы? Если я знаю как работают теги, то если у меня возникает задача выровнять блоки по высоте, то нахожу статью в интернете, ПОНИМАЮ как решение работает и внедряю в свой проект. А понимаю я потому, что недавно изучал как эти теги работают. Поэтому не надо знать все. Надо знать принципы! Зная принципы можно осилить все что угодно.
Еще один пример. Я раньше писал сайты на 1C-Bitrix (он работает на php). Потом я перешел на ruby on rails. Мне понадобилось два месяца чтобы полностью переехать на новый язык. Знаете почему так быстро? Поясню:
Знаете как мыслит большая часть программистов? Вот так: "Я написал этот код и он мне дает результат". Эти люди не могут применить свой код для решения других задач кроме тех, которые они уже знают.
Но как мыслю я: "Чтобы получить результат, мне надо написать код". Какой код надо написать? Это уже другой вопрос...но не самый важный.
Я разработку сайта делю на "задачи". Например:
- Шаблонизировать верстку
- Разделить на страницы
- Поставить авторизацию
- Сделать администрирование контента
Каждую эту задачу можно решить разными способами и на разных языках.
Когда я переезжал на рельсы я не задавался вопросом: "А как работает Ruby On Rails?". Я задачи, которые отработал на php просто переносил на ruby. Я очень много гуглил вопросы из разряда: "Как сделать авторизацию на рельсах?". Я знал, что мне нужна авторизация и я искал как ее сделать. Сделать эту задачу для меня не было проблемой на php, но мне надо было принцип создания перенести на новый язык. Вот и все.
У меня задачи делятся на три типа:
- Задача, которую я знаю как решить и поэтому сделаю.
- Задача, которую я не вытяну потому что я в ней не разбираюсь. Например, я не возьмусь за разработку мобильного приложения на Swift. Потому что я не понимаю принципа этого языка и разработки приложений на нем.
Или я не возьмусь настраивать систему серверов, потому что для меня сервера до сих пор являются чем-то страшным и не понятным) - Задача, которую я не знаю как решить, но 100% разберусь. Это значит, что я понимаю принцип, но пока не знаю какой код нужно написать для реализации этой задачи.
Недавно я делал мессенджер на сокетах. Я понимал как работают сокеты, для чего они нужны, как их применять, но я не знал как их реализовать в плане кода. Просто мне надо было найти кусок кода, который решит мою задачу. И я нашел и решил задачу.
Хочу заметить, что третий тип задач после выполнения переходит к первому типу. Теперь я эту задачу знаю и могу сделать когда угодно.
У меня на работе сейчас даже не спрашивают: "Сможешь сделать вот это?", говорят сразу: "Сделай вот это".
Иногда, конечно, бывают ступоры. Иногда задача подвисает на несколько дней или недель. Бывает, что я задачу не делаю, потому что на нее надо потратить много времени и она становится нецелесообразной. Тогда находится либо альтернатива, либо более простое решение (иногда более простое, но более не правильное в плане кода).
Подытог. Когда вы пишите код, необходимо держать баланс между несколькими составляющими:
- Все должно работать. Если вы написали сайт на супер модном языке, но он не работает, то от него нет толка. Работа проделана зря.
- Все должно работать хорошо. Сайт должен не только работать, но и работать быстро, доступно, без лагов. Необходимо оптимизировать css,js, сжимать картинки и все такое. Я как-то сделал сайт, он работал, все прекрасно, но грузился он секунд 5-10! Это был мой первый большой проект и после него я глубоко осознал этот пункт.
- Код должен быть понятен вам или другим программистам. Если работаете в команде, то нужно писать код в формате обговоренном командой. Если пишете один, чтобы сами могли потом разобраться чего там понаписали.
- Старайтесь понимать не что вы пишете, а зачем вы это пишете. Исходите от задачи, а не от кода.
И на последок, фраза которая расставит все точки над и.
Всегда пишите код так, будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете.
— Martin Golding
Если вы сами довольны тем кодом, который вы написали, то это прекрасно и вам есть чем гордится. Если есть чувство, что где-то напортачили, то лучше переписать.
Я часто пишу код, как я думаю, идеально, а потом смотрю на него через пол года и понимаю, что это жесть какая-то и надо по-другому. Если у вас так же, то это значит одно - вы развиваетесь! Вы двигаетесь в правильном направлении.
P.S. Прошу прощения за возможный сумбур в мыслях. Я постарался выложить по максимуму выразить свое мнение. Пока что я еще пытаюсь сформулировать свое окончательное отношение к этой теме, поэтому где-то я еще сам сомневаюсь стоит ли писать чистый код или это вообще не обязательно. Но пока я считаю так, как описал выше)