Оффтоп _Программинг

Описание: Офф-топы, юмор, поздравления, радости и печали.

ADF
Автор темы, Старые
ADF
Автор темы, Старые
Репутация: 23
Сообщения: 4198

#61 ADF » 12.04.2018, 21:17

Только сортировать пузырьком нельзя. Он неэффективный слишком. У сортировки пузырьком есть одно достоинство - но в нонешних условиях оно крайне редко востребованно :)

PS: за сортировку пузырьком в реальных проектах, если начальник код увидит, руки от жопы оторвут :rolf2:

ADF
Автор темы, Старые
ADF
Автор темы, Старые
Репутация: 23
Сообщения: 4198

#62 ADF » 17.04.2018, 14:31

...по необходимости теперь тоже с JS вожусь.

Офигиваю от того, что там синтаксис записи функций разный, чуть ли не три разных вида, в зависимости от того, это просто функция, это описание прототипа или статичная функция в синглтоне. Это просто жесть :help:

Сергей
Старые (Администрация)
Аватара
Сергей
Старые (Администрация)
Репутация: 25
Сообщения: 4782

#63 Сергей » 17.04.2018, 21:42

Ты же вроде знал и так JS и не офигевал? Тоже вот что-то не в восторге. Так туго идет. Как-то с шарпами легче было, хоть я их до конца и не знаю.
Все вышеописанное является моим мнением и моим оценочным суждением, и не претендует быть истиной в последней инстанции. ..Nihil est ab omni parte beatum..

ADF
Автор темы, Старые
ADF
Автор темы, Старые
Репутация: 23
Сообщения: 4198

#64 ADF » 18.04.2018, 00:33

Сергей писал(а):Ты же вроде знал и так JS и не офиге

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

Сергей
Старые (Администрация)
Аватара
Сергей
Старые (Администрация)
Репутация: 25
Сообщения: 4782

#65 Сергей » 18.04.2018, 12:46

А чего пишешь, если не секрет?
Все вышеописанное является моим мнением и моим оценочным суждением, и не претендует быть истиной в последней инстанции. ..Nihil est ab omni parte beatum..

ADF
Автор темы, Старые
ADF
Автор темы, Старые
Репутация: 23
Сообщения: 4198

#66 ADF » 18.04.2018, 20:54

на работе задачи текущие...

Сергей
Старые (Администрация)
Аватара
Сергей
Старые (Администрация)
Репутация: 25
Сообщения: 4782

#67 Сергей » 07.05.2018, 17:30

Алехандро, а как обстоять дела с проектированием? На примере той же Жизни прихожу к выводу, что архитектура что у меня, что у тебя гавно. Она не расширяемая. Имею в виду, а что если например понадобится 3-мерное поле сделать? А если на поле появятся еще какие-то сущности при этом? И так далее. Как вообще у тебя с этим дела обстоят? Ведь одно дело сделать чтобы просто работало - и это как раз таки называется быдлокод, а другое дело сделать зачупатую архитектуру, расширяемую с низкой связанностью (coupling) и т.д. Пользуешь какие-то средства проектирвания (так называемые CASE-средства)?
Я вот когда базу данных проектировал в рамках курса пользовался неким средством - и разработка архитектуры при таком подходе действительно проста и не напряжна, а главное визуально наглядна. Не говоря уже о таких фишках как генерация базы данных по физической модели автоматом..
Все вышеописанное является моим мнением и моим оценочным суждением, и не претендует быть истиной в последней инстанции. ..Nihil est ab omni parte beatum..

ADF
Автор темы, Старые
ADF
Автор темы, Старые
Репутация: 23
Сообщения: 4198

#68 ADF » 07.05.2018, 18:41

Сергей писал(а):что архитектура что у меня, что у тебя гавно. Она не расширяемая. Имею в виду, а что если например понадобится 3-мерное поле сделать? А если на поле появятся еще какие-то сущности при э

Сразу видно неопытного программиста! :empathy:

Сергей, при решении практических задач не надо закладываться на бесконечную расширяемость. Потому, что:
1. ВСЕ возможные в будущем варианты ты все равно не учтёшь на этапе планирования архитектуры;
2. Когда дойдёт до внедрения новых фич, твою мега-архитектуру с очень высокой вероятностью придётся изменять - нельзя заранее предугадать, как именно и что надо было сделать. Объём работ по изменениям - может быть сопоставим или превышать, как если бы ты просто с нуля запилил фичу;
3. Ты тратишь дополнительное время на создание супер-архитектуры: того, что не требуется для решения текущей задачи.

По этому поводу есть множество шуток, например: "если программиста оставить надолго наедине без задач, он начинает писать движок всего" :biggrin:

Всё это называется ёмким словом: over-engineering.

В реальной и продуктивной работе делается так (этот подход счтается САМЫМ эффективным):
1. Делаешь архитектуру под решение только текущей задачи;
2. По мере необходимости внедрения новых фич - рефакторишь, чтобы архитектура оставалась красивой, а код - поддерживавуемым. Но только при реализации конкретных новых фич, а НЕ заранее!
3. Стараться избегать переписывание всего с нуля, как бы рука не дёргалась этим заняться (хотя на этапе обучения, возможно, это делать как раз надо).

Сергей писал(а):Ведь одно дело сделать чтобы просто работало - и это как раз таки называется быдлокод,

Ты даже не представляешь, насколько ты не прав :)

Мой, как и твой код - легко читать, просто рефакторить. По этим двум ГЛАВНЫМ параметрам - он не является быдлокодом. Простой и читаемый код == хороший код.
Переделать для разных сущностей, для трёхмерного поля? Сергей, там весь код едва два экрана занимает, можно его хоть весь переписать. Проблемы расширяемость для этого кода - просто не существует - именно потому, что он простой.

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

Сергей писал(а):сделать зачупатую архитектуру, расширяемую с низкой связанностью (coupling) и т.д.

И будет классическая проблема слишком универсального инструмента! Ты, видать, просто ещё не сталкивался с этим на практике...

Допустим, ты две недели писал свою супер-архитектуру, красивую армию универсальных базовых классов, строго придерживался всяких там паттернов проектирования типа MVC. Но за это время у тебя ни разу не было реальной работающей программы - ты все это писал практически вслепую.
А потом тебе, наконец, захотелось все это применить - и ты будешь, грубо говоря, целый день писать хрень, в которой у тебя сначала все нужные синглтоны инициализируются, всякие там слушатели событий создаются, может быть подсасывается XML-ка с параметрами или кусок базы данных - только для того, чтобы на экране написать hello world.

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

С другой стороны, конечно, представление о правильной архитектуре надо иметь обязательно. И о том, что такое расширяемый код, а что такое не расширяемый. Без этого - никуда. И создавать порой какие-то базовые вещи, чтобы было проще делать что-то сложное - тоже приходится. Ещё существует подход, что сначала выгоднее сделать инструментарий, а не сразу херачить. В случае, если предполагается решение некого количества однотипных задач - инструментарий позволяет сэкономить уйму времени! Но не надо по каждому чиху-пуку тут-же начинать писать свой супер-универсальный движок ;-)

В общем... Всё это с опытом приходит :drink:

Сергей
Старые (Администрация)
Аватара
Сергей
Старые (Администрация)
Репутация: 25
Сообщения: 4782

#69 Сергей » 07.05.2018, 18:54

Короче я так понимаю, что ты не проектируешь архитектуру, а просто пишешь, а там куда кривая везения вывезет. И инструментами ты для проектирования не пользуешься. :rolleyes:
Все вышеописанное является моим мнением и моим оценочным суждением, и не претендует быть истиной в последней инстанции. ..Nihil est ab omni parte beatum..

ADF
Автор темы, Старые
ADF
Автор темы, Старые
Репутация: 23
Сообщения: 4198

#70 ADF » 07.05.2018, 20:22

Сергей писал(а):не проектируешь архитектуру, а просто пи

Что значит не проектирую?! Тогда уж и не программирую я вовсе, а просто кнопки нажимаю! :lol: :lol: :lol:

Сергей писал(а):И инструментами ты для проектирования не поль...

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

Добавлено спустя 11 часов 7 минут:
.
А ещё есть так называемый development hell, в который очень легко попасть.

Проектирование архитектуры, использование паттернов - всё это должно ускорять разработку. Но когда оно без должного опыта применяется - разработка замедляется вплоть до полной жопы. :help:

Сергей
Старые (Администрация)
Аватара
Сергей
Старые (Администрация)
Репутация: 25
Сообщения: 4782

#71 Сергей » 08.05.2018, 17:39

А как соотносится архитектура с алгоритмом? Я вот понимаю, что ничего не могу поменять так как по большому счету знаю только простейший алгоритм (пересчет из одного поколения в другое). Архитектура получается следствием алгоритма, заложенного в решение задачи. Оказывается есть и другие алгоритмы это Жизни. В том числе и более быстрые. Или это в крупном приближении одно и то же?
Все вышеописанное является моим мнением и моим оценочным суждением, и не претендует быть истиной в последней инстанции. ..Nihil est ab omni parte beatum..

ADF
Автор темы, Старые
ADF
Автор темы, Старые
Репутация: 23
Сообщения: 4198

#72 ADF » 08.05.2018, 17:47

Сергей писал(а):А как соотносится архитектура с алгоритмом?

Ну в теории это вообще разные понятия.

Архитектура - это как станки по цехам расставлены, а алгоритм - это технология, как из частей автомобиль скручивают. Одно от другого не зависит. По крайне мере в общем случае :)

Сергей писал(а):Я вот понимаю, что ничего не могу поменять так как по большому счету знаю только простейший алгоритм (пересчет из одного поколения в другое). Архитектура получается следствием алгоритма,

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

Сергей писал(а):Оказывается есть и другие алгоритмы это Жизни. В том числе и более быстрые. Или это в крупном приближении одно и то же?

Алгоритмы не всегда разные, бывают ещё разные реализации одного алгоритма. А вообще - да. Но это уже из области оптимизации.

Кстати, задача оптимизации (быстродействия) почти всегда идёт в разрез задаче построения красивой архитектуры и читаемого кода. Ну это так, к слову. )

Сергей
Старые (Администрация)
Аватара
Сергей
Старые (Администрация)
Репутация: 25
Сообщения: 4782

#73 Сергей » 08.05.2018, 18:23

ADF писал(а):типа тут у нас отрисовщик, здесь - обработчик, тут - функционал для редактирования и управления.
Это паттерн MVC. Мне говорят надо гибкую и расширяемую архитектуру. В рамках обучения. Я уже в копаниях запутался. По идее работа с двумя массивами (как и реализовано) - алгоритм, который по логике никакой такой особой архитектуры как раз и не предполагает. Есть другой алгоритм, который возможно и предполагает другую архитектуру. Я уже что то в этом неделю копаюсь и если вначале мне казалось, что понимаю с каждым днем все больше чего от меня хотят, то теперь я уже вообще ничего не понимаю. То ли от меня хотят тупо разделение на 3 сущности по MVC и взаимодействие между ними через некие интерфейсы. То ли еще более дробное деление на сущности в том числе и модели самой и чтобы эти сущности взаимодействовали друг с другом через интерфейсы.
Текст такой:
Спойлер
Сама задача действительно простая, в этом ее смысла — главное, как ты отнесешься к архитектуре, и можешь ли ты сделать архитектуру четкой и легко расширяемой. Если ты сделаешь тупо массив с нулями — тебе будет тяжело потом уйти от такой модели, если мы тебя попросим чуть более сложные данные хранить (а если будут не только клетки, но еще и камни? А если поле будет не двумерным, а трехмерным? А если будет вообще не поле, а просто некое множество с какими-то новыми правилами того, кого считать соседом?). При работе напрямую с массивом ты полностью отказываешься от инкапсуляции, теперь весь проект знает, что модель — это массив с булинами. А надо, чтобы весь проект знал только про самый общий интерфейс, вся логика и все детали реализации должны быть по максимуму инкапсулированы
Как думаешь, чего надо?
Все вышеописанное является моим мнением и моим оценочным суждением, и не претендует быть истиной в последней инстанции. ..Nihil est ab omni parte beatum..

ADF
Автор темы, Старые
ADF
Автор темы, Старые
Репутация: 23
Сообщения: 4198

#74 ADF » 08.05.2018, 18:39

Да на классы все побить, взаимодействие через интерфейсы и-или публичные методы.

Допустим у тебя есть класс поле, реализация - приватная. Публичные методы: задать мерность поля, прочитать мерность поля. Задать размеры поля, получить размеры поля. Методы для доступа к ячейкам по координатам. Сам класс "поле" - это структура для данных, вычислений в нём делать не надо, кроме каких-то самых базовых. Алгоритм делаешь в другом классе, которому даёшь в зубы экземпляр класса "поле" и над ним делаются вычисления.

Элементы массивы - объекты класса "ячейка", который ты тоже сделаешь. Ячейка может разные значения принимать, иметь разные свойства - всё это описываешь в классе ячейка. Так ты ушел от жестких нулей и единиц. Обращение к ячейке - через публичные методы. Считать ячейку, записать ячейку, получить список возможных состояний ячейки. Из остальных частей проекта обращение к ячейкам - только через эти методы.

И вот так вот всё на куски бьёшь и разделяешь.

Сергей
Старые (Администрация)
Аватара
Сергей
Старые (Администрация)
Репутация: 25
Сообщения: 4782

#75 Сергей » 08.05.2018, 19:03

Вот как раз и стал приходить к таким выводам, точнее делению на ячейки и поле, даже схемку стал рисовать, и методы для этих двух сущностей описывать. А потом к х**м запутался. Спасибо за просвещение :drink:
Все вышеописанное является моим мнением и моим оценочным суждением, и не претендует быть истиной в последней инстанции. ..Nihil est ab omni parte beatum..

Сергей
Старые (Администрация)
Аватара
Сергей
Старые (Администрация)
Репутация: 25
Сообщения: 4782

#76 Сергей » 15.05.2018, 19:08

Александро, подскажи еще, как лучше доступ к полям класса иметь - через встроенные же методы этого класса или можно через геттеры/сеттеры? Ты вроде как про методы ранее говорил, но ты может не знал, что я про get/set знаю. Если функционал у методов тот же, что у get/set по сути, то нафига городить огород, а? Игрулю я кстати переписал как надо, на сущности побил, MVC-принципы применил. Правда на C# пока, сейчас на JS буду переписывать.
Еще вопросик в догонку. В интернете пошарился конечно предварительно, но как-то не внятно. Я ранее думал, что модули JS с классами соотносятся в нормальных языках. Сейчас вижу, что вроде как классы в стандарте ES6 имеются, а модули это отдельная песня. Да и по сути модули - это просто отделенный и не зависимый код, вынесенный в файл. В шарпах один файл - один класс, укрупненные деления вроде только на пространства имен, как мне кажется пространства имен в шарпах и модули в JS это одно и то же. Я правильно понимаю, что классы те, что у меня на шарпах были, можно так же в принципе переписать на классы JS? А 4 класса модели объединить например в один модуль?
Все вышеописанное является моим мнением и моим оценочным суждением, и не претендует быть истиной в последней инстанции. ..Nihil est ab omni parte beatum..

ADF
Автор темы, Старые
ADF
Автор темы, Старые
Репутация: 23
Сообщения: 4198

#77 ADF » 15.05.2018, 20:49

Если у тебя доступ к просто полю класса - то делаются геттеры-сеттеры.
Если доступ вообще открыт всегда и всем - то онанизм с геттерами-сеттерами не нужен и поле просто тупо публичным стоит делать.
Но у тебя может быть доступ к хитрым структурам с хитрыми формулами - допустим доступ к одной клетке поля. Тут уже не геттер-сеттер, а функция, которая по заданным координатам тебе выковыривает содержимое ячейки из внутреннего массива (или списка). И в этой функции также должна быть проверка на допустимость диапазона x и y, как минимум, и в случае выхода за пределы поля функция, в общем случае, не должна крэшить всю программу, но должна как-то сообщить пользователю или тому, кто функцию вызвал, что случился косяк. Допустим вернув значение "-1", если бы там Int был, если она объект возвращает - то можно вернуть null. При условии, что у тебя в коде выше есть проверки на null.

Про JS:
в JS нет нормального ООП, там так называемые прототипы. Если по-простому - классы малость по ебанутому описываются. Нэймспэйсов нет, но есть (и применяются) так называемые замыкания - когда какую-то часть кода можно в функцию обернуть, внутри этой функции будет своё изолирование от внешней среды пространство имён переменых.
Ты всё это при желании можешь нагуглить.
Но в общем и целом - архитектуру твоей программы на С# в практически том-же виде ты и в JS воплотить можешь.

Сергей
Старые (Администрация)
Аватара
Сергей
Старые (Администрация)
Репутация: 25
Сообщения: 4782

#78 Сергей » 15.05.2018, 21:02

А как в эту картину мира модули вписываются? Про замыкания и прототипы знаю в общем-то, хоть и не прям супер. Что-то модули меня в ступор вводят. В модуле тоже своя вроде как область видимости - а значит если я правильно понимаю - тот же механизм инкапстыляции, что и при замыканиях.
Все вышеописанное является моим мнением и моим оценочным суждением, и не претендует быть истиной в последней инстанции. ..Nihil est ab omni parte beatum..

ADF
Автор темы, Старые
ADF
Автор темы, Старые
Репутация: 23
Сообщения: 4198

#79 ADF » 15.05.2018, 21:04

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

Сергей
Старые (Администрация)
Аватара
Сергей
Старые (Администрация)
Репутация: 25
Сообщения: 4782

#80 Сергей » 15.05.2018, 21:11

Понятно, ты не в курсе свежих веяний стандарта ES6. Я правда сам не супер знаток. Ну, на "нет" и суда нет. Там имхо дела получше с некоторыми вещами обстоят и язык больше на язык похож становится. Еще лучше думаю в ES7 будет. Так что если тебе JS нужен по работе, может и подтянуть стоит. А если ты за совместимость кода рубишься, так транспайлеры есть, бабель тот же, который код из ES6 может в ES5 или хоть ES3 перегнать.
Все вышеописанное является моим мнением и моим оценочным суждением, и не претендует быть истиной в последней инстанции. ..Nihil est ab omni parte beatum..


Вернуться в «Обо всём»

Кто сейчас на форуме (по активности за 5 минут)

Сейчас этот раздел просматривают: 1 гость