Современный деловой человек не умеет отдыхать. К таким неутешительным выводам приходят специалисты в области социологии, менеджеры по работе с персоналом и аналитики. Казалось бы, как можно постоянно работать? Люди просто не способны на такое — статистические исследования ошибаются. Но нет! В погоне за материальным достатком, признанием, реализацией карьерных амбиций человек часто забывает о собственном здоровье. Подтверждением этому стало распространение такого явления как кароси, что в переводе с японского обозначает «смерть от переработки».
Среди наших соотечественников случаев, когда сотрудник умер от переработки, пока еще не было. По крайней мере, официальных данных по этому поводу нет. Но специалисты по работе с персоналом в один голос кричат о том, что сотрудники страдают от загруженности. Как результат — такие работники быстро выгорают, теряют интерес к деятельности, впадают в затяжные депрессии либо страдают неврозом. То же самое касается и представителей IT-сферы, особенно начинающих программистов.
Как не утонуть в работе над сложными программами? Вот несколько советов, которые помогут новичку грамотно выстраивать рабочий процесс и не впадать в крайности.
Правило №1. Обязательное планирование
Любая работа требует тщательной подготовки. Программирование не является исключением. Идеальная схема планирования программного кода выглядит приблизительно так:
- Замысел;
- Исследование;
- Планирование;
- Реализация;
- Проверка;
- Корректировка.
Многие программисты сравнивают написание кода с творчеством, а значит, каждый шаг требует особенного подхода. Знаменитую пословицу «семь раз отмерь – один отрежь» можно перефразировать специально для программеров «Семь раз прикинь — один напиши».
Но и усердствовать в планировании не стоит. Все равно составить идеальный четкий план не получится. Важно продумать несколько последующих элементов, чтобы обеспечить себе пошаговое продвижение в построении качественного кода.
Правило № 2. Качество превыше всего
Часто начинающие программисты, сосредоточившись на количестве строк в коде, забывают о его качестве. А ведь очень важно, чтобы код был читабельным.
Профессионалы советуют избегать длинных строк при кодировании, ведь строчка, длина которой превышает 80 символов, вызывает затруднения. Не получается самостоятельно «подчистить» код? Воспользуйтесь, например, ESLint.
Не забывайте про длину функций. Попробуйте разбить их на мелкие и понятные части. Разбивая длинный код на короткие части, ни на минуту не забывайте о читабельности.
Правило № 3. Первое решение – не всегда правильное
Первые трудности, возникающие у новичков при создании программы, чаще всего заставляют хвататься за первое решение, которое приходит в голову. Многие из нас, желая сэкономить время, просто ленятся обдумать проблему со всех сторон. Поспешишь – людей насмешишь. Сколько программистов вспоминает эту народную мудрость, когда в один не очень прекрасный день выясняется, что скорое решение оказалось не таким уж и хорошим, и вам опять приходится возвращаться к прежнему проекту.
Профессиональные программисты рекомендуют изучить проблему со всех сторон и подобрать не быстрое, а простое и наиболее оптимальное решение, которое легко воплощается в жизнь, эффективно работает и несложно поддерживается.
Правило № 4. Признавать ошибки не страшно
«Сдаются только слабаки» — очень часто подобные мысли приходят в голову молодым программистам, когда на пути решения определенной задачи они вдруг понимают, что выбрали не лучший вариант. Но менять решение вроде как поздно, потому что уже потрачено много времени и сил.
Опытные программисты настойчиво рекомендуют начинающим коллегам не стесняться отказываться от одного решения в пользу лучшего варианта. Не стоит цепляться за неудачный код из-за жалости — забудьте о нем без сожаления. В похожих ситуациях вам поможет сервис контроля версий Git, позволяющий экспериментировать с различными вариантами решений.
Правило № 5. Гугл знает все
Если ваши разработки не касаются новейших сверхсекретных технологий, то, скорей всего, аналогичные вопросы возникали и до вас. Нет ничего страшного, чтобы спросить у Гугла, как разрешить ту или иную задачу. Поиск может вам выдать несколько неожиданных вариантов, о которых вы даже и не подумали. Единственный минус, который подстерегает любителей постоянно советоваться с Гуглом, это бездумное копирование «рекомендаций». Профессионалы утверждают, что использовать код, подсказанный поисковиком, следует только тогда, когда вы сами его понимаете от начала и до конца.
Правило № 6. Не включать фантазию
Мы уже говорили, что программирование часто сравнивают с творчеством, поэтому при написании нового кода начинающие программисты могут поддаваться соблазну поэкспериментировать, воплотить фантазию в реальность и т д. Нет, нет и еще раз нет! Пишите только тот код, который вам понадобится здесь и сейчас. Не тратьте драгоценное время! В конце концов «Рост ради роста – это идеология раковой клетки» (американский философ Э. Эбби).
Правило № 7. Изучай структуры данных
Заучивать алгоритмы – это, конечно, хорошо, но вряд ли банальная зубрежка алгоритмов прибавит креатива программированию. Намного эффективнее изучать разнообразные структуры данных того языка программирования, на котором вы пишите программы. Как ни странно, но именно изучение структур улучшает ваши навыки разработчика — доказано профессионалами. А вот неуместное использование структуры сразу выдает вас с головой и становится ясно, что над кодом работал новичок.
Правило № 8. Не ухудшай
Представьте, что вас поселили в комнату, где царит грандиозный бардак. Мало того, что в комнате хаос, так вам надо там еще и свои вещи разложить. Проще всего, конечно, не обращать внимания на разбросанные предметы, а быстренько разложить все свое поверх бардака. Таким образом, вы только увеличите захламленность комнаты. Гораздо эффективней организовать генеральную уборку: аккуратно разложить разбросанные вещи по местам, а потом уже расставить свои. В результате в вашей комнате будет порядок и чистота. То же самое с кодами — лучше сделать лучше, чем хуже.
Профессионалы выделяют несколько распространенных ошибок, которые ухудшают код:
- Дублирование;
- Пренебрежение файлом конфигурации;
- Наличие множества условных операторов и временных переменных.
Правило № 9. Не пренебрегайте тестами
Считаете себя экспертом в области программирования, которому не нужны тестирования кода? Поздравляем! Вы – самый яркий представитель новичков-программистов.
Даже если вы не пишите тест для вашей программы, то все равно вы ее тестируете вручную. Самый простой пример — обновление страницы после написания нескольких новых строк в код. Это делается хотя бы для того, чтобы определить, как писать автоматический тест.
Любой успешный проект будет постепенно расти, и однажды, вы просто-напросто забудете проделать очередной тест. Так зачем рисковать? Пусть система делает это за вас. Тest-driven development, TDD и многие другие методики тестирования помогут вам в этом. К сожалению, не все они подходят под конкретные проекты, но если есть возможность прибегнуть к помощи этих сервисов, то обязательно их используйте.
Правило № 10. Сомневаться – это правильно
Опытные программисты любят повторять, что если код работает, то это все равно не значит, что он хороший. Исходя из личной практики, практически каждый разработчик утверждает, что однажды он сталкивался с тупым кодом. Интересно, но «тупость» кода новичок вряд ли заметит, а если и заметит, то сразу усомнится — а стоит ли что-то менять, если все и так нормально работает, к тому же достаточно давно?
Самое ужасное, что новички, глядя на тупой код, будут уверенны в его эффективности и попытаются применять его в дальнейшей работе. Профессионалы советуют подвергать сомнению любой недокументированный код, который вам непонятен. Не бойтесь изучить его или расспросить о нем у коллег. Не используйте непонятный код до тех пор, пока вы сами не разберетесь в нем.
И, наконец, не гонитесь за внедрением «лучших практик». Мир программирования настолько быстро развивается, что сегодняшние лучшие практики уже завтра станут «тупыми». А вы сами, разбираясь в каждом коде, сами сможете стать основателем «лучшей практики». Главное — не забывайте про отдых и следуйте представленным десяти правилам, чтобы получать от программирования только удовольствие.
