Dev Easy Notes

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

Аргументная база у него была в виде ссылки на книгу “Чистый код”, в которой автор описывал почему нельзя сортировать методы по модификатору доступа. Суть “правильного” подхода заключается в том, что ты располагаешь методы по мере их использования. Например, делаешь метод public и если в нем есть метод private из этого класса, но ты располагаешь его сразу под public. Ну понимаете да, чтобы далеко не бегать когда код читаешь. Однако с современными IDE приватные методы можно располагать хоть в Саратове, все равно все проиндексируется.

Значительная часть аргументов касательно кода, сводятся к стилю: А вот X на конференции Y сказал что подход Й хрень и поэтому мы его использовать не будем. И чем более именитый докладчика тем больше ему верят. И казалось бы так делать не нужно, однако других вариантов у нас нет.  В IT нет базиса для аргументации. 

Вот допустим взять хардкорную инженерию, там все упирается в четкие физические параметры и законы, там все споры пресекаются на этом. У нас нет такого базиса. Точнее он есть, это CS, но тут обычно и споров то не возникает. Кто будет спорить что быстрая сортировка лучше пузырьковой? Поэтому вполне возможна ситуация, когда два могучих сеньора могут посраться из-за какой-то фигни и никогда не придут к консенсусу, ведь у одного опыт A у другого опыт B, а проверить на эксперименте, что лучше – потратить время команды впустую.

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

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

😁55👍31❤15🤔3

www.tgoop.com/dev_easy_notes/284

4.1K viewsNikita, edited  Feb 7, 2024 at 08:56

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

Аргументная база у него была в виде ссылки на книгу “Чистый код”, в которой автор описывал почему нельзя сортировать методы по модификатору доступа. Суть “правильного” подхода заключается в том, что ты располагаешь методы по мере их использования. Например, делаешь метод public и если в нем есть метод private из этого класса, но ты располагаешь его сразу под public. Ну понимаете да, чтобы далеко не бегать когда код читаешь. Однако с современными IDE приватные методы можно располагать хоть в Саратове, все равно все проиндексируется.

Значительная часть аргументов касательно кода, сводятся к стилю: А вот X на конференции Y сказал что подход Й хрень и поэтому мы его использовать не будем. И чем более именитый докладчика тем больше ему верят. И казалось бы так делать не нужно, однако других вариантов у нас нет.  В IT нет базиса для аргументации. 

Вот допустим взять хардкорную инженерию, там все упирается в четкие физические параметры и законы, там все споры пресекаются на этом. У нас нет такого базиса. Точнее он есть, это CS, но тут обычно и споров то не возникает. Кто будет спорить что быстрая сортировка лучше пузырьковой? Поэтому вполне возможна ситуация, когда два могучих сеньора могут посраться из-за какой-то фигни и никогда не придут к консенсусу, ведь у одного опыт A у другого опыт B, а проверить на эксперименте, что лучше – потратить время команды впустую.

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

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

BY Dev Easy Notes