Век программируй, век учись

В программировании приходится учиться методом проб и ошибок. Далее я расскажу о 9 важных уроках из своего непростого личного опыта.

1. Как раз самых дешевых, быстрых и надежных компонентов никогда и нет 

Эти слова принадлежат Гордону Беллу. Из чего следует вывод, что необходимо поддерживать систему или часть ПО максимально простыми. Уменьшение сложности приводит к снижению числа ошибок. 

Хорошо известный принцип программирования KISS, сформулированный в ВМС США, утверждает то же самое: 

Чем проще системы и чем меньше усложнений они претерпевают, тем лучше большинство из них работают. Поэтому основной целью в проектировании должна стать простота, а вместе с ней и предотвращение ненужной сложности. 

Сложность проявляется по-разному. Прежде всего, при создании системы следует тщательно подходить к подбору необходимых компонентов. Например, если вы работаете и с MongoDB, и с Elasticsearch, то лучше выбрать одну из них ради уменьшения количества составляющих элементов. Таким образом вы не только снизите затраты на обслуживание, но и ограничите число компонентов, способных выйти из строя. Всегда обращайте внимание на то, что можно объединить или удалить. 

Основательно выбирайте пакеты, включаемые в код. Если вам нужна лишь одна функция из крупного пакета или зависимости, то целесообразнее будет реализовать или скопировать только эту самую функцию. 

2. Вуду-программирование

Порой после исправления ошибки для вас так и остается загадкой, из-за чего это произошло. Многие программисты побывали в таких ситуациях, и в этом случае нельзя оставлять все как есть. Убедитесь, что вы понимаете код. Выясните, почему данное изменение обернулось именно таким результатом. 

Такой подход научит вас намного большему, чем учебники. Отбросьте в сторону стеснения и консультируйтесь по необходимым вопросам. И в какой-то момент вы заметите, что сами стали тем, к кому обращаются за советом.  

Тот же принцип относится к скопированному и вставленному коду. Да-да, все мы иногда пользуемся Stack Overflow, в чем нет ничего плохого. Но если код вам не понятен, то не используйте его или попросите у кого-нибудь разъяснений. 

Процесс создания или применения кода, который выходит за рамки вашего понимания, попадает под определение вуду-программирования. А это бомба замедленного действия. 

3. Код никогда не лжет, в отличии от комментариев 

Комментарии играют важную роль, но по возможности лучше обходиться без них и писать более содержательный код. 

Зачастую в процессе изменения кода забывают про корректировку комментариев. Из чего и вытекает утверждение о том, что они лгут (т.е. ошибочны), поскольку относящийся к ним код изменился, а они остались прежними. 

Документировать код можно тремя способами.

1. Фиксировать комментарии в коде. 
2. Оформлять документацию в отдельном документе. 
3. Писать самодокументирующийся код. 

Рассмотрим последний пункт подробнее, поскольку именно это я подразумеваю под написанием содержательного кода.

• Используйте оптимальное проектное решение, тем самым обеспечивая логическую структуру базы кода и легкость навигации. 
• Не экономьте символы. Прописывайте полные имена переменных, классов и функций. Например, вместо wm назовите windowManager, а вместо rf  —  readFileToString. Такие имена становятся невероятно полезными, когда вы или ваши коллеги пробуете разобраться в коде спустя несколько месяцев после его написания. 
• Делайте функции максимально содержательными, и пусть они выполняют только одно действие. Называйте их в соответствии с их назначением. Например, создайте функцию для считывания файла в строку и дайте ей имя readFileToString(String fileName). Даже без детального изучения кода становится понятно, что он делает. По сути, идеальный код  —  это последовательность вызовов функций, подобных рассмотренной выше, которые написаны простым человеческим языком. И лишь при необходимости можно углубиться в детали. Вот что значит самодокументирующийся код! 

4. Регулярные выражения 

Столкнувшись с проблемой, некоторые приходят к мысли об использовании регулярных выражений и тем самым только удваивают количество этих самых проблем. 

Шутка, конечно, старая, но до сих пор верная. Регулярные выражения  —  это сплошная боль. Когда вы чувствуете, что наконец-то подобрали его верно для одного случая, оказывается, что для следующего оно подходит лишь на 70%. 

Я лишь выражаю свое личное мнение, но советую избегать регулярных выражений как чумы, за исключением тех случаев, когда без них никак не обойтись. Зачастую для выполнения задачи достаточно комбинации таких функций, как split, substring, endsWith, indexOf, в результате применения которых код становится более читаемым. 

5. ПО подобно храмам: сначала мы их строим, потом молимся

В эссе “Собор и базар” противопоставляются две разные модели разработки. Википедия описывает их следующим образом: 

“В соборной модели исходный код доступен с каждым новым выпуском ПО, но код, созданный между выпусками, становится прерогативой только ограниченного числа разработчиков. 

В базарной модели код разрабатывается через интернет у всех на виду. Линус Торвальдс, руководитель проекта разработки ядра Linux, считается изобретателем данного процесса”.

У обеих моделей есть свои достоинства и недостатки. Однако, согласно общепринятому мнению, процесс разработки ПО должен носить циклический характер, что предполагает постепенное добавление функциональностей. Конечных же пользователей желательно привлекать к участию уже на самых ранних этапах. 

6. Из трех вариантов — дешево, быстро, надежно — доступны лишь два 

Я в восторге от этого принципа, поскольку он вынуждает людей (менеджеров) думать самостоятельно.

• Вы хотите быстрой и надежной разработки? Без проблем  —  платите лучшим специалистам. 
• Склоняетесь в сторону дешевой и быстрой? Пожалуйста, но тогда нечего рассчитывать на ее надежность! 
• А как насчет надежно и дешево? Если повезет, то вполне возможно. Однако уйдет немало времени на поиск того, кто возьмется за дело на таких условиях оплаты, или потребуется множество циклов (а следовательно и времени) на то, чтобы довести все до ума. 

7. Два сложных момента в разработке ПО 

0. Именование процессов. 
1. Инвалидация кэша. 
2. Ошибки неучтенной единицы. 

Как правило, мы, люди, начинаем отсчет с 1, а компьютеры  —  с 0. Этот простой факт стал причиной множества багов и затруднений. Наверняка вы уже сталкивались с ошибками неучтенной единицы. Если же нет, то встреча с ними не за горами. 

8. Прежде чем перейти улицу с односторонним движением, хороший программист смотрит в обе стороны 

Лучшему ПО по силам все ошибки  —  именно все, и даже те, которые никогда не произойдут. 

Разработка большинства ПО нацелена на осуществление “идеального процесса”, при котором все работает по плану и пользователь не делает ничего экстраординарного. Но реальный мир далек от совершенства, и со временем то, что могло пойти не так, происходит именно таким образом. Попробуйте охватить как можно больше ошибок, особенно если ПО выполняет крайне важную функциональность. 

9. Оценивать результативность программирования по количеству строк кода  —  это как судить о качестве самолета по его весу 

Успех разработки не измеряется количеством строк кода. По этой же причине превосходство в объемах написанного кода не говорит о продуктивности. 

Наилучший код содержит минимальное число строк для выполнения задачи, и именно такой сложнее всего писать. Можно провести аналогию со следующим высказыванием: 

Будь у меня больше времени, письмо было бы короче. 

Написание краткого и эффективно работающего кода требует затрат времени и усилий. Как правило, приходится несколько раз проводить рефакторинг исходной базы кода, прежде чем приблизиться к наиболее оптимальному и читаемому варианту решения задачи. 

Благодарю за внимание! 

Читайте также:

• Реальный способ стать хорошим программистом
• Какой язык программирования учить в 2022 году?
• Scrum: 5–3–5–3–3

Читайте нас в Telegram, VK и Яндекс.Дзен

---

Перевод статьи Erik van Baaren: 9 Programming Life Lessons You Must Experience Yourself to Truly Understand