Разница между компьютерным инженером и кодером.
Да, вы не ослышались. Это не одно и то же. Ну по крайней мере для меня это совершенно разные вещи. Я говорю это, потому что у меня есть факты, подтверждающие это различие. Прежде чем читать дальше, я просто хочу убедиться, что это моя идеология, и она может отличаться от человека к человеку.
Определение:
Кодер — это человек, который пишет код. Да, я прямолинеен. Просто шучу. Кодер — это человек, который применяет свою логику для решения сложной/простой задачи с помощью языка программирования. Ему все равно, является ли решение оптимальным, если только код не работает.
С другой стороны, компьютерный инженер — это человек, который знает, что начало написания кода — это последний этап решения проблемы. Он использует структурный подход, чтобы найти наиболее оптимальное решение проблемы, и только после этого он прикасается к своей системе, чтобы написать код.
Теперь вопрос в том, как стать компьютерным инженером, кроме как быть хорошим программистом.
Я собираюсь поделиться некоторыми из вещей, о которых я знаю. Я буду обновлять этот пост, как только найду еще несколько.
1. Поймите формулировку проблемы
Часто бывает так, что как только мы слышим о проблеме, мы начинаем думать о коде, который мы напишем для решения этой проблемы. Это поможет вам достичь скорости в более простых задачах, но, поверьте мне, в долгосрочной перспективе это будет очень болезненно.
Вместо этого начните с чтения задачи дважды. Я писал в своем предыдущем посте, что много раз так случается, что мы застряли на неправильном пути, в то время как было доступно самое простое решение, On Stack Overflow: p. А если серьезно, попробуйте погуглить свою проблему, прежде чем переходить к решению. Возможно, проблема, которую вы пытаетесь решить, уже кем-то решена. Но убедитесь, что вы понимаете решение, прежде чем слепо копировать его. Потому что, когда вы столкнетесь с ошибками в коде в будущем, их будет очень сложно решить.
2. Выберите редактора
Выбор идеального редактора для вашей работы очень важен. Редактор играет важную роль в экономии вашего времени.
Даже я никогда не заботился о том, каким редактором я пользовался во время учебы в колледже. Честно говоря, я слишком много времени использовал gedit для написания кода. Судите меня как хотите, но это было до того, как я познакомился с emacs. Я мог бы настроить его с помощью своего языка программирования, добавить поддержку git в самом редакторе, чтобы сэкономить время при переключении между редактором и терминалом.
Я не рекомендую emacs всем, но убедитесь, что вы ищете, какой редактор лучше всего подходит для конкретного языка программирования. Кроме того, это помогает соблюдать стандартную этику кодирования, чтобы ваш код был легко читаем для всех во всем мире.
3. Используйте комментарии // Ради бога
Говоря о читабельности, что может быть лучше, чем добавление комментариев к вашим функциям. Дайте описательный комментарий, чтобы тестер или любой другой человек, читающий ваш код, мог понять, что делает функция. Это экономит время другим и вам, когда вы читаете свой код спустя годы.
4. var a = «Я переменная с очень неописательным именем»;
Наряду с комментариями убедитесь, что вы используете правильные имена для своих переменных и функций.
Всегда программируйте так, как будто парень, который в конечном итоге будет поддерживать ваш код, будет жестоким психопатом, который знает, где вы живете. — Джон Вудс
Я думаю, приведенной выше цитаты достаточно, чтобы объяснить важность правильного именования.
Не забудьте сделать отступ в коде. Код без отступов не только непрофессионален, но и труден для понимания.
5. Использование правильной структуры данных
Определите структуру данных еще до написания кода. Выбор правильной структуры данных помогает сэкономить много времени на обслуживании нескольких переменных. Поймите, в чем проблема и как вы будете манипулировать своими переменными. Примите во внимание скорость, с которой работает каждая структура данных, и то, насколько вам удобно использовать встроенные функции в этой конкретной структуре.
6. Модульное тестирование
Я знаю, что вы программист, а не тестер, но поверьте мне, это самое главное, чтобы убедиться, что ваш код не глючит. Напишите тесты для всех своих функций и протестируйте их на максимально возможном количестве случаев.
Лучше используйте TDD. Если вы не знаете, что такое Test Driven Development, это практика разработки, при которой вы сначала пишете свои тестовые примеры, прежде чем писать свою функцию, а затем убедитесь, что все ваши тестовые примеры пройдены.
7. Убедитесь, что ваш код доступен для модульного тестирования
Для модульного тестирования важно понимать, как работает модульное тестирование. Модульное тестирование может быть выполнено на функциях, которые работают, а не многие. Например, если функция написана для проверки имени пользователя и пароля, убедитесь, что она не выполняет никакой другой работы, например, «если пользователь прошел успешно, добавьте его в базу данных». Он будет возвращать либо истину, либо ложь (в большинстве случаев).
В сценариях, где функция выполняет несколько задач, модульное тестирование становится затруднительным.
8. Подробнее о git
Если вы работаете в команде, важно правильно использовать git. Любая ошибка приведет к неприятностям для вас и всей вашей команды.
Поймите, почему ветвление полезно, поймите разницу между слиянием и перебазированием.
Дайте правильное сообщение своему коммиту, чтобы ваша команда могла понять, о чем он.
Что ж, это некоторые из моментов, которые, как мне кажется, отличают две роли, и я добавлю больше, как только узнаю. Большое спасибо за чтение.
Первоначально опубликовано на https://medium.com 26 апреля 2018 г.
