Хочешь уверенно проходить IT-интервью?
Мы понимаем, как сложно подготовиться: стресс, алгоритмы, вопросы, от которых голова идёт кругом. Но с AI тренажёром всё гораздо проще.
💡 Почему Т1 тренажёр — это мастхэв?
- Получишь настоящую обратную связь: где затык, что подтянуть и как стать лучше
- Научишься не только решать задачи, но и объяснять своё решение так, чтобы интервьюер сказал: "Вау!".
- Освоишь все этапы собеседования, от вопросов по алгоритмам до диалога о твоих целях.
Зачем листать миллион туториалов? Просто зайди в Т1 тренажёр, потренируйся и уверенно удиви интервьюеров. Мы не обещаем лёгкой прогулки, но обещаем, что будешь готов!
Реклама. ООО «Смарт Гико», ИНН 7743264341. Erid 2VtzqwP8vqy
Чтобы от программного кода не отмахивались собеседующие или коллеги, он должен быть удобоваримым. Как написать «конфетку», которая понравится всем?
Роберт Мартин когда-то сказал, что единственным допустимым измерением качества кода является «Что за…».
Позвольте объяснить. Всякий раз, когда на глаза попадается какой-либо код, возникает одна из трех эмоций:
- «Что за…», произнесенное с отвращением – этот код вообще не нужен.
- «Что за…», выражающее восхищение – «Эй, а ведь этот парень действительно крут!»
- «Что за…» с раздражением – в представленном коде невозможно разобраться.
Так что отвечает за реакцию на код? Это чистота кода. Писать чистый и предельно понятный код – признак настоящего профессионала. Как этого добиться?
Такое мастерство создано из двух главных составляющих: знания и работы. Знание учит вас шаблонам, принципам, практике и эвристике, которые необходимы для постоянного совершенствования. Но это знание должно быть подтверждено практикой, без которой оно попросту не будет закрепляться.
Так что красота программного кода – это не так уж просто, и если собеседующему что-то не понравилось, не расстраивайтесь: помните, что это все придет с опытом. В этой статье мы собрали десять принципов по-настоящему хорошего кода.
«Могу ли я узнать ваше имя?»
В программировании имена повсюду. Мы называем функции, классы, аргументы, пакеты и т. д. Иногда мы думаем что-то вроде: «И так понятно, что text – это текстовое поле. Зачем мудрить?» Однако взглянув на код или часть программного кода через неделю, две или месяц, натыкаемся на абракадабру, в которой непонятно что непонятно за что отвечает.
Допустим, вы написали небольшую графическую часть на Java. Что можно сказать о происходящем из представленного ниже программного кода?
setTitle(text1);
setSize(550,360);
setVisible(true);
text2.setEditable(false);
try {
List<String> text = Files.readAllLines(Paths.get("text.txt"));
name = text.get(0)+":";
name2.setText(name);
} catch (IOException e) {
e.printStackTrace();
}
В коде происходит нечто странное. Давайте немного изменим его:
setTitle(title); //Здесь мы видим заголовок
setSize(550,360);
setVisible(true);
textAreaMessage.setEditable(false); //Здесь уже JTextArea, etc.
try {
List<String> mass = Files.readAllLines(Paths.get("text.txt"));
name = mass.get(0)+":";
labelName.setText(name);
} catch (IOException e) {
e.printStackTrace();
}
Имя любой переменной, функции или класса должно отвечать на три вопроса: зачем это нужно, что делает и как используется. Выбор хороших имен поначалу требует времени, но в дальнейшем вы сэкономите намного больше. Тщательно подбирайте названия, и все, кто прочтет ваш код, будет вам благодарен.
Не бойтесь разбивать код на составляющие
Луис Салливан как-то сказал: «Форма следует за функцией».
Помните, что методы – это глаголы языка программирования, а классы – имена существительные. Не старайтесь делать методы огромными, включающими в себя все на свете. Будет гораздо понятнее, если вы разобьете класс на несколько методов. Так вы не запутаетесь в собственном коде, и другие люди его тоже поймут.
Небольшой пример-визуализация сказанного. Работа со слушателем:
buttonSave.addActionListener(new ActionListener() {
@Override
public void actionPerformed(ActionEvent e) {
buttonLogin();
}
});
Просто выносим функцию нашей кнопки в отдельный метод:
protected void buttonLogin() {
System.out.println("Вот так будет намного удобнее :)");
}
Комментирование программного кода
Это особенно важно, если вы новичок или пишете действительно большую программу, к которой придется возвращаться снова и снова. Если вы оставите код без единого комментария, рискуете не понять его спустя некоторое время.
Также это большой плюс при приеме на работу. Выполняя ТЗ работодателя, не забывайте комментировать код: так вы показываете свою серьезность и умение писать код, понятный для всех.
Комментировать можно строку или несколько строк, выделяя таким образом часть программного кода. Например, я всегда вывожу размещение элементов в своеобразный блок:
/*** Расположение элементов ***/ panel.setLayout(new GridBagLayout()); GridBagConstraints c = new GridBagConstraints(); c.gridx = 0; c.gridy = 0; panel.add(labelQuestion, c); c.gridx = 0; c.gridy = 1; panel.add(labelSpace, c);
А вот вариант объяснения одной из строк:
FileWriter writer;
try {
writer = new FileWriter("text.txt", false);
writer.write(textName.getText());
writer.flush(); //Финализирует выходное состояние, очищая все буферы вывода
} catch (IOException e) {
e.printStackTrace();
}
Удобно, правда? Работодатель или напарники по проекту будут того же мнения.
Минимализм vs информативность
Нет, от сокращения имен код не станет проще: это лишь сделает его запутанным и непонятным. Отсутствие комментариев также будет недостатком. Но есть еще ряд приемов, которые заметно уменьшат код. К таким приемам относятся:
- Удаление лишних проверок и условий.
- Избегание дублирования.
- Умение пользоваться конкретным языком программирования.
С первым пунктом вроде все понятно, но давайте проясним. К ненужным проверкам относится в т. ч. проверка на null. Иногда это даже попахивает паранойей. Например:
obj = new Object();
...
if (obj != null) {
obj.call();
}
А порой одно и то же условие проверяется несколько раз, словно что-то могло измениться без нашего вмешательства (разумеется, это не относится к коду, с которым действительно происходили соответствующие метаморфозы).
Дублирование – бич начинающих программистов. Из этого пункта вытекает и третий, ведь если человек знает все тонкости языка, он не станет намеренно увеличивать количество строк. Но странно то, что часто такие требования предъявляются именно новичкам, у которых просто недостаточно опыта, чтобы хорошо разобраться во всех тонкостях, например, ООП. Подобное исправляется лишь регулярной практикой.
Рекурсия – не панацея
Многие считают рекурсию лучшим средством для устранения всего лишнего. Если говорить о внешнем виде программного кода, это, несомненно, правда. Пример с факториалом:
public static void factorial() { //итерация
int fact = 1;
int n = 5;
for (int i = 1; i<=n; i++){
fact*=i;
System.out.println(fact);
}
}
static int factorial(int n){ //рекурсия
int res;
if (n == 1) return 1;
res = fact(n-1)*n;
return res;
}
Да, в этом случае код и там, и там маленький, но если прибавить кучу условий и строк – все изменится. Например, вот рекурсивное решение ханойской башни:
public static void hanoi(int n, String a, String b, String c){
if (n == 1) System.out.println("#" + n + " " + a + " -> " + c);
else {
hanoi(n - 1, a, c, b);
System.out.println("#" + n + " " + a + " -> " + c);
hanoi(n - 1, b, a, c);
}
}
А теперь вообразите, сколько строк выдаст новичок, столкнувшийся с ханойской башней и работающий только с итерацией :)
Но не все так гладко. Попробуйте посчитать факториал большого числа. Вероятно, IDE зависнет, пытаясь переварить ваше решение, и это понятно: рекурсия «кушает» много памяти, так как метод каждый раз вызывает сам себя. Конечно, если в поставленной задаче рекурсия необходима (например, при обработке древовидных структур), использовать ее нужно, но ни в коем случае не злоупотреблять. Компактность-то она обеспечит, но что потом делать с памятью?
Не бойтесь перемен!
Здесь собраны очень простые рекомендации, о которых знает каждый, вот только далеко не каждый их использует. Допустим, вместо «многослойных» if-ов можно использовать оператор (x ? y : z).
Пример с if:
if (x) {
var1 = y;
} else {
var1 = z;
}
Пример с (x ? y : z):
var1 = x ? y : z;
Также не забывайте о существовании forEach(), который избавит вас от претензий в стиле «Многа букав»:
public static void forEach(){
int [] mas = {1, 2, 3, 4, 5};
for (int i : mas){
System.out.println(i);
}
}
Объединяйте вложенные if. Посмотрите, насколько проще становится код.
Было:
if (a) {
if (b) {
do_something();
}
}
Стало:
if (a && b) {
do_something();
}
Поговорим о боли под названием «try-catch»
Читаемость кода часто усугубляется повсеместными блоками try-catch, которые сильно портят «картинку». Кроме того, по мере чтения такого программного кода теряются цель и логика происходящего в нем. А все должно быть предельно понятным, особенно для стороннего человека. Правильно обрабатывать возможные ошибки – признак настоящего мастерства.
Да, блоки try-catch напрямую влияют на объем вашего кода. Да, полностью избавиться от этого нельзя, но можно свести к минимуму строки внутри такого блока, вынеся все остальные за его пределы. Но если такое дробление будет подразумевать создание еще большего количества try-catch – лучше обойтись без подобных экспериментов.
Еще исключение может обрабатываться где-нибудь внизу метода, не царапая глаз в середине кода.
Логирование
Не пренебрегайте лог-файлами! Эти «ребята» всегда помогут в создании и сопровождении вашего будущего ПО, ведь на поиски и обработку ошибок будет уходить гораздо меньше времени.
Вспомните ситуации, когда один из элементов приложения не работал или обрабатывал что-то непонятным образом, а что за причина – неизвестно. С лог-файлом время поиска проблемных участков сократится в разы.
Да, такие файлы предназначены для более сложных проектов, и в каких-нибудь Hello-world-программах просто не нужны. Но если вы разрабатываете приложение вдвоем или командой, либо это тестовое задание на допуск к собеседованию – займитесь логированием: интервьюер будет впечатлен, а команда – лишена необходимости переворачивать весь код вверх тормашками в поисках ошибки.
Тестирование
Юнит-тестирование (или модульное тестирование) – еще одна составляющая хорошего программного кода, которая заставит помучиться. Зато в итоге вы сможете запросто проверять на правильность отдельные модули.
Суть в том, что вы пишете тесты для каждой функции, которая не относится к тривиальным и составляет костяк программы. С юнит-тестами можно проверить, к чему приведут последующие изменения в коде.
Используйте бейджики качества кода
Часто в файлах README можно наблюдать небольшие иконки. Что же там делают данные графические элементы? Это бейджики, которые показывают, насколько хорош код. Зачастую используются либо перфекционистами, либо в серьезных проектах, но если даже незначительный по важности код прошел такую проверку – это огромный плюс.
Где получить бейджик? Для этого существуют специальные сервисы. Например, мне нравится Travis CI, предназначенный для сборки и тестирования ПО. Он использует в качестве хостинга GitHub, куда и коммитится проект, так что никаких проблем с привязкой Трэвиса к проекту нет.
Поначалу сложно понять, почему же сервис ругается и не пропускает код, но когда вы поймете, дальнейшее сотрудничество с сервисом пойдет как по маслу.
Комментарии