Как не писать говнокод? Любой мой проект, в принципе говнокод. Я всегда
пишу говнокод и не знаю, как сделать лучше. Только когда меня носом тыкают, я начинаю понимать, что не так. Я раньше вообще не осознавал этого факта, давал проекты на ревью, в основном, сносно или хорошо было. Только в этом месяце, я осознал это, когда появилось пару человек, которые умнее меня и знают больше. Как этого избежать и научится писать нормальный код?
11 ответов
Окружить себя толковыми кодерами и по кд кидать им кучки своего когда
Перестать писать сложно то, что можно написать простым способом
Ну обычно либо практика нужна, либо чтение и осознание какой-нибудь литературы У Фаулера в рефакторинге есть список признаков плохого кода. Можешь почитать и пробовать найти у себя эти признаки А практику можно наработать и участием в разных проектах (учиться на примере коллег), или поддержкой быстро развивающегося проекта — в таком случае сам будешь видеть что затрудняет изменение кода и внедрение новых фич, а что способствует им
https://refactoring.guru/ru/refactoring/what-is-refactoring дополню, хоть там больше по ООП, но в любом случае почитать стоит
Можно еще читать опенсурс и найти единомышленника и что бы рефачили друг друга
и трогали тоже :3
Мне не сильно нравится этот каталог Описание паттернов в нём в каких-то мелочах отошло от того, что дано в гоф. Может это и хорошо, может паттерны и нужно немного переосмыслить, но меня это смутило
Так современные ООП языки отличаются от того что имели ввиду ребята GoF и ранее, все эти посылки сообщений и 2 вида трактования инкапсуляции.
Нет, ООП не изменился со времён написания книги бандой И трактовки инкапсуляции тогда были, и разные виды полиморфизма, и разделение ООП на то, что было придумано Кеем, и то, что реализовал Страуструп. У них в книге же не раз упоминается смоллток — язык, который Кей создал. А примеры на плюсах
Как перестать писать говнокод?
Здравствуйте! Три месяца назад меня взяли работать в небольшую организацию, для нужд которой необходимо написать приложени (под Android, пишу на Java). На собеседовании особых вопросов не задавали. Сказали, мол, приложение будет простенькое , учиться вместе будем и тд. Руководитель мой, программист C#, он мне задания и даёт. Т.к. база программирования у меня крайне слабая уповаю я, лишь на гугл. Со временем, понимание начинает приходить, мозги работать. Т.е. постоянно идет работа с поиском кода, его чтением, анализом, что непонятно сразу в доки, книжки, статьи. Как то раз даже нашел в городе программиста, и напросился на встречу, где он мне написал кусок кода, который меня спас от увольнения. Даже зарегистрировался тут и на стэковерфлоу. Но я пишу откровенный говнокод. Руководитель ругает меня за низкую скорость. И может иногда карательные меры предпринять, хоть и не смертельные. Я действительно неэффективно работаю. Напрашивается вывод, нужно увеличивать знания java core. И писать, писать, писать. Но после рабочего дня, если я его честно отрабатываю, откровенно не халтуря, то мои мозги не могут воспринят информацию, в нужном объёме. Мне код снится ночью уже. Чаще мой рабочий день это 12 часов, за которые я успеваю выжать себя как лимон, потратить время на отвлекающие факторы и что то написать, вернее «наговнокодить«. Проект двигается, разрастается и с каждым днем я понимаю, что это вавилонская башня.
Мне нужен Ваш совет, умеющие программисты. Какой то жизненный опыт, ваш. Как перестать говнокодить?? Спасибо!
Да в общем-то никак. Умение писать грамотный код придет со временем, если, конечно же, регулярно практиковаться. Для новичка (особенно если речь идет всего о трех месяцах опыта) говнокод и медленная скорость работы — это вполне нормальная картина. Ему просто неоткуда знать, как писать код грамотно и быстро (к сожалению этому не учат даже в институтах ). Со временем, если у новичка есть голова на плечах и желание развиваться, он будет накапливать положительный и отрицательный опыт, научится грамотно распределять свое время и усилия, и мало-помалу этот процесс сдвинется с мертвой точки. Главные условия — это регулярная практика и самообучение. Описанная вами картина очень хорошо знакома многим (читая ваши строки, вспоминал, что почти то же самое происходило и со мной) — срывы сроков работы, регулярные баги, любовь к костылям, повсеместный говнокод, нагоняи от начальства. Серебряной пули здесь нет, это болезнь роста. Она излечивается со временем при соблюдении вышеуказанных условий.
В любом случае хорошим подспорьем будет ковыряние в чужих исходниках (Гитхаб к вашим услугшам), чтение подходящей литературы («Совершенный код» Макконелла или «Рефакторинг и улучшение существующего кода» Фаулера). Поинтересуйтесь также такой вещью, как рефактринг — изучение его принципов способно помочь в понимании того, как следует писать код. Если вы пишете на C# в Visual Studio, то великолепнейшим помощником для вас может стать Resharper. Он способен разглядеть тысячу потенциальных проблем в вашем коде и просто облегчить работу. Также очень благотворно может повлиять наличие наставника, который мог бы что-то показать и объяснить. Хотя с этим обычно сложнее.
- Разберитесь как правильно писать на Java: Thinking in Java, Effective Java.
- Пишите код.
- Читайте про хороший код: Clean Code, Beautiful Code, Code Complete, Implementation Patterns.
- Пишите код.
- Читайте чужой хороший код. Изучайте исходники популярных open-source продуктов. Разумеется, вы не сможете сразу отличить хорошие примеры кода от плохих. Но это даст вам пищу для размышлений и образцы для подражания (пусть даже и не лучшие). Получится своего рода бесплатный опыт: вам не пришлось тратить время на разработку и написание, вы смотрите уже на готовый код.
- Продолжайте писать код. Перечитывайте материал из пунктов 1-3. Выкидывайте плохой код. Пишите еще. Не бойтесь рефакторить.
- Будет отлично, если вы сможете учиться у других программистов и кто-то будет адекватно критиковать ваш код, например в рамках open-source проекта.
- Читайте про проектирование, принципы SOLID, паттерны, тестирование. Постепенно вы научитесь отличать хороший класс от плохого.
- Возвращайтесь к своему старому коду (даже полугодовалой давности). Обдумывайте, что в нем не так, что вы бы улучшили. Опирайтесь в дальнейшем на этот опыт.
Я это все к чему: умение писать хороший код не приходит спонтанно. Необходимо накопить некоторую критическую массу опыта только для того, чтобы начать понимать что лучше, а что хуже. Намного быстрее этот опыт набирается в среде опытных разработчиков, где вам есть с чем сравнить свой код, чем в изоляции.
Чаще мой рабочий день это 12 часов, за которые я успеваю выжать себя как лимон
Не думаю, что оно того стоит. Такая работа — путь к стагнации и разочарованию в профессии.
Три месяца назад меня взяли работать
А это вообще не срок. Все впереди. Главное не позволяйте работе довести себя до «творческого выгорания».
Как перестать писать говнокод
Шутеечки на тему IT и всего, что связано с компьютерами. Подписывайтесь 🙂
0. Никому не говори, что у тебя есть принтер.
1. Никогда не говори, что умеешь переустанавливать Windows.
3. Придя в гости — не чини компьютер.
4. Делай комментарии в коде.
5. Не давай компьютеру понять, что спешишь.
7. Проверяй сделанные бэкапы!
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору
Как не говнокодить?
Часто ищя решения какой-нибудь задачи я натыкаюсь на обсуждения, что это так называемый говнокод и поставленную задачу можно решить другим способом. Как правило такой код вполне рабочий, но к нему возникают такого рода предъявы. Почему так происходит и как этого избежать, может какие-нибудь рекомендации?
Что если задача не была поставлена (сформулирована), а код пишется?
а зачем он тогда вообще пишется?
Задача могла быть решена на 0.1% а код может быть хорошим, потому, что легко и дёшего дорабатывается.
А можно закрыть все потребности говнокодом, который решает задачу на 100%, но как только через N времени появится новая потребность в расширении, проще будет просто отказаться от такой работы.
Попытайся наговнокодить на чистoм Posix sh.
Чтобы решить не поставленную задачу. Такие авторы считают, что постановка задачи — лишний этап. Даже на лоре таких полно. Как ты оцениваешь такой код?
Если кратко, то в чем разница?
А ты попробуй и сам поймешь. Ногу острелить намного труднее.
Внимательно читать документацию. Обычно претензии бывают, когда что-то делается стандартной функцией в 1-2 строчки, а ты изобретаешь велосипед на 100
Дыры в безопасности. Например, твой код сломается, когда встретит в каталоге имя файла с пробелом.
Писать на bash что-то длиннее сотни строк (автогенерированный код не считается, как и приклеенный к скрипту блоб). В 99% случаев это значит, что надо взять другой язык.
Вкусовщина. Всегда найдётся кто-нибудь, кто назовёт тебя быдлокодером, какой бы ты код не написал. Не стоит принимать всё слишком близко к сердцу.
Чтобы решить не поставленную задачу.
То есть задача все равно сформулирована? Отсутствие приказа на исполнение не означает отсутствия задачи.
А можно закрыть все потребности говнокодом, который решает задачу на 100%, но как только через N времени появится новая потребность в расширении, проще будет просто отказаться от такой работы.
Ну и отлично. Раз не было задачи сделать программу, которая будет поддереживаться внуками через полвека, значит в этом не было и смысла. То, что вы назвали говнокодом — свою задачу успешно выполнило и было отправлено в утиль, как и любой другой устаревший продукт. Если бы кому-то понадобилось расширение через N времени — это входило бы в условия задачи.
Уменее писать без говнокода придёт само со временем. Может быть конечно зависит от сферы и специализации, но кажется такое умение приходит лет через 10 постоянной практики.
Ну и еще придёт умение отсеивать критику тех кто сам ничего не умеет кроме критики, это как люди которые не могут читать смысл написанного если видят ошибки в русском языке — у них включается подпрограмма придирок к грамотности, и если человек не грамотен — они не могут увидеть его мысль, и даже допустить что она есть 🙂
Некоторые программисты тоже через такое проходят — им можно дать гениально подобранный для конкретной задачи алгоритм -но реализованные не оптимально и на древнем стандарте их яп. В итоге опытный прогер увидит прежде всего решение задачи и восхитится кодом, а всякие миддло-джуны начнут стебать про то что так уже никто не пишет и вообще не оптимально, а то как искуссно решена задача даже не поймут, и если им дать с нуля реализовывать — они напишут топорно, но зато используя все няшные плюшки 🙂
Это такая тайна?
Поддерживаю. В моей практике приходилось десятки раз писать сугубо одноразовые скрипты, потому что такой задачи больше нигде и никогда не встретится. И как бы они ни были написаны — если решили задачу, они хорошие. Но людям я бы их не показывал 🙂
Есть два стула вида разработчиков, которые:
Участвуют в конкурсе красоты исходников и не стремяться выпустить работающий продукт. В худшем варианте это сродни ОКР. Им важнее, чтобы все было канонично, «правильно».
Херачат решение и дорабатывают в процессе эволюции требований к реализации. Они знают недостатки текущего решения и осознают, как это может стрельнуть в ногу в будущем, поэтому оставляют подсказки себе и коллегам.
Также, есть два вида «ревьюверов», которые:
Хейтят чужое ради повышения ЧСВ. Обычно это люди, которые хейтят не только чужой код, но и жалуются на жизнь: считают, что происходящее с ними дерьмо находится в зоне ответственности других людей. Их много. Воспитание-с.
Укажут на недостатки (кто-то резко, кто-то мягко) и посоветуют как исправить. Или же, увидев подсказки, поймут «что хотел сказать автор».
Рекомендация одна: насрать на окружающих, делать, анализировать результаты и стремиться быть лучше.