Документация към софтуерен проект

[Тодор (Zaarin)]

От: Документация към софтуерен проект

кодинг стайла и добрата архитектура на софтуера са си отделни неща. аман от демотивиращи се от всякакви правила програмисти и инженери

всички сериозни проекти, които съм виждал, имат строг кодинг стайл.

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

Повечето неща могат да се постигат и като демотивираш персонала и като не го демотивираш... Познай кога имаш по-добри резултати

[Андрей Боянов]

От: Документация към софтуерен проект

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

Повечето неща могат да се постигат и като демотивираш персонала и като не го демотивираш... Познай кога имаш по-добри резултати

Да ти кажа честно много малко от програмистите, с които съм работил, са имали проблем с изискването за кодинг стайл.
Спазването на кодинг стайл при писане на сорс код е абсолютно същото, като спазването на правописните правила при писане на текст. Много по-лесно се чете написан по правила за кодиране софтуерен код. Скелето си е скеле, пироните са си пирони
Иначе по-много начини съм успявал да демотивирам служителите, спор няма Но като че ли много рядко е било заради кодинг стайла...

[Rabin]

От: Документация към софтуерен проект

Toчно свинщината и некадърните мърлячи дават най-голяма демотивация. А да ти дадат да му оправяш мазалото на такъв. Последните като се намърдат и нагоре по йерархията и ето ти рецепта за катастрофа. Ама темата е друга...

[господин никой]

От: Документация към софтуерен проект

Въпроса с "coding style"-а е много... прост. Или си научен да го спазваш, или не... Точно заради това дори и простичък HTML да пиша гледам да спазвам изрядно абсолютно всичко, а после минавам и дооглеждам коментарите... Добре, че вече не програмирам... ужасна досада е

[Георги-trimata]

От: Документация към софтуерен проект

Много благодаря на всички за полезните съвети! Определено може да се извлече много информация от тях.

Някъде в началото нямаше ли едно мнение подсказващо, че трявба да имам и техните лицензи за продуктите на които е писан софтуера ни, тъй като ако те са пиратски или с липсващи лицензи, то и нашия проект се счита за незаконен? От тук идва и следващия въпрос - ако е писано на напр. trial версия на компилатор законно ли е?

[Ясен]

От: Документация към софтуерен проект

Някъде в началото нямаше ли едно мнение подсказващо, че трявба да имам и техните лицензи за продуктите на които е писан софтуера ни, тъй като ако те са пиратски или с липсващи лицензи, то и нашия проект се счита за незаконен? От тук идва и следващия въпрос - ако е писано на напр. trial версия на компилатор законно ли е?

Няма такова нещо.

Т.е. лицензите на някои развойни средства изрично обявяват продукта за незаконен, ако е направен с нелицензна версия, но това е работа на този, който е евентуално нарушил лиценза. Не се очаква потребителят да е натоварен с полицейски функции. Тоя фокус го правят някои държавни органи, за да се натегнат.

А дали е законно с trial версия на развойния продукт, зависи от trial лиценза на продукта, който може да е формулиран всякак.

[Тодор (Zaarin)]

От: Документация към софтуерен проект

Проблемът с лицензите е по-различен. За компилатори и т.н. едва ли някой ще се заяде с теб (с тях може, но пак малко вероятно). Почти всички лицензи, които са купили, автоматично се прехвърлят и към твоя продукт, без да ти дават нищо черно на бяло. Лошото е, ако са използвали опенсорс код (GPL или дори неправилно ползване на LGPL), за който и да искат не могат да ти дадат лиценз. Или, не дай си боже, опенсорс с двоен лиценз. Тогава, ако този продукт бъде пуснат комерсиално или безплатно извън вашата фирма (ако се ползва вътрешно фирмено, едва ли някой ще го погледне), е напълно възможно да има проблеми и да се наложи продукта да бъде спрян, макар и вие пак да не може да бъдете подведени под съдебна отговорност.

[Ясен]

От: Документация към софтуерен проект

Почти всички лицензи, които са купили, автоматично се прехвърлят и към твоя продукт, без да ти дават нищо черно на бяло. Лошото е, ако са използвали опенсорс код (GPL или дори неправилно ползване на LGPL), за който и да искат не могат да ти дадат лиценз.

Я дай пример за прехвърляне на лиценз от компилатор на продукт? Много майкрософтски звучи това твърдение.

[Тодор (Zaarin)]

От: Документация към софтуерен проект

Я дай пример за прехвърляне на лиценз от компилатор на продукт? Много майкрософтски звучи това твърдение.

Ъ? Кой говори за компилатори?! Вложените в един проект "продукти", не са единствено компилаторите, а и библиотеки, че дори и прости парчета сорс код, а понякога и самите алгоритми или структури от данни имат лиценз, без занечение, че пишеш собствен код за реализация (например някои кодеци). Като за начало това са две твърдения. Първото е, че ако ползват чужд код, библиотека или алгоритъм, за които са платили лиценз, че могат да влагат в свои продукти, то те могат да я влагат без да ти издават копие на този лиценз и на теб. Примерно искаш да промениш кода на Qt библиотеката, но без да отваряш промените. Плащаш на разработчиците на Qt комерсиалната версия на лиценза й и имаш право да го правиш. Други подобни, с които съм работил са примерно mysql, asterisk, pjsip и т.н. Когато купуваш затворен код от друга компания важи същото. На потребителя не даваш абсолютно нищо на хартия, ако има оплаквания към него, той ги прехвърля към теб и ти се оправяш. Второто е, че страшно много фирми взимат готов GPL код, модифицират го и го влагат в свои продукти или просто линкват статично LGPL библиотеките, например във фърмуеър за устройства, без да отварят промените или другите съставни части на общото байнъри и след това го продават като изцяло свое решение, което е в нарушение на GPL лиценза. Примерно са направени същите промени в Qt библиотеката, не са ги отворили, но не е заплатена и комерсиалната версия на лиценза й. Естествено това не се споменава пред клиентите, а в много случаи и пред разпространителите. Тогава, ако това бъде хванато и разработчика откаже да си отвори кода (което пък би било нарушение на договора с клиента или разпространителя) или да си оправи сметките, то продажбата на продукта може да бъде забранена и от това ще страда и разпространителя.

[Ясен]

От: Документация към софтуерен проект

Това е ОК. Първото беше толкова съкратено, че и аз не го разбрах. А това цялото се свежда до факта, че ако част от продукта е разработван от трети лица, трябва да си чист и към тях и това е твоя, на разработчика грижа.

[Георги-trimata]

От: Документация към софтуерен проект

да, проверих го, използват чужди и платени библиотеки.

Ясене - последното ти изречение май се отнася до разработчици?

[Ясен]

От: Документация към софтуерен проект

Да, защото отговарях на zaarin, от своя (главно разработчишка) гледна точка. Да, можех да го напиша по-ясно.

[Тодор (Zaarin)]

От: Документация към софтуерен проект

Това е ОК. Първото беше толкова съкратено, че и аз не го разбрах. А това цялото се свежда до факта, че ако част от продукта е разработван от трети лица, трябва да си чист и към тях и това е твоя, на разработчика грижа.

Да, ама не Ако беше толкова просто, то щеше да е елементарно да се направи една анонимна офшорка (чиято анонимност може да се наруши само в случаи на търговия с оръжие или наркотици), през нея да си разработиш продукт пълен с код с нарушени лицензи, на който ти се явяваш само клиент или разпространител, след което закриваш офшорката и има ли някой претенции към теб, да го пратиш да се оправя с нея Напрактика, ако разработчика не си реши проблемите, било поради факта, че е на локация, на която не му пука от съд или просто заради това, че е фалирал, грижата си се прехвърля, в известна степен, към клиента или разпространителя, като стой та гледай... Е, няма да ги осъдят да плащат неустойки, тъй като теоретично и те са били подведени, но могат да ги принудят да спрат продукта, което също си е загуба. И при изчезнал разработчик няма и от къде да си я избият. Всъщност се получава като казуса с купуването на краден телефон от заложна къща (може и да не знаеш, че е краден), ти го взимаш и след време идва полицията и го прибира, ако не хванат крадеца или той е гол и бос, изгаряш с парите за телефона.

[Ясен]

От: Документация към софтуерен проект

ок, нямам нищо против и това твърдение.

[Георги-trimata]

От: Документация към софтуерен проект

Нека добавя един друг въпрос,
Какъв процент от стойността на продукта трябва да бъде заделен за поддръжка през следващата една година след приемането и?

Става въпрос за някои дребни детайли, които трябва да бъдат леко модифицирани или за такива, които дават грешки (установени след приемането).