пятница, 9 октября 2020 г.

Java и немного шарпа. А также спагетти код, всё, как вы любите!

 Собеседование Java

http://www.quizful.net/interview/java


Канал

https://t.me/javaproglib


Один и тот же вопрос

https://t.me/javaproglib/1279

http://www.quizful.net/interview/java/clone-and-cloneable


inellij

https://www.youtube.com/watch?v=yefmcX57Eyg


junior

https://youtu.be/bH3DBnxO4FA


Курс из 25 занятий по многопоточности в Java.

https://youtu.be/bjh1HWV9RRk


Уроки Java по самым сложным и продвинутым темам.

https://www.youtube.com/playlist?list=PL786bPIlqEjTO9pC06Phl7AtlH1wxyxgB


Еще более углубленный курс по Java - Java Beans, JMX, форматирование строк и другое.

https://www.youtube.com/playlist?list=PL786bPIlqEjQifz13w4nAE9d-53HW387n


Я уже говорил на некоторых лекциях, что не разделяю энтузиазма по поводу перехода с Maven’а на Gradle - в своих проектах я предпочитаю Maven. Сейчас, кстати, входит в моду Bazel - на него многие переходят или думают переходить, но тем, кто всё-таки делает свои проекты на Gradle, будет полезным посмотреть данный доклад, где рассказывается о подводных камнях этой системы - https://youtu.be/Yft6h7JkWo0


Доклад об устройстве JVM.

https://youtu.be/-fcj6EL9rc4

Никита Липский, Владимир Иванов — JVM: краткий курс общей анатомии


О возможностях IntelliJ IDEA для новичков.

https://youtu.be/mcvnjaLqVWQ


Топ-15 фишек IntelliJ IDEA.

https://proglib.io/w/56d0b690


Интересная статья о том, как написать полноценный мессенджер на языке C#: https://prglb.ru/3llw8




Vyacheslav Lapin:otus-teacher:  3:29 PM

vyacheslav.lapin@gmail.com


О структурном программировании


Посмотрел тут апреля этого года ролик SOER’а (https://youtu.be/7fblR__JVy4), которого очень уважаю, на тему структурного программирования. И отметил, что, в отличие от многих других его роликов, здесь у него явно слабоватая проработка в плане рефлексии. Решил это компенсировать, написал коммент, который, возможно, будет интересен и Вам, так что публикую его тут целеком:

Обычно у Вас более глубоко продуманные ролики. Давайте я Вам помогу отрефлексировать то, что Вы пытаетесь здесь сформулировать. Есть базовый закон диалектики, который в диамате деградировал до “закона перехода количаства в качество“, а в оригинале - у Гегеля - звучал как “По мере нарастания количественных изменений, происходят качественные переходы“. Вообще, в реальности количества и качества нет, это единая характеристика, их разделение - это элемент восприятия реальности технически-образованными людьми. С.Кара-Мурза в “Манипуляции Сознанием” упоминает - “Пастух хоть в Туркмении, хоть в тундре никогда не скажет, сколько у него овец или оленей, хотя знает их всех в лицо!“. И это разделение на кол-во и качество, хоть и даёт некоторые преимущества, но и недостатки содержит тоже, нивелируя фундаментальные отличия. Скажем, изба, многоквартирный дом и небоскрёб отличаются далеко не только кол-вом этажей, а много чем ещё другим.

Так же и здесь - если мы начнём измерять сложность программы в LOC’ах (Line Of Code), а поддерживаемость кодовой базы во времени выполнения типовой задачки по внесению нового функционала и правки баги, то эмпирически, пока Ваша кодовая база содержит до 500 LOC’ов - Вам СТОИТ использовать структурное программирование. Со всеми его GOTO и глобальными переменными - поддерживаемость от этого не пострадает. Это мы видим в, например, bash-скриптах и CMD или bat-файлах в Windows - абсолютно никаких проблем, даже GOTO есть! А всё потому, что редко до 500 строчек кода добираемся, обычно их там сотня-две, не больше.

Но как только Ваша кодовая база вырастает до 500 - переходим на процедурное - там с поддерживаемостью по-легче - уже примерно до 5'000 LOC’ов. Например, хранимые процедуры в Базах Данных - прекрасно в процедурном стиле живут, потому что на один tablespace их не бывает больше 5'000 строк (а если всё-таки накапливается - это становится болью и раздаются призывы, типа “Хранимки - зло и давайте всю логику перенесём на сервер приложений“). Кстати говоря, ORACLE переодически пытается добавить в хранимки элементы ООП, но сообщество не готово это воспринять - всё это проваливается.

В общем, превысили 5'000 LOC’ов - опять попа наступает - единое пространство имён, слишком много процедур - путаешься в них - и т.д. И вот тогда переходим к ООП. На самом деле, и ООП уже не устраивает - чистый ООП - это, следуя этому правилу, до 50'000 LOC’ов и многие Enterprise’ные программы давно уже этот предел превысили, и по-этому на самом деле сейчаас на чистом ООП уже не пишут - к нему примешивают более мощную парадигму - АОП, просто это не принято громко афишировать - по крайней мере настолько громко, как какой-нибудь Гради Буч и Алан Кей всех громко убеждали в преимуществах ООП. Ну не нашлось фигуры соответствующего масштаба для АОП-парадигмы, так что её просто стали использовать незаметно для себя многие и удивляться - как стало всё странно, как мы нарушаем чистоту языка и т.д... Например, в Java это Spring (Boot/Cloud) - он добавляет следование АОП-парадигме и только с ним можно поддерживать гигантские проекты в Enterprise’е - опять же до 500'000 LOC’ов.

А если и этого мало - тут нас перестаёт устраивать уже монолит и часто даже монорепозиторий - так что давайте переписывать всё на микросервисы...

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

Ну и, следуя этой логике, когда мы достигнем 5'000'000 LOC’ов, должна будет родиться новая парадигма. Лично я в этом отношении смотрю на тот подход, который выбрали в LinkedIn c Kafka’ой - они называют это “потоковая платформа” и в Java-мире этому пытается следовать, насколько я могу судить, Spring Cloud Data Flow. Но это пока в целом область исследований, поскольку проектов, которые перевалили за 5'000'000 LOC’ов достаточно мало... (edited) 



Вадим Заигрин  1 month ago

Давным давно, когда была предложено структурное программирование, его преимуществом называли отказ от GoTo. В то время, например, оператор IF в Fortran IV выглядел как сравнение и три метки: когда сравнение меньше нуля, равно нулю и больше нуля. Весь код был в кусках, связанных GoTo (спагетти-код). До структурного программирования есть шаг 0: спагетти-код с GoTo. Такой подход сейчас ещё можно встретить в shell-скриптах. Можно считать, что его можно использовать, примерно, до 100 LOC.

white_check_mark

eyes

raised_hands


Vyacheslav Lapin:otus-teacher:  1 month ago

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


Vyacheslav Lapin:otus-teacher:  1 month ago

Действительно, можно назвать спагетти-кодом операторный подход, когда он превышает 100 LOC’ов


92 или 95

Два мотора с одинаковым пробегом: Один ездил на 92-м, а второй на 95. Смотрим эндоскопом в камеры сгорания каждого


https://zen.yandex.ru/media/automaniac/dva-motora-s-odinakovym-probegom-odin-ezdil-na-92m-a-vtoroi-na-95-smotrim-endoskopom-v-kamery-sgoraniia-kajdogo-5f62322d6f388e770cf6283e


На каком бензине едить лучше на 92 или на 95 ? Спойлер - пох ))