Я только начал работать в стартапе! Захватывающе и звучит «круто»!
Но проблема в том, что у меня есть весь предшествующий опыт корпоративного образования.
Через несколько дней я обнаружил культурные различия. Жизнь в стартапе действительно крутая. Это, без сомнения, сложно, нужно выйти из своей зоны комфорта и быть очень гибким. Вместо того, чтобы просто решать поставленную задачу, нужно быть достаточно активным, чтобы проявлять инициативу.
Более интересный факт, с которым я столкнулся, был, когда я начал изучать кодовую базу. Я не видел много комментариев, это было на старте немного пугающим фактором для меня.
Как и в корпоративной среде, раньше существовал контрольный список комментариев кода, которому должен был следовать каждый разработчик. Обычно эти контрольные списки состоят из таких пунктов, как каждый метод или функция должны иметь сводку с описанием автора и описание метода, которое включает ввод и вывод метода, перед каждым изменением должен быть комментарий с указанием имени разработчика и даты. вместе с идентификатором задачи и так далее.
Итак, как смелый кодер, я глубоко погрузился в кодовую базу и обнаружил, что код достаточно чистый, за исключением некоторых. Теперь, что это означает «код достаточно чистый»? Ну значит я смог разобраться в коде без всяких комментариев!
Это привело к тому, что я написал Без комментариев :)
Это была хорошая новость для меня, так как я смог понять большую часть кода, и постепенно я нашел в этом комментарии только тот код, который не может себя объяснить!
В стартапе всегда происходит частый отток кода, и каждый раз, если мы будем продолжать изменять уже написанный комментарий или писать новые комментарии, это станет кошмаром для разработчиков, и они потеряют интерес к комментированию. Итак, вот важность чистого кода. Ниже приведены несколько рекомендаций по написанию чистого кода:
- Код должен быть понятным. Переменные, методы, параметры должны быть названы так, чтобы они объясняли цель их существования в кодовой базе.
- Комментирование кода не следует использовать в качестве системы контроля версий. Нет необходимости писать имя автора, идентификатор задачи или дату задачи. Даже тот код, который не требуется, не следует оставлять в файле закомментированным, так как это только создаст путаницу. Все это может быть обработано системой контроля версий.
- Комментируйте только в том случае, если какой-то код сложный, и комментарий должен кратко пояснять постановку проблемы и решение, которое предлагает код.
- При комментировании API мы можем использовать некоторые генераторы документации API, такие как apidoc, которые будут генерировать документы с использованием наших комментариев. Этот автоматически сгенерированный документ будет описывать API, например его описание, параметры, возвращаемые значения.
Из этого я заключаю, что независимо от того, стартап это или корпорация, мы всегда должны кодировать с мыслью, что наш код является казначейством компании, и мы должны обращаться с ним логически, поскольку мы подотчетны, потому что этот код будет использоваться нашими коллегами в будущем. Написав чистый код, мы сэкономим их время и энергию :)
Удачного кодирования!
