Реба Създадено на 06.08.2020, видяно: 2230 пъти. #3107
вижте, факта че за 70 години от как интензивно се програмира няма наложен стабилен модел, значи че такъв няма, не се мъчете да измисляте такъв, ще се маже и това е.
между другото, да споделя едно мое сравнително скорошно наблюдение относно множеството класове за почти еднакви неща. например двойката цвят/3двектор или пък комплексно число/2д вектор и тн. схващате картинката, сравнително прости класове, с доста еднакво поведение (например еднакви оператори за събиране, скалиране, инициализиране и тн) но различен смисъл и някои чисти разлики, например произведението на два цвята е пак цвят, а на два вектора е число. масовата практика е да се ползват отделни класове, и аз правх така до преди 3 години, когато трябваше да спретна набързо нещо от нула, без депендънсита. за бързина реших да ползвам общ клас за цвят и вектор - това се оказа толкова потресаващо удобно, че възприех тая практика във всичкия си стендалон код. това е много неправоверна тактика, но върши чудесна работа, и за пореден път доказва че радетелите за чистота са тъпанари
Всъщност има, но той не се харесва на джендърите, защото е много просташки. А моделът е абсолютно еко, природно натурален. Пряко следствие от същността на компютрите.
Принципът е, че най-малкият код, който решава задачата, излиза най-добър и като скорост и като усилия за поддръжка и като общи усилия за разработка.
Но за съжаление мейнстрийма го е страх от такъв подход:
Реба Създадено на 06.08.2020, видяно: 2211 пъти. #3110
когато някой играч надуши печеливша стратегия побеждава, и мишоците започват да копират принципите му, това е начина по който странните идеи стават общоприети. та или ти си единствения който се е сетил за това, или просто не е вярно. кое според тебе е по-вероятния вариант?
Откъде накъде "или-или"??? Разбира се, че не съм единственият който се е сетил за това.
Какво да говорим, когато ти самият преди два поста написа същото и колко си бил потресен от ефекта.
Най-потресающия грандиозен провал, в който по неволя участвах. Начи у лъскава западна столица, техния бизнес парк до горичката. Отдел на международна многомилиардна Корпорация. Голяма сграда с офиси, наще заели цели 2 етажа и пишат новия велик ERP дето ще връти мелеардите. Получавам язе почти завръшения им проект, и очите ми не верват кво виждат. Тия се мъчили да пишат собствено ORM, ама толкоз смотано, че ако някой се освести как се мапва обект, то след макс. 2 чАса го е забравил, като след събуждане от лош сън. Почвам да мрънкям язе, на всичко отгоре не се билдва с мавенжийницата.
Отиваме там на място да си подкарат лайната. Инак сичко по Скум, буквално кибичат прави сутрин по половин час, и то не къв да е Скум, ами международен. Един конферентен телефон на средата на залата, и се надвикват с още един такъв екип от другия край на света. Ние бяхме ларж и не застанахме на един крак, а нащо шефче по едно време заспа за малко, буквално. Сичко по TDD писано, 2 реда да бутнеш и сичко тръгва да се ребилдва и тества наново. Диви интерфейси и патърни, свет да ти се извие. Фикснах един бъг, системата беше толкова тромава и опропастена, че фиксът ми тъй и не успя да се добере до репото. Една камара огледални сървъри, екип DevOps да го прави по книга да връви, и нищо не бачка накрая. Па да кажа, туй не у кмб, ми у огромна мега Корпорация. Накрая биг Бос се усети кви лайна са натворили по стандарт, угаси ламбите и ни прати сичките на борсата. Чужденците за 5 цифрено в евро, назе за 5 цифрено в лева. Та така с големите науки. А можеха да си турят някой безплатен ORM дето бачка...
Толкоз беше насрано, че аз лично не се сещам кой може да оправи толкоз много сбръкана работа на ено место. Трябваше да се почне наново. Имаха си дедо архитект дето го е натворил, и ни учеше на ум и разум назе туземците, кво велико дело е TDD със 100% test coverage. За отдела на ганите няма нужда да поменувам. Кокошарникът стигаше за 2 футболни отбора на Симитли.
Ако пускаш постоянно на прод с CI/CD, лично мисля, че трябва да имаш поне смоук тестове, bare minimum, даже Unit Test-овете са ти нужни. Трябва да си нагласил девопсването, ако си с кубернетес е лесно, но ако си с 2-3 виртуалки зад балансер пишеш скриптове яко. Обаче интегрираш по- малки части. Друг добър похват е да имаш feature switch. Първо даваш новата функционалност на малко клиенти и ако работи, тогава на повече. Ако ти спре бизнеса за всички е гадно, но ако ти спред за 10% някакви по-евтини мастии и можеш бързо да го изключиш, защо не. Струва ми се по- оптимално да съм баш lean, пиша, тестват, UA, Prod. Така интегрирам по- малко неща наведнъж. Но ако съм копал feature-и 2 месеца или повече и трябва да ъпдейтвам нещо голямо, трябва да кибича повече време с админите и опсовете по нощите и накрая ни будят след 3 часа да връщаме версия, не е приятно. На малки стъпки интеграцията ми се струва по- безболезнена.
Най-малко код да, обаче как се мери най-малкото? Зад един ред код може да стои метод с 10к редове и още незнайно колко други в извиквани от него методи.
В големи системи, писани много време и от много хора има три метода които подобряват една система - импакт анализ, концентрация на логика и TCO анализ. Т.е. може да се окаже по-добре да се махне/пренапише даден метод, например да се добавят нови 1000 реда вместо да се напише нов метод със 100 реда, ако това ще концентрира логика. За последното - добре е да се смята TCO-то в правилен интервал - т.е. може в текущия проблем да се загуби повече време, ако това ще намали цената в по-дълъг план. От друга страна един бърз фикс и преработка наново по-късно може да избегне големи щети.
Са тия неща са отвлечени и малко встрани от Истинското програмиране и Архитектуриране, но е хубаво да се знае че големите бизнес системи рядко са в застой - те винаги се развиват или поне се опитват да го правят. Има два варианта на развитие - в единия системата независимо от нарастването си се оптимизира, става по-гъвкава и по-приятна за работа, и другия - става по-раздута, по-тромава, по рабиноидна - т.е. с повече претенции и с по-малко реална полза.
Над тия неща има и някои други, като например как се управлява ит проект, ама то става съвсем отвлечено и сухо, и мераклии за такива дискусии едва ли има.
Дай малко акъл как се управлява ИТ проект, че само с копане не става. А как убеждаваш C-Level-ите, че това е нирваната. В крайна сметка чичковците с пари натискат да се вадят пари по-бързо. Ако не им го представя в сметки, няма да ми обърнат внимание. А ако сбъркам сметките, може да си ходя. И така навлизаме в едно делегиране на решенията отгоре надолу, блеймоспективи, комплейнспективи, Гошо от 10-ти етаж го реши това, аз му казах да си караме по старому, ще го махнем и няма да има проблеми. Горните мениджъри ще разиграят цирк да си запазят мястото, то такова място не се отваря всеки ден.
Пропуснах да напиша, че тяхната Гана караше нова служебна расова бегачка. Само единия фар струваше повече от заплата при назе. Като станат на 4 години им ги сменят, че остарели. Колегата искаше да купи някоя такава 4 годишна остарелница, ама на нас южняците не се полагало. Държаха шефчето по 6 чАса на конферентни разговори. Софтуер за големи мелеони изисква многочасови разговори. После тотален краш по учебник. Някой от вас едва ли е виждал толкоз насрана архитектура. Просто не е за вярване.
Друг случай. Пращат ме да преконфигурурам мрежата на друг клиент многомелеардник. Преотдадено ропче на друг робовладелец, да им оправя бакиите. Колегите се дърпат от такива неща, аз лично съм ОК щото е забавно. И кво да видят очите ми при клиента.
3 (ТРИ) отдела с админи си имат. По печес човека у собичка и си геедат у мониторите. Ужас и безумие. И ме пратили менека да им оправям бакиите. Близо 100 виртуалки имаха у вътрешната мрежа. Дори не съм админ на щат, ми го правя щото няма кой друг.
Рабе, кажи си, че и ти искаш да си С-level, с всичките благини на това :D
И аз съм на този принцип от години. Печели малкото код пред "правилният" начин, просто защото минималният код, който върши работа е достатъчно необходимият да бъде правилен и лесен за поддържане.
Искам да съм това дето съм в момента. Тъпото е, че изисква големи мангизи за да стане в обозрим срок. Нямам мелеоните на Ганите, и пълзя във времето. Ейго иде зима, и хангар нямам дори.
Ако съм незнам кой левъл в Корпорация, ще трябва на 100 % да пърформя корпоративен шит. Гади ми се от тия неща. До такава степен са насрали занаята ни, че 10 човека вършат работа за един. У казармения форум (ега ин го турнье слон) имаше една тема за SOLID. Гюро е часниче и пише софт дето го купуват многомелеардници. Гюро също отрича залитанията в патърни и корпоративен шит.
Реба Създадено на 06.08.2020, видяно: 2151 пъти. #3120
то всички сме на тоя принцип, но само "понякога", и той като всички останали велики патерни е верен самоза част от случаите. в другите , там където не е валиден, смело скачаме в езерото с лайна и плуваме юнашката
Отиваме малко в управление на чичковщина, не на проект.
Като едно добро начало - ти си напред с материала, първото правило в управлението на чичковци/Гани е да представиш сметка. И когато те я пренебрегнат, се инкасират загуби. След като загубите достигнат едно критично ниво се задейства защитния механизъм и чичкото почва да разбира че с чичковщина пари не стават или поне не достатъчно. Почват анализи, и първата стъпка към подобрението е когато чичо има добре представена сметка, в която може да види алтернатива. Едно добро правило е на чичкото да не се дава акъл какво решение да вземе, а да се представят варианти. Никой (вкл. чичото) не се ражда научен, и в основата на ученето е да избираш и да страдаш при грешни решения. Най-тъпото което можеш да направиш с един чичко е да го караш да взима решение, така той свиква да си бара чичовеца и да разчита на теб, съответно да не мисли и да прави глупости.
В предоставянето на сметки също има разни интересни детайли, един добър вариант е дадена сметка да се дава в интервал (min, max) и с делта като %, което за умния чичко подсказва доколко сметката е сигурна според сметкаджията. В класическия вариант се дава едно число, и тогава оставяш на чичото да определя доколко е вероятна преценката за нещо.
Като резюме - не се опитвай да промениш системата ако не си мениджър и нямаш права да я променяш. Давай варианти, върши твоята работа и оставяй отговорните да взимат решения и да поемат вината за грешните.
А, понеже ме подсети. Практика в кмб, почти навсякъде е. Като се осерат нещата се обвиняват ропчетата на плантацията. Дори те да не са вземали тия решения. По таа причина заобикалям бивши клиенти кат ги срещна на пътя, щото ме е срам кви глупости ме караха да правя за сметка на тия клиенти.
Как така само понякога? Аз имам предвид най-малкото код, който върши работата, не най-малкото код, който решава част от работата.
Лично аз меря кода в бинарни байтове. Тоест, не е важно колко реда е сорса ами колко е после изпълнимият файл.
Разбира се сумарно със всички библиотеки. А бе, мери се кода, който е в паметта докато програмата се изпълнява. Ако се зарежда динамично код - то размера в най-тежкият случай.
Ако се използва език с интерпретатор - то кода на програмата плюс интерпретатора.
Разбира се, точна преценка е много трудно или даже невъзможно да се направи. Но важното е да има стремеж към минимизиране на кода при проектирането на проекта и после при написването му.
Жони не те знам как мериш кода, ама като ви слушам със Стилгара го мерите с рулетката.
Пак случай от като бях жунка бесна. Пиша няколко месеца див асемблер, едвам се събира у чипа. Отива шефчето у Датекс да ги пита могат ли да направят същото нещо. Обадили му срок под една седмица. На С си инициализират няколко масива, ползват си готови библиотеки, и свършват работата 10 пъти по-евтино и бръзо.
Аз с твоя асемблер съм го ял немит!
п.с. Аве ти ли беше хостнал за Дзен в кодолеярството. Много удачно би се вписало в тоя форум.
Нали се разбрахме че от робче кирлив джуньо (като теб) до робче синиър и нагоре (като останалите) има мааалка разлика?
Хубаво, ама ти правиш няколко фатални грешки - първо, с тоя код работиш основно ти, второ - от изброените неща, а и от всичко досега на теб топ критерий ти е бързодействието, което не винаги е така. Трето - сам признаваш че точна преценка не може да се направи, т.е. е субективно. Оттам нататък твърдението ти че трябва да се търси минимален код винаги и навсякъде лупва като зряла круша.