mboost-dp1
IKEA
"Han efterlyser standardplatforme, der understøtter Ikeas forretningsprocesser i stedet for at tilbyde en masse andre funktioner i platformen"...
Hvilket jo reelt er en umulighed. Ikeas forretningsprocesser er netop Ikeas forretningsprocesser. De andre funktioner er andre kunders forretningsprocesser.
Sidder som forretningsudvikler på et finansielt program med ca. 40 kunder, alle har deres egne processer og særheder, der skal understøttes og nogle skal have det pakket ind i gavepapir mens andre skal have det med en rød sløjfe.
>2
Det er jo bare ikke nok at fjerne den visuelle adgang. Tilstedeværelsen af de forskellige funktionaliteter i koden er med til at øge kodekompleksiteten betragteligt - især hvis der er tale om kundetilpasset versioner af den samme grundlæggende funktionalitet.
Enten må de tilpasse sig standardsoftware eller også må de bruge skræddersyede løsninger. Det standardsoftware, han efterspørger, kan reelt kun bruges af Ikea, fordi der ikke er andre virksomheder, der har de samme forretningsprocesser.
Det er jo bare ikke nok at fjerne den visuelle adgang. Tilstedeværelsen af de forskellige funktionaliteter i koden er med til at øge kodekompleksiteten betragteligt - især hvis der er tale om kundetilpasset versioner af den samme grundlæggende funktionalitet.
Enten må de tilpasse sig standardsoftware eller også må de bruge skræddersyede løsninger. Det standardsoftware, han efterspørger, kan reelt kun bruges af Ikea, fordi der ikke er andre virksomheder, der har de samme forretningsprocesser.
#3 Jo, men det er vel udviklernes problem og ikke Ikeas? Hvis det visuelt og funktionelt fungere, så er det vel mere et problem for udviklerne? Måske det kan kræve flere mandetimer at lave opdateringer og ændringer.
Selvfølgelig, hvis den tilpasning det kræver for at fungere for Ikea er stor nok, så kan det da slet ikke betale sig at prøve at tilpasse standard software, og man kan lige så godt få special udviklet det hele.
Selvfølgelig, hvis den tilpasning det kræver for at fungere for Ikea er stor nok, så kan det da slet ikke betale sig at prøve at tilpasse standard software, og man kan lige så godt få special udviklet det hele.
Jeg har svært ved at se hvad idea kan gøre udover enten at vælge en standard løsning (billigst) eller at få udviklet en special løsning (dyrest)
De kommer ingen vegne ved at stille sig over i et hjørne og tude over det!
De kommer ingen vegne ved at stille sig over i et hjørne og tude over det!
Pointen er snarere at med et special-udviklet system er der meget større muligheder for at optimere indtjeningen ved at tilpasse det tættere på IKEAs forretningsgange, især med så stor en organisation som IKEA er - dermed er det ikke nødvendigvis den dyreste løsning, hvis man altså formår at udvikle software agilt og uden hovedet under armen.
Jeg er grundlæggende enig i at IT systemer idag er et afgørende konkurrence-parameter og man kan ikke differenciere sig fra konkurrenterne hvis alle kører på de samme standard-platforme.
Jeg er grundlæggende enig i at IT systemer idag er et afgørende konkurrence-parameter og man kan ikke differenciere sig fra konkurrenterne hvis alle kører på de samme standard-platforme.
Ja, med en størrelse som Ikea så vil jeg nok også vurdere at det godt kan betale sig for dem at få et special udviklet system, for det skal jo ikke effektivisere særligt meget før de tjener meget på det.
På den anden side, så kan det så også give en periode med tests og bugs hvor det er mindre effektivt.
På den anden side, så kan det så også give en periode med tests og bugs hvor det er mindre effektivt.
arne_v (10) skrev:#8
Det er ekstremt dyrt at producere fejlfri kode og at bevise at det er fejlfrit.
Men statisk kode analyse til at finde fejl er da forhåbentligt noget som de fleste projekter over adhoc niveauet bruger.
Jeg har indtil videre kun oplevet statisk kode analyse ifm med vindmølle software
Hvis koden skal matematisk bevises som værende korrekt så er vi vist på NASA niveau?
CBM (11) skrev:Jeg har indtil videre kun oplevet statisk kode analyse ifm med vindmølle software
Min forventning idag vil være at selv for almindeligt business software så bliver der skannet for:
- mulige fejl (resource leaks, pointers/indexes som kan få ulovlige værdier etc.)
- mulige sikkerhedshuller (manglende input validering, manglende outout escaping, mulighed for SQL injection etc.)
- code smells (for store klasser/metoder etc.)
- overtrædelser af coding convention
#13: jeg har lavet business/administrativ software siden 2009 i div sprog og har ikke en eneste gang oplevet at man har brugt statisk kode analyse
Kun da jeg arbejdede med vindmølle software fra 2007 til 2009
De fleste steder bruger knap nok versions styring eller bruger det kun meget lidt (en enkelt main branch hvor alt smides på, ingen tags, ingen branchez, no nothing)
Kun da jeg arbejdede med vindmølle software fra 2007 til 2009
De fleste steder bruger knap nok versions styring eller bruger det kun meget lidt (en enkelt main branch hvor alt smides på, ingen tags, ingen branchez, no nothing)
Jeg vil mene at noget af det bliver gjort.
- mulige fejl (resource leaks, pointers/indexes som kan få ulovlige værdier etc.)
- mulige sikkerhedshuller (manglende input validering, manglende outout escaping, mulighed for SQL injection etc.)
Dette håber jeg da at det bliver gjort. Bare ikke med et system der selv scanner efter det, men måske at det er noget man er opmærksom på og prøver at undgå. Man bruger jo ofte nogle standard systemer der har indbygget beskyttelse mod SQL injection, og ellers må man jo vænne sig til at kunne beskytte sig imod det på en standard måde. Men mange virksomheder tester knap nok deres software, og lader det bare være en del af deres service at de så hjælper kunden med at rette fejl hvis og når de opstår.
Men dette tror jeg ret sjældent det sker. Lyder til at nogen virksomheder faktisk stadig bruger kæmpe klasser og metoder.
- code smells (for store klasser/metoder etc.)
- overtrædelser af coding convention
Derudover er alt det med for store klasser og coding convention også noget der bliver lagt mere vægt på end man burde. I mange tilfælde komplicere det mere end det hjælper, og føre til unødvendige klasser og metoder, hvilket nemt kan gøre det mere uoverskueligt. Jeg programmerede før man bruge OOP og kan derfor sammenligne hvordan det blev gjort før og efter. I starten var alt ofte et program, med en helt masse linjer og måske nogle funktioner ind imellem som der kunne hoppes frem og tilbage til.
I dag er der da kommet en hel del gode standarder, metoder og sådan som giver meget god mening. Men en del af det er simpelthen noget der bliver gjort fordi det siges at være standard eller vigtigt når man bruger OOP.
- mulige fejl (resource leaks, pointers/indexes som kan få ulovlige værdier etc.)
- mulige sikkerhedshuller (manglende input validering, manglende outout escaping, mulighed for SQL injection etc.)
Dette håber jeg da at det bliver gjort. Bare ikke med et system der selv scanner efter det, men måske at det er noget man er opmærksom på og prøver at undgå. Man bruger jo ofte nogle standard systemer der har indbygget beskyttelse mod SQL injection, og ellers må man jo vænne sig til at kunne beskytte sig imod det på en standard måde. Men mange virksomheder tester knap nok deres software, og lader det bare være en del af deres service at de så hjælper kunden med at rette fejl hvis og når de opstår.
Men dette tror jeg ret sjældent det sker. Lyder til at nogen virksomheder faktisk stadig bruger kæmpe klasser og metoder.
- code smells (for store klasser/metoder etc.)
- overtrædelser af coding convention
Derudover er alt det med for store klasser og coding convention også noget der bliver lagt mere vægt på end man burde. I mange tilfælde komplicere det mere end det hjælper, og føre til unødvendige klasser og metoder, hvilket nemt kan gøre det mere uoverskueligt. Jeg programmerede før man bruge OOP og kan derfor sammenligne hvordan det blev gjort før og efter. I starten var alt ofte et program, med en helt masse linjer og måske nogle funktioner ind imellem som der kunne hoppes frem og tilbage til.
I dag er der da kommet en hel del gode standarder, metoder og sådan som giver meget god mening. Men en del af det er simpelthen noget der bliver gjort fordi det siges at være standard eller vigtigt når man bruger OOP.
#14
Det er ikke godt.
Men måske ikke så overraskende. Danmark er af forskellige årsager lang bagefter med hensyn til mere formel tilgang til software udvikling.
Man burde bruge static code analysis tools. Og det burde integreres i CI eller anden regelmæssig build, så det er noget hvor man altid har en rimelig opdateret status.
Der er sket rigtigt meget indenfor static code analysis tools de sidste 10-15 år.
Og der er et hav af produkter. Dyre kommercielle produkter, gratis open source produkter.
https://en.wikipedia.org/wiki/List_of_tools_for_st...
Det er ikke godt.
Men måske ikke så overraskende. Danmark er af forskellige årsager lang bagefter med hensyn til mere formel tilgang til software udvikling.
Man burde bruge static code analysis tools. Og det burde integreres i CI eller anden regelmæssig build, så det er noget hvor man altid har en rimelig opdateret status.
Der er sket rigtigt meget indenfor static code analysis tools de sidste 10-15 år.
Og der er et hav af produkter. Dyre kommercielle produkter, gratis open source produkter.
https://en.wikipedia.org/wiki/List_of_tools_for_st...
kblood (15) skrev:Jeg vil mene at noget af det bliver gjort.
- mulige fejl (resource leaks, pointers/indexes som kan få ulovlige værdier etc.)
- mulige sikkerhedshuller (manglende input validering, manglende outout escaping, mulighed for SQL injection etc.)
Dette håber jeg da at det bliver gjort. Bare ikke med et system der selv scanner efter det, men måske at det er noget man er opmærksom på og prøver at undgå.
Naturligvis forsøger man at undgå at lave fejl.
Men der bliver lavet fejl. Udviklere er menneskerog laver fejl. Nogen laver færre fejl end andre men alle laver fejl.
Og de fejl skal gerne findes inden koden går i produktion.
Code scan er et af flere værltøjer til at fange fejl med.
kblood (15) skrev:Man bruger jo ofte nogle standard systemer der har indbygget beskyttelse mod SQL injection,
Ja.
Men I samme øjeblik man begynder at tilføje egen kode, så er der mulighed for fejl.
Gode frameworks gør det svært at lave fejl. Men ikke alle frameworks er lige gode. Og den menneskelig opfindsomhed til at omgå selv det bedste framework er stort.
kblood (15) skrev:Men mange virksomheder tester knap nok deres software, og lader det bare være en del af deres service at de så hjælper kunden med at rette fejl hvis og når de opstår.
Ja.
:-(
#17 Jeg vil nok vægte tests højere end at man kører det igennem en skan, men hvis man bare kan have en skan som fanger nogle af denne slags problemer, så kan det da ret sikkert betale sig. Tror så bare ikke så mange kender til det, fordi jeg har lige taget en Datamatiker uddannelse og jeg tror ikke engang det blev nævnt at man kan få løsninger som skanner alt koden efter disse problemer.
kblood (18) skrev:Tror så bare ikke så mange kender til det, fordi jeg har lige taget en Datamatiker uddannelse og jeg tror ikke engang det blev nævnt at man kan få løsninger som skanner alt koden efter disse problemer.
:-(
Et firma lavede en undersøgelse for 3 år siden blandt lidt over 2000 Java udviklere omkring brug af static code analysis tools.
Mab kan altid diskutere hvorvidt:
- de 2000+ udviklere er typiske for alle Java udviklere worldwide
- Java udviklere er typiske for alle udviklere
Men jeg kender ikke andre offentlige undersøgelser.
Og tallene er interessante:
https://www.slideshare.net/ZeroTurnaround/the-wise...
slide 3:
61% bruger sådanne tools til at monitorere software kvalitet
39% gør ikke
slide 5:
85% bruger et eller flere sådanne tools
15% bruger ingen
(det er ikke åbenlyst udfra slides hvad forskellen på 61 og 85 skyldes)
Det er også værd at notere sig at nogle af de tools de tæller med er ret simple tools.
Men det er altså ret høje procenter.
kblood (18) skrev:Jeg vil nok vægte tests højere end at man kører det igennem en skan, men hvis man bare kan have en skan som fanger nogle af denne slags problemer, så kan det da ret sikkert betale sig.
Der er jo heldigvis ikke enten eller.
static code analysis
manual code review
unit tests
integration test
functional test
performance test
anomaly test
penetration test
Det er bare at vælge så meget som budgettet kan bære.
Vi kører static code analysis ad-hoc in Xcode, fordi Apple ikke supportere human-readable reporting tools når man kører clang analytics på deres kode.arne_v (16) skrev:Man burde bruge static code analysis tools. Og det burde integreres i CI eller anden regelmæssig build, så det er noget hvor man altid har en rimelig opdateret status.
Desværre så er testing og static analysis inden for Apple verdenen ikke holdt højt.
Men f.eks. i Swift er det meget sjældent at finde fejl i en static analyser. Plus, clang/Xcode static analyser kan ikke resolve macros, så det er uendeligt mange false positives.
Claus Jørgensen (22) skrev:Men f.eks. i Swift er det meget sjældent at finde fejl i en static analyser. Plus, clang/Xcode static analyser kan ikke resolve macros, så det er uendeligt mange false positives.
Måske har I brug for et bedre SCA tool.
Problemet er nok bare at der ikke er så meget for Swift som for større sprog.
Coverity og Klocwork understøtter så vidt jeg kan se ikke Swift.
[Coverity er ret gode - da de skulle have tilføjet C# support, så hapsede de Eric Lippert fra MS - inden han skiftede til FB]
AppScan og Fortinet er nok for sikkerheds fokuserede.
Men SonarCube hævder at understøtte Swift.
https://www.sonarsource.com/why-us/products/codean...
Måske værd at prøve.
kblood (15) skrev:Men dette tror jeg ret sjældent det sker. Lyder til at nogen virksomheder faktisk stadig bruger kæmpe klasser og metoder.
- code smells (for store klasser/metoder etc.)
- overtrædelser af coding convention
Igen vil jeg ikke udelukke at det er sjældent at der checkes for det i en typisk dansk mindre udviklingsafdeling.
Men brug af simple SCA tools til at enforce coding convention har været almindelige side de tidligere 00'ere.
Code smell reporting er vel først blevet almindelige som en side-effekt af de mere avancerede SCA tools. Og jeg tvivler faktisk på at de rapporter udnyttes fuldt ud.
De er rigtigt gode til at få udvalgt de rigtige stykker kode til et meget grundigt code review.
Og de kan også give et indtryk af værdien af en høj unit test coverage procent.
kblood (15) skrev:Derudover er alt det med for store klasser og coding convention også noget der bliver lagt mere vægt på end man burde. I mange tilfælde komplicere det mere end det hjælper, og føre til unødvendige klasser og metoder, hvilket nemt kan gøre det mere uoverskueligt. Jeg programmerede før man bruge OOP og kan derfor sammenligne hvordan det blev gjort før og efter. I starten var alt ofte et program, med en helt masse linjer og måske nogle funktioner ind imellem som der kunne hoppes frem og tilbage til.
Jeg mener ikke at ideen med korte metoder er opfundet med OOP. Korte procedurer/funktioner var også et nøgle element i strukturet programmering (Algol og Pascal i 60'erne og først i 70'erne).
Et typisk datalogi-studerende Pascal program fra midt 80'erne havde gennemsnitligt meget korte procedurer/funktioner (jeg undrede mig en del, da jeg kom fra Fortran).
Men det essentielle spørgsmål er vel om det betyder noget. Code Complete har referancer til nogle emperiske undersøgelser.
I min lidt grove opsummering siger de:
* op til nogle hundrede linier kode så giver store metoder ikke flere fejl men derover begynder de at give flere fejl
* store metoder er lidt billigere end små metoder i udvikling
* små metoder er meget billigere end store metoder i vedligehold
En lidt mindre videnskabelig tilgang er at se på hvilken kode som virkeligt gode udviklere selv er stolte af. I de fleste tilfælde vil sådan kode have virkeligt lavt gennemsnitligt antal linier per metode. Bob Martin har en anekdote hvor Ken Beck viste ham noget Java Swing kode som har var stolt af - alle metoder havde 2-4 linier (og dem som har lavet Java Swing apps ved at det er uhyggeligt nemt at ende med 35-50 linier).
@arne: jeg har endnu ikke oplevet et sted der havde en desideret plan for configuration management (cm), jeg har oplevet buildservere og continious integration (ci) et enkelt sted.
Og det var ikke alt der var underlagt ci, nogle projekter fik udelukkende builds initieret manuelt via interfacet
De brugte også automatiseret test/scripted test så de var godt fremme i skoene
Det sted der kom tættest på var vindmølle firmaet hvor der var en form for cm i form af fin procedure for brug af versionsstyring plus statisk kode analyse men ingen ci
Jeg har kun lært om cm, ci/buildservere og statisk kode analyse efter jeg kom ud i erhvervslivet.... hverken som datamatiker eller som bachelor blev det nævnt en eneste gang
Mange steder har heller ikke fastlagt coding convensions
Og det var ikke alt der var underlagt ci, nogle projekter fik udelukkende builds initieret manuelt via interfacet
De brugte også automatiseret test/scripted test så de var godt fremme i skoene
Det sted der kom tættest på var vindmølle firmaet hvor der var en form for cm i form af fin procedure for brug af versionsstyring plus statisk kode analyse men ingen ci
Jeg har kun lært om cm, ci/buildservere og statisk kode analyse efter jeg kom ud i erhvervslivet.... hverken som datamatiker eller som bachelor blev det nævnt en eneste gang
Mange steder har heller ikke fastlagt coding convensions
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund