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

Вы можете принять / контролировать / отказаться от простых привычек, которые могут облегчить жизнь вам и вашим коллегам. Эта статья не зависит от какой-либо платформы или языка программирования.

1. Скопируйте и вставьте или скопируйте макароны

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

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

Если вы берете отрывок из справочной документации, форумов, статей, руководств, блогов разработчиков и т. Д., Вы получите двоякую выгоду от ввода кода, а не его копирования:

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

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

2. Размер имеет значение, но не так, как вы думаете

Я помню, как в начале 2000-х годов я читал рекомендации по добавлению кода в исходный код ядра Linux (из любопытства). Мои теперь любимые части казались мне довольно строгими для моей молодой университетской версии, поскольку в то время уже были графические среды разработки для Linux, но руководящие принципы заключались в поддержке тех (кого я представлял как волшебников с косматыми седыми бородами), которые все еще кодирую в Emacs или vi в терминале 80x24.

Правило было жестким 8 для вкладок, и ни одна строка кода не могла быть длиннее 80 символов. Вы можете спросить, осталось ли место, чтобы что-нибудь написать? Ну да, если вам нужно сделать отступы или вложить ваши управляющие структуры / блоки более 3 раз, это запах кода, что ваша функция, вероятно, слишком велика. И если вам нужно вертикально прокрутить большой объем, чтобы прочитать остальную часть функции, то, вероятно, следует разбить ее на большее количество функций.

Точность этого может показаться чрезмерной, поэтому давайте не будем останавливаться на деталях, но если вы извлечете доводы, стоящие за этим, это все еще актуально по сей день в современной разработке программного обеспечения. Я провел первую половину своей карьеры, не всегда прислушиваясь к этому совету, а вторую половину он улавливал. Возможно, вы не занимаетесь программированием ядра на C, но я обнаружил, что вы можете применить эти фундаментальные идеи к C ++, Objective-C, C #, Java, JavaScript, Ruby, Swift и т. Д. И добиться большего успеха.

Есть действительно простые вещи, которые вы можете сделать, чтобы помочь в этом. Например, с помощью столбцов вы можете отобразить поля в настройках редактора кода и указать, в каком столбце они будут отображаться. Точный момент, когда любая строка кода превысит этот предел, будет очевидным. Может быть, 80 - это слишком мало для некоторых разработчиков, но все, что больше 120, становится немного громоздким; если вы прокручиваете код и по горизонтали, и по вертикали, требуемые умственные усилия резко возрастут. Это неэффективно и может вызвать утомление. Держу пари, что никому не нравится прокручивать 220-символьную строку кода.

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

Для вертикальной прокрутки ни один метод или особенно блок не должны быть когда-либо настолько длинными, чтобы вы не были уверены, когда дойдете до конца. То же самое верно и для самого файла. Коллега однажды сказал мне, что файл из 400+ строк - это запах нарушения единого принципала ответственности (SRP) SOLID (или любого другого шаблона, который касается разделения задач). Если вы посмотрите на него, многие согласятся с этим пределом. Лично у меня нет жесткого ограничения, но я уже подумываю о рефакторинге чего-нибудь значительно большего, чем это.

3. Самодокументирующиеся имена

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

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

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

4. Согласованность пробелов

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

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

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

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

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

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

5. Чистота на ходу

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

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

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

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

6. Синтаксический стиль

У каждого свой стиль, но также у каждого языка программирования есть свой собственный стандарт де-факто или установленный стиль, с которым не следует иметь привычки бороться. Любые вариации мелких нюансов должны согласовываться в вашей команде разработчиков для единообразия. А сейчас самое время позвать меня / поиздеваться над моим примером Swift в разделах 2 и 4.

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

Архитектура

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

При разработке с использованием пользовательских интерфейсов использование таких парадигм, как MVC или MVVM, поможет вам отделить бизнес-логику от кода отображения и модели данных и наоборот.

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

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

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

Правоприменение

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

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

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

Заключение

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

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

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