Не говнокод ли я пишу (часть 2)?

Question

[artr_lr]

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

Я не стал тот же пример с кружочками переделывать, возникла задача полегче, даже в браузере ничего не нужно рендерить, только консоль, только легкотня:) Но всё же посмотрите что из этого вылилось https://codesandbox.io/s/z3nn4y63m4 просто расчитывает вашу массу на той или иной планете в космосе...

P.S.: честно говоря жутко смотреть на свой код из первой части... Как-то мало критики тогда дали!

Comments

[Антон Спирин]

Если бы вы изучали JavaScript месяц-два, то вас можно было бы похвалить. А так, прошло почти 2 года, а вы до сих пор почти впустую тратите время на бесполезные велосипеды. Учитесь решать реальные задачи. За это время можно умудриться уверенным и сильным мидлом стать.

[Антон Спирин]

artr_lr,

Как вы определили что я не решаю реальные задачи?

По вашему коду.

А тут спросил у "знающих", потому что может кто-нибудь открыл бы что-то новое для меня?

Вам и открыли, что давно пора учиться решать реальные задачи.

И вы действительно думаете, что человек изучающий программирование 2-3 месяца будет так писать?

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

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

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

[artr_lr]

Антон Спирин Я надеюсь вы прочтёте всё то, что я тут написал=)

Только в отличии от вашего примера обычно реализовывают пользовательский интерфейс, без которого в web-приложении нет особого смысла.

Я вижу вы исправили свой ответ:) Если б я хотел сделать пользовательский интерфейс, то пришлось бы прикручивать какой-нибудь реакт, в довесок редакс или мобх) а цель была написать именно свой велосипед! В самом начале я попробовал переписать тот пример с шариками о котором спрашивал в первой части и задать тут этот же вопрос. Но всё вылилось в написание своего
мини-фреймворка со своим реактом и редаксом из коробки. По началу было интересно, но затем я упёрся в оптимизацию. Система работала на flux архитектуре, но всё полностью перерисовывалось при незначительном изменении в модели. И дальше я бросил эту затею... Потому что нет времени. Всё же я работаю над одним проектом используя определённый стек, но не в компании... Да опыта работы именно в компании или команде у меня нет, тут вы правы на все сто.

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

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

Видно, что какие-то продвинутые знания у вас есть, но как их применять вы толком не знаете.

Тут я так и не понял что вы имели в виду:) Либо я использовал не те паттерны в задачке или неправильно, либо то что я стрелял из пушки по воробьям и эту пушку лучше бы было вообще не применять либо применить на нормальной задаче.

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

Фреймворки изучаю, эксперементирую с ними, сравниваю их... А так звучит не сложно, я б сразу залез в документацию, посмотрел что api WeatherApp принимает на вход, что возвращает и исходя из этого написал бы свою обёртку, которое взаимодействовало напрямую, либо через адаптеры, для обеспечения большей гибкости. Написание своего серверного приложения на экспрессе, в котором я могу загружать через sequelize в postgresql фотографии, редактировать и выводить считается? Не волнуйтесь там я сделал пользовательский интерфейс, правда статический=)

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

Хорошей компании надо чтобы ты уже чуть ли не всё умел, нет? https://www.youtube.com/watch?v=zMU4ir10DMg и тут человек (для меня авторитет) подразумевает, что работа в компании (рядовой) вряд ли поднимет тебя в программировании. Я считаю, человек сам себя должен развивать, обучая других (практикую), показывая свой код другим (как я сделал, может ресурсом правда ошибся, надо на гитхаб было), участвовать в опен соурс проектах (честно не участвовал) и смотря на бест практики всё на том же гитхабе(регулярно делаю) Как-то так...

[Антон Спирин]

а цель была написать именно свой велосипед!

Ну получился не очень-то пригодный для езды и при этом overhead для задачи которую решает.

Но почему плохого кода так и не сказали.

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

Несколько претензий навскидку

1.

app.obj = "Юпитер";
app.myWeight = 60;

Ну зачем тут вообще сеттеры? Все это только усложняет анализ кода. Интерфейс можно было сделать более очевидным и удобным. Сами можете ответить зачем наплодили геттеров и сеттеров?

2. А почему вообще у вас этим занимается ядро приложения? Почему не модуль? Добавим фич и здравствуй God object.

3.

get obj() {
    this.viewer.render(this.strings.obj);
    return this.store.obj;
  }

Почему геттер выполняет рендер?

4. this.event.dispatch("SET_OBJECT", obj);
А почему строки, а не константы со строчным значением? Здравствуй целый класс багов вроде: "SET_OBEJCT"

5.

import obj from "../utils/";

const { finder } = obj;

Зачем? Почему не поименный экспорт? obj - не очевидное имя. Дефолтный импорт следовало назвать utils.

6.

export default program
  .setStore(store)
  .setViewer(view)
  .setString(phrases)
  .setPhrase(cphrase)
  .setExecutors(cweight)
  .setDataAction(cdata)
  .setEvent(event)
  .init();

В чем смысл цепочной передачи параметров? Почему не объект? Цепь имеет смысл когда число звеньев может меняться в зависимости от задач. Реактивное программирование, цепочное преобразование данных и тп.

7.

const execute = new Map();

export default execute
  .set("Луна", x => x * 0.17)
  .set("Юпитер", x => x * 0.5)
  .set("Сатурн", x => x * 0.65);

Нарушен принцип DRY. Усложним рассчет и переделывай для всех планет.

8. Почему Файл actions экспортирует Event?

9. reducer пишет значения в два источника правды?

10. А промежуточное ПО? Ни хранилище, ни app его не поддерживают.

11. Редьюсеры имеют доступ ко всему хранилищу и изменяют его напрямую. Привет еще один класс багов(Вася и Федя решили использовать один ключ в разных редьюсерах). Это не FLUX.

12. Еще Редьюсеры не могут обрабатывать один и тот же тип эвента.

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

14. export default view.init();
Зачем тут init при экспорте? Не надо так делать.

Чего в коде нет: асинхронного кода, работы с реальными данными, взаимодействия с пользователем.

　
Радует глаз разве только аккуратное форматирование. Ну и неплохо, что знаете о приемах функционального программирования.

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

Дьявол кроется в деталях. Попробуйте и поймете.

Хорошей компании надо чтобы ты уже чуть ли не всё умел, нет?

На позицию Junior к вашим знаниям, необходимо хотя бы изучить фреймворк и решить реальную задачу. Комплексную. Вроде WeatherApp с сохранением списка избранных городов, определением геопозиции и поиском. После ревью и работы над ошибками можно откликаться на вакансии и пробоваться на собеседованиях. Естественно, верстку тоже надо знать. Плюсом будет:
1. базовые знания npm
2. базовые знания webpack
3. базовые знания TypeScript
4. базовые команды git
5. английский на уровне чтения технической литературы

тут человек (для меня авторитет) подразумевает, что работа в компании (рядовой) вряд ли поднимет тебя в программировании

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

Я считаю, человек сам себя должен развивать

Это лишь одна неотъемлемая часть целого комплекса мероприятий. Обмен знаниями и опытом очень важен. На работе есть все условия, чтобы как губка впитать чужую мудрость и кого-то при этом еще и перерасти. Этот ваш авторитет, одно дело посмотреть часик его подкаст, другое работать с ним бок о бок 8 часов в день, 5 дней в неделю, в течении года.

Могу посоветовать осваивать React/Redux. Функциональный уклон стека должен вам понравиться.