Вы когда-нибудь получали гигантский блок текстового сообщения или электронного письма от кого-то, в котором вообще не было абзацев?
Насколько сложно было собрать что-то с трудночитаемыми, плохо написанными инструкциями?
Сравните это с тем, кто щедро использует абзацы для организации и разделения своих мыслей или одной из самых удивительных и простых инструкций, которые вы когда-либо читали. Усвоение информации менее утомительно, верно?
Кстати говоря, многие программисты, даже опытные, делают так называемое «кодирование по совпадению» или «кодирование методом проб и ошибок». То есть: они одновременно пытаются понять проблему, придумать решение и кодировать его на лету.
К сожалению, большинство программистов также думают, что они «сделали», когда приложение заработало и оно соответствует требованиям. Однако это только одна часть из многих целей, которые программисты должны иметь в отношении своей задачи.
Помимо того, что код «работает», он также должен легко читаться и поддерживаться.
Когда программисты пишут по стечению обстоятельств или методом проб и ошибок, код, как правило, выглядит точно так же: гигантский кусок текстового сообщения или руководства по эксплуатации, который выглядит так, как будто он был переведен Google без корректуры.
Когда код нелегко читать, он может быть неправильно истолкован, и позже в него могут быть легко внесены ошибки. Кроме того, на освоение кода уходит много времени и денег.
Программист не «готов» после того, как он «заработал». Следующей целью должно быть вернуться к коду и реорганизовать его, чтобы сделать его более понятным.
Точно так же, как существуют методы написания для организации текста (использование абзацев, хорошие заголовки/подзаголовки, осторожное использование слов для уменьшения двусмысленности и т. д.), существуют также методы организации кода таким образом, чтобы его было приятно читать как для других, так и для других. товарищи по команде и будущее «я» автора.
Когда вся команда придерживается этой привычки, вы будете удивлены, насколько быстрее пойдет разработка программного обеспечения.
Две книги, которые отлично объясняют, как писать легкий для чтения/понимания и более удобный для сопровождения код, — это «Чистый код» Роберта Мартина и «Code Complete 2» Стива МакКоннела.
Кроме того, программисты должны избавиться от привычки кодировать методом проб и ошибок. Это выходит за рамки этого поста, но я расскажу, как это сделать, в статье Я ненавижу использование белой доски на технических собеседованиях.
Вы когда-нибудь возвращались к тому, чтобы сделать ваш код более легким для чтения и обслуживания? Как получилось в дальнейшем? Дай мне знать в комментариях!
