Как научиться писать код быстро

На портале Tproger опубликован опрос, в котором ИТ-специалисты поделились своими секретами быстрого и качественного написания кода. Комментарий для материала дал Виталий Филиппов, наш разработчик-эксперт. Умение быстро писать код — залог успеха программиста? Почему иногда удалить часть кода важнее, чем написать? Так ли незаменимы IDE и фреймворки? Об этом — в материале «Как научиться писать код быстро» на сайте издания.

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

Вопросы на собеседованиях типа «что делает вот эта функция» хоть и выглядят глупо, но проверяют именно то, что вы, имея опыт работы с каким-то языком, должны обязательно помнить. Ясно, что все в конечном счете можно загуглить, но вот этот гуглеж и тормозит процесс.

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

Еще я верю: чтобы писать код быстро, желательно использовать инструменты, которые позволяют писать его меньше, а тестировать быстрее. Это в целом очень полезно, так как меньший объем кода снизит его сложность для того, кто будет с ним разбираться в следующий раз. Если кто не понял, это камень в огород любителей большого числа слоев и объектной ориентированности :-) Ну и в адрес авторов Bitrix-like простыней на 3000 строк кода без единой функции, конечно, тоже. Самое приятное занятие — это не написать кусок кода, а удалить кусок кода, сохранив функциональность.

Кроме того, чтобы быстро писать код, иногда его лучше вообще не писать. Потому что лишний груз часто тормозит быструю разработку. Легко затащить на борт кучу красивых технологий и потом удивляться, почему все стало так сложно. Легко начать делать фактически необязательные фичи «на потом» или зарыться в другую ненужную задачу и в результате не доделать нужную. Чтобы избежать всего этого, надо следовать простому правилу: если вы не на 100 % уверены в необходимости чего-либо (фичи, технологии, фреймворка, сервера авторизации), то без этого можно и нужно обойтись. Тащить что-то на борт нужно только тогда, когда вы уверены, что без этого никак. Потому что затащить легко, а вот выкинуть потом гораздо сложнее.

А еще ваша IDE, которая пытается услужливо додумывать за вас, скрывать типы, по одному нажатию клавиши генерировать простыни кода — не помощник, а враг. Простыни никуда не денутся, хоть вы их и не будете писать руками. А вы в итоге станете зависимыми от IDE и перестанете помнить, где что лежит. В конце концов, самые хардкорные парни, например разработчики ядра Linux и системного софта типа Ceph, пишут код в Vim. При этом в коде ядра даже практически нет документации. Почему этим парням не нужна IDE? Да просто потому, что они и так помнят все, что им нужно. Поэтому они и круты.

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

В общем, практика и знания, по-другому никак!