Эван Хан — разработчик, который работал на Signal и Airtable, автор нескольких библиотек и книг. Здесь собраны вещи, которые он считает важными для компьютерного программирования на сегодняшний день. Они основаны на его собственном опыте.
Как подходить к решению задач
Большая часть моей работы — это работа с тикетами, и я все еще пытаюсь стать лучше в этом. За время работы я научился нескольким вещам:
- Различные подходы для разных задач, команд и проектов. Например, было бы безответственно создавать кардиостимулятор без автоматизированных тестов. люди могут пострадать! Но также неправильно было бы напрягаться по поводу автоматизированных тестов во время игрового джема выходного дня. В разных контекстах «хороший код» означает разные вещи, и я должен подбирать свой подход в зависимости от конкретной проблемы.
- Сделайте «скачок». Иногда я пытаюсь реализовать функцию за минимально возможное время, используя ужасный код, ужасные хаки и множество TODO. Как только у меня что-то получается, я убираю это. Я обнаружил, что это полезный способ увидеть, где кроются проблемы, и довольно хороший способ быстро создавать вещи. См. «Выбросьте первый черновик вашего кода».
- Если я бьюсь головой о проблему, не добиваясь прогресса, мне следует сделать перерыв.
- Когда передо мной стоит сложная задача, я спрашиваю себя: «А что, если бы я вообще этого не делал?». В большинстве случаев это глупый вопрос, и мне приходится его задавать. Но в ~5% случаев я понимаю, что могу полностью пропустить какую-то работу.
Как проектировать программное обеспечение
Я никогда не разрабатывал крупномасштабные production системы с нуля, но я создал несколько значимых функций и построил несколько приложений среднего размера. Вот чему я научился на этом пути:
- Различие между понятиями «простой» и «легкий» очень важно. Простое — это противоположность сложному. Легкость — это нечто другое, она привычна. Понимание этого различия помогло мне разработать более простое программное обеспечение (хотя в этом направлении мне еще есть над чем работать). См. статью «Простота — это легко».
- Сделайте недействительные состояния непредставимыми. Если я могу спроектировать свои данные/типы так, чтобы предотвратить недействительные состояния, это устраняет большой источник ошибок. Небольшие мучения с системой типов или схемой базы данных обычно стоят того.
- Тестируемость — это, по сути, то же самое, что и модульность.
- Люди, занимающиеся функциональным программированием, могут быть весьма самодовольны, но они часто правы. Сложнее сделать хорошую работу с объектно-ориентированным программированием и проще — с функциями, которые работают с неизменяемыми данными.
Тонкости программирования
Эти убеждения я использую в своем редакторе кода:
- Существует множество способов документировать мой код. Некоторые идеи — явное документирование; хорошие имена для функций и переменных; разбиение участков кода на именованные функции; комментарии; сообщения в логе.
- Используйте положительное именование переменных. Такие переменные, как
use_widget, лучше, чемskip_widget, потому что они помогают избежать путаницы с двойными отрицаниями (я видел, как такая путаница приводила к значительным ошибкам безопасности). - Избегайте переименования идентификаторов. Если у меня есть переменная
photo_id, называйте ееphoto_idвезде, даже еслиidможет иметь смысл только в контексте. - Вместо булевых значений используйте перечисления. Они могут быть более понятными и расширяемыми. Смотрите «Не используйте булевые».
- «Выучить X за Y минут» — отличный ресурс для быстрого изучения основ языков программирования (и некоторых других вещей).
- Коды состояния HTTP не стоят того, чтобы над ними ломать голову. Например, есть разница между кодами состояния 401 «Неавторизованный» и 403 «Запрещенно», но это различие никогда не имело значения для моей работы; компьютеру обычно все равно. Иногда есть важные различия, например, разница между 301 «Перемещено постоянно» и 307 «Временное перенаправление», но обычно они довольно очевидны. Если на выбор кода статуса уходит больше минуты, я беспокоюсь.
- Попробуйте использовать инструменты, которые уже есть, прежде чем искать новые. Вместо того чтобы устанавливать модный пакет Zsh, посмотрите, можно ли установить
$PROMPTи быть счастливым. Вместо того чтобы устанавливать зависимость, посмотрите, есть ли в стандартной библиотеке что-то подобное. - Настройка системы имеет ограниченные преимущества. Очень весело настраивать свои дотфайлы, выбирать идеальный редактор и настраивать свою систему разработки. Но я не думаю, что это сильно экономит время. Есть несколько отличных инструментов, которые помогают, и настройка может быть отличным способом узнать, как все работает. Но выбор правильной цветовой схемы обычно не влияет на продуктивность, и я не заметил корреляции между «хорошим программистом» и «заботящимся о своем редакторе». (…тем не менее, это весело, и я часто этим занимаюсь!)
Межличностные отношения
Ах да, другие люди.
- Проблема «одинокого разработчика»: когда программист-одиночка создает что-то, другим часто бывает сложно поддерживать это в дальнейшем. Похоже, это касается всех, в том числе и меня. Я написал более длинный пост об этой идее.
- Простые мнения, как правило, ошибочны. Например, некоторые люди говорят что-то вроде: «PHP — отстой!»… но на PHP работает большая часть интернета, а современный PHP имеет кучу отличных функций. Люди, которые догматично относятся к процессу, например TDD, обычно правы в одних ситуациях, но ошибаются в других. Мне обычно нравится работать с программистами, которые понимают нюансы и компромиссы, и я сам стараюсь быть таким программистом.
- Все оказывается сложнее, чем вы ожидаете. Я должен быть осторожен, чтобы не приуменьшить чью-то работу, потому что она, вероятно, намного сложнее, чем я думаю. Создать прототип гораздо проще, чем что-то серийное.
Высокий уровень/карьера
Я думаю, что наиболее важными были вещи высокого уровня.
- Самые важные проблемы — нетехнические. Много лет назад я прочитал отличный пост об этом. Вопросы «реального мира», как правило, наиболее важны. Создаю ли я что-то, что помогает людям или вредит им? Здорова ли моя команда?
- Набирать новый код — это, как правило, самая легкая часть работы. Более серьезные проблемы: чтение кода, расстановка приоритетов, коммуникация, динамика команды и т.д.
- Создание бесполезных вещей может быть отличным способом научиться чему-то новому. Не все должно быть полезным, но иногда это может получаться само собой! Например, я потратил кучу времени на написание пользовательского кодировщика PNG для одного из побочных проектов. Я никогда не думал, что это будет полезно. Но через несколько месяцев мне понадобилось написать код для обнаружения анимированных данных в PNG для работы, и это оказалось тривиальным, потому что я точно знал, как это сделать.
- Важно, для кого я создаю. Человечество в беде. Неполный список проблем: изменение климата, войны, авторитаризм, геноцид, бедность, неравенство, слежка. Я не должен тратить свое время на создание программного обеспечения для людей, которые причиняют людям боль. Я не должен тратить свое время на создание программ, чтобы сделать босса богатым, даже если я сам босс. Есть много работ, где я могу использовать свои навыки, чтобы помочь людям… Я должен работать там, если смогу!
Интересно, буду ли я по-прежнему верить в эти вещи через год или через десять… но это то, во что я верю по состоянию на июль 2024 года.