Sergei721
На ваш взгляд, стоит ли указывать параметры, которым передаются значения (если имена переменных и параметров совпадают)?
Да, стоит, потому что они не совпадают, а они очень похожи, до идентичного вида. То есть мы считаем, что они не одинаковые, а что они очень-очень похожи.
Sergei721
Один из коллег говорит, что прям необходимо вызвать как для sql_create_rw.
Молодец! Значит, он правильные книжки читал, которые не читал ты ещё пока что.
Это не пустой звук.
Sergei721
Какой вариант вызова вы бы выбрали sql_create или sql_create_rw (метод вызывается 1 раз)?
Ломай себе мышление, если мыслишь неправильно и нужно доучиваться. Доучивайся, не ленись. Переучивайся, если надо, хоть десять раз. Это поможет.
Почему нужно это делать? Потому что зависимости - это страшный враг. Чем их больше, тем хуже. Если у тебя один кусок кода зависит от другого куска кода, это плохо. Если ты можешь не делать зависимости, не делай её.
Ты сделал на пустом месте зависимость, которая звучит так “эти аргументы одинаковые”.
Почему вызывание один раз не аргумент? Потому что код - это живая материя. Он не фиксируется, когда ты его написал, он продолжает жить дальше. И когда он живёт, он растёт в разные стороны, растекается, как вода. И если он может потечь в плохую сторону, то он это начнёт делать. Ну как, если ружьё висит на стене, то оно обязательно когда-нибудь выстрелит и обязательно в это время в него кто-то будет заглядывать, хотя сейчас оно висит на стене и не стреляет и всё нормально. Соответственно, если там может появиться второй, третий, десятый вызов, он там появится. Мы так думаем, когда пишем. Поэтому у нас всё готово к тому, чтобы код разрастался. Когда он будет разрастаться, ничто не даст ему уйти в ненужную сторону. Например, сейчас ты считаешь, что эти аргументы одинаковые и вызов только один, поэтому ты не замечаешь, в чём может быть проблема. Но когда ты пишешь много программ разных и они все похожи друг на друга, ты всё чаще и чаще начинаешь улучшать программы, приходит такой навык (ты часто просто берёшь и переписываешь какой-то маленький кусочек, не смотря на всю остальную программу вокруг него, просто потому, что так надо, потому что этот кусочек вот нужен вот таким, так будет лучше). Например, ты какую-нибудь хрень, которую написал раньше, начинаешь переписывать во что-нибудь красивое сегодня, и это улучшает код (сокращает его, проясняет его, уничтожает в нём зависимости и так далее). И вот когда ты его переписываешь, вот эти имена начинают меняться на более конструктивные, вот эти вызовы начинают дополняться другими вызовами или раскладываются на несколько вызовов, более гибких и используемых. И вот в эти моменты ты уже давным-давно не помнишь, что когда-то ты полагался на одинаковость этих имён или на одинарность этих вызовов. А если этот код вообще не твой и ты его разрабатываешь дальше после кого-то (кого ты даже мог не знать никогда, просто код тебе достался), то ты даже не в курсе, на что там человек полагался, когда писал его.
Что такое зависимость и в чём её хрень? Вот в данном участке кода
Sergei721
def check_qa(
table_name: str,
segment: str,
columns: str,
primary_key: str,
hash_id: str) -> str:
sql_create = self._create_table(columns, primary_key, hash_id)
sql_create_rw = self._create_table(columns=columns, primary_key=primary_key, hash_id=hash_id)
Например, тебе понадобились другие имена в сигнатуре функции. Почему другие? Почему такие? Ну, потому что.
Не table_name, а просто name.
Не primary_key, а просто key.
Не hash_id, а просто identificator.
Вот ты через IDE автоматически поменял эти имена
def check_qa(
name: str,
segment: str,
columns: str,
key: str,
identificator: str) -> str:
sql_create = self._create_table(columns, key, identificator)
Что произошло с вызовом self._create_table()? Он просто стал неясным. Из новой версии вызова неочевидно, есть в нём ошибка или нет в нём ошибки. Ты просто поменял имена на такие, какие
тебе надо и ты уже из-за этого потерял какой-то кусок ясности, который был раньше. Раньше он полагался на то, что имена одинаковыми будут и всё будет понятно, а теперь стало, что в вызове self._create_table() стало всё непонятно. Надо вспоминать, где какой аргумент, а передаются ли они правильно, а на своих ли они местах. Вот это происходит из-за появившейся неясности. И ты тратишь время на это мышление, мозги устают на сотнях таких строк и ты меньше прорабатываешь кода, потому что просто мозги устают от него. У тебя появляется потребность чаще отдыхать и так далее, прокрастинация там и прочая хрень.
Другое дело, когда там именованные аргументы используются
def check_qa(
name: str,
segment: str,
columns: str,
key: str,
identificator: str) -> str:
sql_create_rw = self._create_table(columns=columns, primary_key=key, hash_id=identificator)
Он как был читаемым и ясным, так он и остался читаемым и ясным. И ты видишь точно, что ошибок нет. Думать ни о чём не надо, проверять по новой ничего не надо, ты продолжаешь работать над кодом. При этом ты поменял имена так, как
тебе надо.
И ты можешь ещё десять раз их менять, это ничего не нарушит. А эти десять раз ещё потребуются, потому что код - это живая материя. Когда-то у тебя есть программа, потом её куски перетекают в другую программу, в той другой программе эти куски начинают расти в другие стороны. И вот то, насколько твой код приготовлен к такому росту, который бывает полностью непредсказуем, и определяет его качество, а качество кода определяет твою дальнейшую работу с этим кодом. Если с твоим кодом легко работать, с тобой будут работать. Если ты весь такой умный сидишь и пишешь свою самоуверенную хрень какую-то, то ты будешь сидеть один и никому не будешь нужен со своим таким вумным и очень гениальным кодом. Даже обгоняя себя самого - а это происходит, когда ты постоянно учишься дальше - ты будешь замечать про свой собственный код, что он пригоден только для того, чтобы его выбросить. Ты не сможешь дорабатывать свой собственный код даже, потому что ты будешь спотыкаться на каждом таком моменте. Тебе надо будеть менять имена, а ты будешь сидеть и думать “блин, вот я тупой был полгода/год/три назад, нахреначил зависимостей, теперь имена поменять нельзя без переделки половины кода”.
tags: refactoring