Учитесь на ошибках других людей в программировании прямо сейчас, чтобы не делать их
Некоторые ошибки, которые делают большинство новичков и даже некоторые опытные люди (например, я) при написании кода, и способы их избежать.
0. Собираем все в один файл
Это наиболее распространенная ошибка, которую вы могли бы увидеть, когда многие программисты записывают весь свой код в один класс / файл.
Одна из основных причин этого заключается в том, что мы изучаем большую часть кодирования с помощью видеоуроков, где большая часть авторов намерена объяснить вам концепцию / логику, а не о том, как структурировать ваш код.
Следовательно, научитесь разделять свой код на различные классы и перемещать эти классы в разные файлы / проекты, чтобы улучшить структуру вашего проекта.
1. Не / вручную форматировать код
Я видел, как многие люди не уделяют достаточного внимания форматированию своего кода, оставляя пустые строки между различными логическими частями, не предполагая вложенных блоков кода и т. Д.
В то время как другие вручную тратят свое время на табуляцию / интервал влево и вправо, а иногда оставляют слишком много пустых строк в коде без причины.
Большинство IDE в настоящее время поставляется с инструментами автоматического форматирования в вашем распоряжении, которые вы можете использовать для форматирования своего кода стандартным способом, убедитесь, что вы включили их и назначили удобные ярлыки, чтобы ваш код всегда был хорошо отформатирован.
2. Незнание своих инструментов
Просто добавив к вышеизложенному, узнайте, какие плагины / ярлыки вы можете использовать, чтобы ускорить разработку и сэкономить те секунды времени, когда вручную запускаете определенные действия в вашей среде IDE.
Постарайтесь узнать, какие инструменты используют ваши старшие разработчики / другие разработчики в сообществе для повышения эффективности.
Постарайтесь автоматизировать большую часть своей работы, где это возможно, ведь вы программист!
Например, когда вы закончите писать свой код, вы можете потратить значительное количество времени на создание упакованного приложения и его развертывание вручную в хранилище / серверах.
Почему бы не изучить инструменты CICD, которые могут сэкономить вам часы времени на протяжении всего жизненного цикла вашего проекта? Итак, все, что вам нужно сделать, это отправить свой код в Git, и тогда вы знаете, что он будет автоматически отправлен вашим пользователям.
3. Оставлять комментарии, комментировать код без надобности.
- Как начинающие разработчики, мы, как правило, оставляем много комментариев с намерением объяснить код будущим «я».
- Часто мы просто боимся удалить блок кода, поэтому просто комментируем его, думая, что будем использовать его в будущем.
Обе эти практики неверны, и вам следует попытаться свести к минимуму количество комментариев, которые вы оставляете в своем коде.
Без комментариев - лучший сценарий, но тогда вы можете спросить, как бы вы объяснили свой сложный код тому, кто мог бы его читать в будущем?
Ответ был бы не в том, чтобы писать сложный код, который нуждается в комментариях для его объяснения. Код похож на шутку: если вам нужно его объяснять, этого недостаточно.
Я настоятельно рекомендую вам проверить эту историю, если вы хотите узнать больше об этом.
4. Слишком много журналов.
В вашем коде остается слишком много операторов журнала / печати. Я как новичок понимаю, как работает программа, которую мы использовали для добавления операторов журнала, но оставлять их в кодовой базе вашего проекта - большой запрет.
Во-вторых, попытайтесь сперва предугадать ход программы самостоятельно, а затем запустите ее, если что-то пойдет не так, попробуйте потренировать свой ум, выполнив пробный прогон, а затем добавьте только ограниченное количество операторов журнала и посмотрите, были ли вы правы или нет.
Это небольшое упражнение поможет вам развить больше уверенности в себе и своем критическом мышлении, а не просто слепо следить за журналами для выявления проблем.
Как всегда, не забудьте удалить / отключить журналы, прежде чем запускать код в производство. Может быть, изучить лучшую библиотеку журналов для вашего проекта?
5. Мыслить только на короткий срок.
Много раз я видел себя / других разработчиков, совершающих эту ошибку. Иногда мы пишем код только для того, чтобы уложиться в короткие сроки.
Например, если в вашем приложении 10 желтых кнопок в разных местах, многие новички просто назначат каждой из них шестнадцатеричный цвет для желтого, и это будет работать.
Но позже, когда появятся изменения, которые сделают эти кнопки синими, а не желтыми, разработчики откроют все эти 10 разных мест в коде и внесут изменения.
Дело в том, что ваш код всегда легко изменить с минимальными усилиями в долгосрочной перспективе. Спросите себя, произойдут ли такие изменения, как вы хотите добиться их эффективности в своем проекте за меньшее время.
Это еще один хороший способ проявить критическое мышление перед написанием кода.
6. Запуск кода после каждой строчки кода.
Это то, что сделает вас очень неэффективным разработчиком. Многие разработчики вначале имеют привычку часто запускать наш код, чтобы убедиться, что все работает должным образом, по мере того, как мы пишем больше кода.
Но это не очень хорошая практика, поскольку вы не думаете критически о потоке своего кода. Следовательно, попробуйте запустить поток своей логики в мозгу, пока вы пишете код, а затем просто запускайте код через определенные промежутки времени, чтобы подтвердить свои ожидания.
7. Скопируйте и вставьте код, которого вы не понимаете.
Не говоря уже о шутках, мы, программисты, не можем позволить себе выпускать в производство код, которого мы на самом деле не понимаем. Следовательно, всякий раз, когда вы реализуете функцию путем копирования кода с какого-либо веб-сайта, убедитесь, что у вас есть время, чтобы понять ее.
Возможно, сначала создайте небольшой POC, где вы попытаетесь изменить код, чтобы увидеть, как он реагирует на эти изменения, а затем добавите его в свою кодовую базу.
Кроме того, это отличная практика, если вы можете написать тестовые примеры до того, как фактически добавите сторонний код в свой репозиторий.
8. Незнание / применение правильных структур данных
Все мы узнаем о структурах данных в нашем курсе информатики, но у меня есть много людей, которые не могут идентифицировать сценарии в своей кодовой базе, где они могут применить карту вместо списка для фактического получения записи в постоянное время.
Применение правильной структуры данных может значительно упростить вашу жизнь / код и повысить производительность вашего приложения / системы, что всегда приветствуется.
9. Незнание основных практик «Чистого кодекса».
Это то, что ваши коллеги / товарищи по команде оценят по достоинству. Чем раньше вы изучите и примените некоторые базовые принципы чистого кода в своем коде, тем лучше будет ваша карьера.
Я настоятельно рекомендую вам прочитать книгу Принципы чистого кода Роберта С. Мартина.
Вы также можете проверить эту историю, чтобы узнать больше о чистом коде.
10. Крупные неорганизованные коммиты
Как и код, ваши коммиты git также должны быть атомарными для одной функции, над которой вы работали. Ваши коммиты должны добавлять / исправлять / улучшать только определенную часть вашего проекта, а не все сразу.
Это может произойти, потому что вы можете делать свои коммиты через большие промежутки времени, и поэтому они могут казаться повсюду. Лучше делайте ваши коммиты более частыми, чтобы они покрывали меньшую часть изменений в коде.
11. Незнание / применение правильных шаблонов дизайна
Как новички, мы, возможно, не сможем реализовать правильную архитектуру для нашего приложения, и именно поэтому у нас есть шаблоны проектирования, которые дают вам стандартную структуру, которой вы можете следовать, чтобы придать своему приложению известную в отрасли архитектуру.
Если вы еще не узнали о шаблонах дизайна, я настоятельно рекомендую вам это сделать, они сделают вас лучшим программистом.
Когда вы освоитесь и сможете оценить плюсы и минусы каждой архитектуры в соответствии с потребностями вашего приложения, возможно, вы сможете создать и проверить свои собственные шаблоны как профессионал.
12. Игнорирование ценности тестирования
Я думаю, что то внимание, которое программист уделяет написанию тестовых примеров, может быть самым большим различием между профессионалом и новичком.
Написание тестовых примеров - одно из самых важных вложений, которое вы можете сделать для своего проекта.
Написание тестов дает вам автоматизированный набор тестов для проверки целостности вашего проекта, когда вы будете вносить изменения в свой код с течением времени.
Ознакомьтесь с этой историей, чтобы узнать больше о тестировании и его важности.
13. Отправка нерелевантных ресурсов / данных в git
Как новички, когда мы узнаем о git, мы, как правило, отправляем почти все файлы в нашем проекте на удаленный git, но это не лучшая практика, поскольку мы можем отправлять определенные файлы проекта, которые не нужно отправлять.
Могут быть определенные файлы, содержащие конфиденциальную информацию о ваших учетных данных / ключах API и т. Д., Которые снова не следует отправлять в git.
Поэтому обязательно изучите файл .gitingore, а также переменные среды.
Я считаю, что это отличный инструмент для создания ваших файлов .gitingore.
Это некоторые из главных вещей, которых я бы посоветовал избегать новичкам. Что ты думаешь? Поделитесь своим опытом и мнениями. Я хотел бы услышать от вас ответы.
Спасибо за чтение ✌️
