RailsConf 2014 - Keynote: Writing Software by David Heinemeier Hansson
23 views
Skip to first unread message
Slavomir Kaslev
May 9, 2014, 4:40:57 AM5/9/14
to polyglo...@googlegroups.com
Stefan Kanev
May 9, 2014, 4:44:46 AM5/9/14
to polyglo...@googlegroups.com
Това заради "TDD is dead" bullshit-а ли го пращаш, или има някой по-интересен point?
Slavomir Kaslev
May 9, 2014, 8:57:40 AM5/9/14
to polyglo...@googlegroups.com
По-скоро за разликата между computer science и building systems, но като цяло презентацията ми беше интересна.
On Fri, May 9, 2014 at 11:44 AM, Stefan Kanev <stefan...@gmail.com> wrote:
Това заради "TDD is dead" bullshit-а ли го пращаш, или има някой по-интересен point?
--
You received this message because you are subscribed to the Google Groups "Polyglot Quine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polyglot-quin...@googlegroups.com.
To post to this group, send email to polyglo...@googlegroups.com.
Visit this group at http://groups.google.com/group/polyglot-quine.
For more options, visit https://groups.google.com/d/optout.
Slavomir Kaslev
Stefan Kanev
May 10, 2014, 4:54:55 AM5/10/14
to polyglo...@googlegroups.com
On 09/05/14, Slavomir Kaslev wrote:
> Writing Software by DHH. <https://www.youtube.com/watch?v=9LfmrkyP81M>
Изгледах презентацията и имам малко коментари. Определено я
препоръчвам, но с едно наум.
Първо, какво ми хареса:
* Computer Scientist vs. Information System Programmer. Отдавна смятам,
че колкото по-бързо разпознаем, че вършим фундаментално различни неща,
талкова по-бързо може да започнем да учим един от друг. Ала "какво
могат да научат JavaScript програмистите от C програмистите и
обратно".
* "Read a lot of software, write a lot of software" – определено
симпатизирам с възгледа, че само с четене не става.
* Целия паралел с пиането бе страхотен. Титлата "Software writer";
цитата на Паскал (или Твен) – "Ако имах повече време, щях да ти напиша
по-кратко писмо"; The Delete key is the №1 tool for writing good code.
Не е нова идея, но беше добра представена.
* DHH е много добър презентатор и определено човек има какво да научи в
представянето на идеи от него. Всеки път е фън.
Това бяха take-away-овете от началото и края. Сега, имам няколко неща
за казване по TDD атаката по средата. Дори да не ви интересува, аз имам
нуждата да го споделя някъде и това е as good as place as any.
DHH прави една много целенасочена атака, която намирам за пълна с
грешки. Схващам какво се крие зад нея, донякъде симпатизирам с целта
му, но е твърде краен и изхвърля бебето с мръсната вода (още "покрай
бълхата изгаря юргана" или както там се превежда този идиом).
Най-големия проблем е с понятията. Представя една картина на TDD, с
която нито аз, нито хората с които съм практикувал TDD се разпознаваме.
От неговата презентация излиза, че картинката е черно-бяла. По мои
наблюдения има цял спектър от това как могат да се прилагат практиките
зад това наименование. Той обаче си избира определени точки в спектъра
и представя тях като цялото нещо.
Например кода, който показа. Не мога да говоря за всички, но аз
определено съм съгласен с неговите примери (injection-а на Date.now като
default аргумент и command pattern-а в контролера [1]) – не са по-добър
код. Уверен съм, че както хората с които съм практикувал TDD, така и
тези от които съм го учил, биха се съгласили с това. Когато аз правя
TDD, не стигам до такъв дизайн.
Друга странна мисъл бе, че Law of Demeter (и другите ОО практики) се
получават, когато се опиташ да направиш писането на такъв код да
изглежда като наука. Аз поне съм възприемал Law of Demeter, Design
Pattern-ите и всичко такова като някакви loose guidelines, които са
подходящи само за определени ситуации. Нещо повече, изглежда ми сякаш
хората, от които съм учил тези неща, също ги възприемат като такива, а
не като hard science. Просто не виждам откъде тръгна с този аргумент
покрай "псевдонаука".
Финално, слага test-first и употребата на mock-ове под една шапка. Само
първото е "TDD" и двете са ортогонални – можеш да test-first-ваш
end-to-end тестовете си и да не напишеш нито един mock. Можеш да
направиш много индиректна система и да добавиш тестовете с mock-ове в
последствие.
Цялото нещо ми смърди на logical fallacies.
В стил на Getting Real, DHH си харесва враг и го напада. Лошо няма,
само дето аз не съм убеден кой е този враг. Имена не споменати. Аз
не се сещам за много хора, които практикуват TDD както DHH го описва и
имам чувството, че по-скоро си измисля врага, отколкото го избира.
Но все пак има няколко неща, на които не мога да симпатизирам:
* "Unless you're doing test-first you are not professional" – това
определено не е вярно. Както и всички други твърдения, които казват,
че нещата могат да станат само по един начин. Не знам кои са тези
консултанти, които той сравни с книги за диети (не мисля, че и той
знае), но "The One True Way" никога не е продуктивно.
* Правенето на TDD с mock-ове (популяризирано от Growing Object-Oriented
Software, Guided by Tests) определено (1) иска тренинг за прилагане и
(2) далеч не е подходящо за всички ситуации. Начинаещите често
постигат гаден код с него – или защото го прилагат на грешното място,
или защото не обръщат внимание на грешки в mock-овете. Ако някой
оставя впечатлението, че това е универсално правилния начин за писане
на код, то това е лошо.
И тъй.
[1]: Всъщност, зад втория пример с "командата" с контролера се крие
идеята за Hexagonal Architecture. Докато в този пример индиректния
подход само нанася щета, има случаи в които това ми изглежда по-добрия
дизайн. Не съм напълно сигурен кога бих подходил така и кога с
монолитнита архитектура на Rails, но разликата между двете ми е много
интересна като тема. За повече информация може да видите една
презентация на Jim Weirich, която илюстрира идеята:
https://www.youtube.com/watch?v=tg5RFeSfBM4
--
Stefan Kanev ¦ @skanev ¦ http://skanev.com/
For systems, the analogue of a face-lift is to add to the control graph an
edge that creates a cycle, not just an additional node.
> Writing Software by DHH. <https://www.youtube.com/watch?v=9LfmrkyP81M>
Изгледах презентацията и имам малко коментари. Определено я
препоръчвам, но с едно наум.
Първо, какво ми хареса:
* Computer Scientist vs. Information System Programmer. Отдавна смятам,
че колкото по-бързо разпознаем, че вършим фундаментално различни неща,
талкова по-бързо може да започнем да учим един от друг. Ала "какво
могат да научат JavaScript програмистите от C програмистите и
обратно".
* "Read a lot of software, write a lot of software" – определено
симпатизирам с възгледа, че само с четене не става.
* Целия паралел с пиането бе страхотен. Титлата "Software writer";
цитата на Паскал (или Твен) – "Ако имах повече време, щях да ти напиша
по-кратко писмо"; The Delete key is the №1 tool for writing good code.
Не е нова идея, но беше добра представена.
* DHH е много добър презентатор и определено човек има какво да научи в
представянето на идеи от него. Всеки път е фън.
Това бяха take-away-овете от началото и края. Сега, имам няколко неща
за казване по TDD атаката по средата. Дори да не ви интересува, аз имам
нуждата да го споделя някъде и това е as good as place as any.
DHH прави една много целенасочена атака, която намирам за пълна с
грешки. Схващам какво се крие зад нея, донякъде симпатизирам с целта
му, но е твърде краен и изхвърля бебето с мръсната вода (още "покрай
бълхата изгаря юргана" или както там се превежда този идиом).
Най-големия проблем е с понятията. Представя една картина на TDD, с
която нито аз, нито хората с които съм практикувал TDD се разпознаваме.
От неговата презентация излиза, че картинката е черно-бяла. По мои
наблюдения има цял спектър от това как могат да се прилагат практиките
зад това наименование. Той обаче си избира определени точки в спектъра
и представя тях като цялото нещо.
Например кода, който показа. Не мога да говоря за всички, но аз
определено съм съгласен с неговите примери (injection-а на Date.now като
default аргумент и command pattern-а в контролера [1]) – не са по-добър
код. Уверен съм, че както хората с които съм практикувал TDD, така и
тези от които съм го учил, биха се съгласили с това. Когато аз правя
TDD, не стигам до такъв дизайн.
Друга странна мисъл бе, че Law of Demeter (и другите ОО практики) се
получават, когато се опиташ да направиш писането на такъв код да
изглежда като наука. Аз поне съм възприемал Law of Demeter, Design
Pattern-ите и всичко такова като някакви loose guidelines, които са
подходящи само за определени ситуации. Нещо повече, изглежда ми сякаш
хората, от които съм учил тези неща, също ги възприемат като такива, а
не като hard science. Просто не виждам откъде тръгна с този аргумент
покрай "псевдонаука".
Финално, слага test-first и употребата на mock-ове под една шапка. Само
първото е "TDD" и двете са ортогонални – можеш да test-first-ваш
end-to-end тестовете си и да не напишеш нито един mock. Можеш да
направиш много индиректна система и да добавиш тестовете с mock-ове в
последствие.
Цялото нещо ми смърди на logical fallacies.
В стил на Getting Real, DHH си харесва враг и го напада. Лошо няма,
само дето аз не съм убеден кой е този враг. Имена не споменати. Аз
не се сещам за много хора, които практикуват TDD както DHH го описва и
имам чувството, че по-скоро си измисля врага, отколкото го избира.
Но все пак има няколко неща, на които не мога да симпатизирам:
* "Unless you're doing test-first you are not professional" – това
определено не е вярно. Както и всички други твърдения, които казват,
че нещата могат да станат само по един начин. Не знам кои са тези
консултанти, които той сравни с книги за диети (не мисля, че и той
знае), но "The One True Way" никога не е продуктивно.
* Правенето на TDD с mock-ове (популяризирано от Growing Object-Oriented
Software, Guided by Tests) определено (1) иска тренинг за прилагане и
(2) далеч не е подходящо за всички ситуации. Начинаещите често
постигат гаден код с него – или защото го прилагат на грешното място,
или защото не обръщат внимание на грешки в mock-овете. Ако някой
оставя впечатлението, че това е универсално правилния начин за писане
на код, то това е лошо.
И тъй.
[1]: Всъщност, зад втория пример с "командата" с контролера се крие
идеята за Hexagonal Architecture. Докато в този пример индиректния
подход само нанася щета, има случаи в които това ми изглежда по-добрия
дизайн. Не съм напълно сигурен кога бих подходил така и кога с
монолитнита архитектура на Rails, но разликата между двете ми е много
интересна като тема. За повече информация може да видите една
презентация на Jim Weirich, която илюстрира идеята:
https://www.youtube.com/watch?v=tg5RFeSfBM4
--
Stefan Kanev ¦ @skanev ¦ http://skanev.com/
For systems, the analogue of a face-lift is to add to the control graph an
edge that creates a cycle, not just an additional node.
Hristo Deshev
May 10, 2014, 10:29:08 AM5/10/14
to polyglo...@googlegroups.com
On 05/10/2014 11:54 AM, Stefan Kanev wrote:
> On 09/05/14, Slavomir Kaslev wrote:
>> Writing Software by DHH. <https://www.youtube.com/watch?v=9LfmrkyP81M>
>
За пълнота пускам линк към разговора на DHH с Кент Бек и Мартин Фаулър
> On 09/05/14, Slavomir Kaslev wrote:
>> Writing Software by DHH. <https://www.youtube.com/watch?v=9LfmrkyP81M>
>
след въпросната презентация:
https://www.youtube.com/watch?v=z9quxZsLcfo
Дешев
Andrew
May 11, 2014, 6:34:53 AM5/11/14
to polyglo...@googlegroups.com
Не съм гледал презентацията, така че не мога да коментирам по нея, но ето някои бележки по коментара на Стефан.
> В стил на Getting Real, DHH си харесва враг и го напада. Лошо няма, само
> дето аз не съм убеден кой е този враг. Имена не споменати. Аз не се сещам
> за много хора, които практикуват TDD както DHH го описва и имам чувството, че
> по-скоро си измисля врага, отколкото го избира.
>
> [...]
>
> Не знам кои са тези консултанти, които той сравни с книги за диети (не мисля,
> че и той знае)
Uncle Bob и последователите му. Виж тази статия (публикувана след лекцията):
http://blog.8thlight.com/uncle-bob/2014/05/02/ProfessionalismAndTDD.html.
Като за начало:
> First of all, if you read that article from 2007, you'll see that I don't
> believe that TDD is a prerequisite to professionalism. What I believe is that
> it currently plays a significant role in professional behavior. I also
> believe it will play a much greater role as we look into the future.
Което звучи смислено. От друга страна,
> If I am right... If TDD is as significant to software as hand-washing was to
> medicine and is instrumental in pulling us back from the brink of that
> looming catastrophe, then Kent Beck will be hailed a hero, and TDD will carry
> the full weight of professionalism. After that, those who refuse to practice
> TDD will be excused from the ranks of professional programmers. It would not
> surprise me if, one day, TDD had the force of law behind it.
Хем твърди, че TDD не е всичко, хем се надява, че в бъдеще ще има закони, които да го налагат.
Чичо Боб често е екстремен в твърденията си. Хвърли едно око на този gist, където @sandal се опитва да смекчи аргументите му и да премахне излишния екстремизъм: https://gist.github.com/sandal/1c6c7ec0d7603775ed17. Разговора в коментарите ми е най-интересната част, примерно:
> I actually like the Uncle Bob persona! There is certainly value to having a
> clear voice in writing, and it has the (positive) subversive effect of
> getting people to let down their guard enough and pay attention. I just wish
> that Uncle Bob wasn't turned all the way up to 11, it'd be nice at a level of
> 6 or 7.
>
> Also it's worth remembering that the more controversial an issue is, the more
> care you need to put into how you present yourself. What would be immediately
> recognized as playful hyperbole in a less contentious issue may be read
> literally and critically in a more heated issue.
Друго,
http://blog.8thlight.com/uncle-bob/2014/05/02/ProfessionalismAndTDD.html.
Като за начало:
> First of all, if you read that article from 2007, you'll see that I don't
> believe that TDD is a prerequisite to professionalism. What I believe is that
> it currently plays a significant role in professional behavior. I also
> believe it will play a much greater role as we look into the future.
Което звучи смислено. От друга страна,
> If I am right... If TDD is as significant to software as hand-washing was to
> medicine and is instrumental in pulling us back from the brink of that
> looming catastrophe, then Kent Beck will be hailed a hero, and TDD will carry
> the full weight of professionalism. After that, those who refuse to practice
> TDD will be excused from the ranks of professional programmers. It would not
> surprise me if, one day, TDD had the force of law behind it.
Хем твърди, че TDD не е всичко, хем се надява, че в бъдеще ще има закони, които да го налагат.
Чичо Боб често е екстремен в твърденията си. Хвърли едно око на този gist, където @sandal се опитва да смекчи аргументите му и да премахне излишния екстремизъм: https://gist.github.com/sandal/1c6c7ec0d7603775ed17. Разговора в коментарите ми е най-интересната част, примерно:
> I actually like the Uncle Bob persona! There is certainly value to having a
> clear voice in writing, and it has the (positive) subversive effect of
> getting people to let down their guard enough and pay attention. I just wish
> that Uncle Bob wasn't turned all the way up to 11, it'd be nice at a level of
> 6 or 7.
>
> Also it's worth remembering that the more controversial an issue is, the more
> care you need to put into how you present yourself. What would be immediately
> recognized as playful hyperbole in a less contentious issue may be read
> literally and critically in a more heated issue.
Друго,
> Финално, слага test-first и употребата на mock-ове под една шапка.
Той слага доста неща под шапката на TDD, съгласен съм. Мисля, че причината за това са многото разнообразни критики, който получава покрай рейлс. Има критики към ActiveRecord, хора искат да ползват по-модулярни обекти вместо контролери, не помня какво още. Трудно ми е да намеря добри представителни примери, но хавата е такава, поне в моя twitter feed. Бях на една цяла конференция (wroclove), където атмосферата беше такава. Немалко хора обявиха, че Rails трябва да умре и да намерим нещо друго, а също и че е било грешка по принцип, но преди 7 години сме се подлъгали и не сме го разбрали. Това са анекдоти, но и ти разчиташ на анекдоти на моменти ("хората с които съм практикувал TDD, така и тези от които съм го учил"). Може би просто имаме видимост върху различни страни на Rails обществото.
DHH вероятно избира TDD като ъгъл на атака, понеже повечето статии, които говорят за interactors, hexagonal, отделен клас за всеки controller action (https://github.com/jonleighton/focused_controller), и прочее, изтъкват "по-лесно се тества в изолация" като аргумент. Ясно ти е, че това не е единствената цел, но е по-лесно за него да захапе TDD, вместо целия обхват от неща. И той е подобен на Uncle Bob в това, че винаги е на 11.
Also see: http://www.dhh-ping-pong.com/. Не бих се учудил оттам да е добил идеи за това колко overengineer-ват някои хора. Разбира се, в този формат трудно може да се прецени контекста на цялостното приложение, но няма да задълбавам.
DHH вероятно избира TDD като ъгъл на атака, понеже повечето статии, които говорят за interactors, hexagonal, отделен клас за всеки controller action (https://github.com/jonleighton/focused_controller), и прочее, изтъкват "по-лесно се тества в изолация" като аргумент. Ясно ти е, че това не е единствената цел, но е по-лесно за него да захапе TDD, вместо целия обхват от неща. И той е подобен на Uncle Bob в това, че винаги е на 11.
Also see: http://www.dhh-ping-pong.com/. Не бих се учудил оттам да е добил идеи за това колко overengineer-ват някои хора. Разбира се, в този формат трудно може да се прецени контекста на цялостното приложение, но няма да задълбавам.
> Цялото нещо ми смърди на logical fallacies.
Gary Bernhardt е съгласен с теб: https://www.destroyallsoftware.com/blog/2014/tdd-straw-men-and-rhetoric
Поздрави, Андрей.
Поздрави, Андрей.
Stefan Kanev
May 11, 2014, 10:25:24 AM5/11/14
to polyglo...@googlegroups.com
On 11/05/14, Andrew wrote:
> > В стил на Getting Real, DHH си харесва враг и го напада.
> >
> > В стил на Getting Real, DHH си харесва враг и го напада.
> >
> > [...]
> >
> > Не знам кои са тези консултанти, които той сравни с книги за диети
> > (не мисля, че и той знае)
>
> Uncle Bob и последователите му. [...]
> >
> > Не знам кои са тези консултанти, които той сравни с книги за диети
> > (не мисля, че и той знае)
>
Виж, това не го знаех – мерси. Да си го бе нападнал него. След като го
написах, си помислих, че вероятно е Avdi Grimm и хората около него.
Injection-а на датата е типичен негова странност. Отвъд това съм
напълно съгласен с цитирания от теб коментар и нямам какво да кажа, ще
споделя любимата си история с името на Чичо Боб в нея.
Mingle-вам аз на първото NordicRuby и с един пич се заговаряме за нещо.
Не помня каква бе темата, но в един момент си викам "ех, колко хубав и
убедителен аргумент ще построя тук". Започвам да разказвам някаква
Uncle Bob-щина (например TDD) и най-накрая завършвам с нещо от рода на
"...и нали, това не е само мое мнение. Чичо Боб, голям експерт в
областта, смята същото. Знаеш ли го?". Пича ми отговори с "Татко ли?
Да, знам го.".
What are the chances. Мисля, че от тогава започнах да избягвам Appeal
to Authority :)
> > Финално, слага test-first и употребата на mock-ове под една шапка.
>
> Той слага доста неща под шапката на TDD, съгласен съм. Мисля, че причината
> за това са многото разнообразни критики, който получава покрай рейлс. Има
> критики към ActiveRecord, хора искат да ползват по-модулярни обекти вместо
> контролери, не помня какво още. Трудно ми е да намеря добри представителни
> примери, но хавата е такава, поне в моя twitter feed. Бях на една цяла
> конференция (wroclove), където атмосферата беше такава. Немалко хора
> обявиха, че Rails трябва да умре и да намерим нещо друго, а също и че е
> било грешка по принцип, но преди 7 години сме се подлъгали и не сме го
> разбрали. Това са анекдоти, но и ти разчиташ на анекдоти на моменти
> ("хората с които съм практикувал TDD, така и тези от които съм го учил").
> Може би просто имаме видимост върху различни страни на Rails обществото.
но определено съм страдал от тия проблеми (не помня дали не сме страдали
заедно). Смятам монолитността на Rails за безценна в началото, но има
момент, в който човек стига до нуждата от шестоъгълници и тук Rails не
scale-ва. В смисъл, че трудно се минава от едното към другото.
Интересно ми е какво може да се направи по въпроса. Нямам конкретно
решение, просто обичам да дъвкам въпроса. Ако си навит, нали :)
> DHH вероятно избира TDD като ъгъл на атака, понеже повечето статии, които
> говорят за interactors, hexagonal, отделен клас за всеки controller action
> (https://github.com/jonleighton/focused_controller), и прочее, изтъкват
> "по-лесно се тества в изолация" като аргумент. Ясно ти е, че това не е
> единствената цел, но е по-лесно за него да захапе TDD, вместо целия обхват
> от неща. И той е подобен на Uncle Bob в това, че винаги е на 11.
> Also see: http://www.dhh-ping-pong.com/. Не бих се учудил оттам да е добил
> идеи за това колко overengineer-ват някои хора. Разбира се, в този формат
> трудно може да се прецени контекста на цялостното приложение, но няма да
> задълбавам.
Уви, това е проблема на този вид дизайн – рядко изглежда добре в малки
примери. Трябва контекст.
> > Цялото нещо ми смърди на logical fallacies.
>
> Gary Bernhardt е съгласен с теб:
> https://www.destroyallsoftware.com/blog/2014/tdd-straw-men-and-rhetoric
тинейджърка на концерт на Backstreet Boys. Или там каквото слушат
тинейджърките в днешно време. <3
The best book on programming for the layman is "Alice in Wonderland"; but
that's because it's the best book on anything for the layman.
Andrew
May 11, 2014, 1:41:50 PM5/11/14
to polyglo...@googlegroups.com
> Смятам монолитността на Rails за безценна в началото, но има
> момент, в който човек стига до нуждата от шестоъгълници и тук Rails не
> scale-ва. В смисъл, че трудно се минава от едното към другото.
> Интересно ми е какво може да се направи по въпроса. Нямам конкретно
> решение, просто обичам да дъвкам въпроса. Ако си навит, нали :)
> момент, в който човек стига до нуждата от шестоъгълници и тук Rails не
> scale-ва. В смисъл, че трудно се минава от едното към другото.
> Интересно ми е какво може да се направи по въпроса. Нямам конкретно
> решение, просто обичам да дъвкам въпроса. Ако си навит, нали :)
Навит съм на скайп кол (или публичен Google Hangout, хе-хе), но се опасявам, че съм неподготвен. Все още не съм дочел нещата за шестоъгълната архитектура. Пробвах веднъж, след първите няколко параграфа ми доскуча и се отказах. И аз нямам решение на въпроса, но нямам нищо против да разцъкаме темата.
Iskren Chernev
May 11, 2014, 2:44:21 PM5/11/14
to polyglo...@googlegroups.com
Аз искам да коментирам върху концепцията за четим код.
Според DHH, дали един код е четим зависи от човека който го чете, и
сам отбелязва, че това е субективно точно като в художествената
литература. Съгласен съм, че в момента ситуацията е такава, но не
смятам, че трябва да бъде. От моя скромен опит (работа в компания, а
не contractor в малки проекти с 1-3ма инженера) съм забелязал, че
всеки има различно мнение по въпроса кое как трябва да стане, и понеже
няма аксиоматика за да се види кое наистина е "правилно", често печели
човека който е по-упорит и твърдоглав. Това няма добро отражение върху
качеството/четимостта на кода.
Вместо да се сравняваме с писатели, където наистина не е ясно кой
какво точно иска да каже, но пък и на никой не му пука чак толкова
дали е разбрал правилно дадена творба, не може ли да се изградят
редица правила за всеки език, която прогресивно да "затяга" кода, в
зависимост от неговия размер. Разбира се това върви ръка за ръка с
инструмент (lint) който да прилага правилата и даже сам да поправя
дребните отклонения.
Както тестовете имат предимство да са безпристрастни, да е лесно да се
повторят и да показват какво не е добре с кода, така и такъв lint
инструмент ще пази кода от това да се превърне в неразбираема черна
кутия със времето. Не виждам защо описанието на това какво трябва а
върши кода се записва в тестове (за да проверяваме постоянно дали той
върши това което трябва), но стилистичните и архитектурни проблеми за
които така често говорим се оставят на съсредоточеността на
програмиста, и човека който прави code reivew. Също като да кажеш "аз
си прочетох кода, изглежда верен" -- просто е безумие :)
Съгласен съм, че написването на такъв осъвършенстван lint е сложна
задача, но даже не разполагаме с правилата за това кое е приемливо и
кое не. Докато това не съществува винаги 90% от кода ще бъде shit,
защото не може да разчитаме, че най-добрите 1% програмисти пишат
всичко.
Според DHH, дали един код е четим зависи от човека който го чете, и
сам отбелязва, че това е субективно точно като в художествената
литература. Съгласен съм, че в момента ситуацията е такава, но не
смятам, че трябва да бъде. От моя скромен опит (работа в компания, а
не contractor в малки проекти с 1-3ма инженера) съм забелязал, че
всеки има различно мнение по въпроса кое как трябва да стане, и понеже
няма аксиоматика за да се види кое наистина е "правилно", често печели
човека който е по-упорит и твърдоглав. Това няма добро отражение върху
качеството/четимостта на кода.
Вместо да се сравняваме с писатели, където наистина не е ясно кой
какво точно иска да каже, но пък и на никой не му пука чак толкова
дали е разбрал правилно дадена творба, не може ли да се изградят
редица правила за всеки език, която прогресивно да "затяга" кода, в
зависимост от неговия размер. Разбира се това върви ръка за ръка с
инструмент (lint) който да прилага правилата и даже сам да поправя
дребните отклонения.
Както тестовете имат предимство да са безпристрастни, да е лесно да се
повторят и да показват какво не е добре с кода, така и такъв lint
инструмент ще пази кода от това да се превърне в неразбираема черна
кутия със времето. Не виждам защо описанието на това какво трябва а
върши кода се записва в тестове (за да проверяваме постоянно дали той
върши това което трябва), но стилистичните и архитектурни проблеми за
които така често говорим се оставят на съсредоточеността на
програмиста, и човека който прави code reivew. Също като да кажеш "аз
си прочетох кода, изглежда верен" -- просто е безумие :)
Съгласен съм, че написването на такъв осъвършенстван lint е сложна
задача, но даже не разполагаме с правилата за това кое е приемливо и
кое не. Докато това не съществува винаги 90% от кода ще бъде shit,
защото не може да разчитаме, че най-добрите 1% програмисти пишат
всичко.
Hristo Deshev
May 12, 2014, 4:06:41 AM5/12/14
to polyglo...@googlegroups.com
On 05/11/2014 05:25 PM, Stefan Kanev wrote:
...
са същите. Тези фреймуърци са страхотни за бързо пускане на някакъв апп.
И се провалят безобразно, когато проектът порасне над няколкомесечно
усилие. Който е работил по "система", която се състои от един единствен
"сайт" проект за Рейлс/Джанго, където са "творили" Х (Х > 2) програмиста
над половин година знае много добре за какво става дума.
>
>> DHH вероятно избира TDD като ъгъл на атака, понеже повечето статии, които
>> говорят за interactors, hexagonal, отделен клас за всеки controller action
>> (https://github.com/jonleighton/focused_controller), и прочее, изтъкват
>> "по-лесно се тества в изолация" като аргумент. Ясно ти е, че това не е
>> единствената цел, но е по-лесно за него да захапе TDD, вместо целия обхват
>> от неща. И той е подобен на Uncle Bob в това, че винаги е на 11.
Тук е същото нещо, но наобратно. Както не можем да твърдим, че Рейлс е
сбъркан, защото не "скейлва" при големи приложения, така и не можем да
твърдим, че техниките за правене на големи приложения са сбъркани когато
ги прилагаме за прости системи.
В този ред на мисли, не виждам проблем в поп-фолк интеграционно тестване
с истинска база за малки системи. Или прескачането на тестването на
разни "прости" неща, които не ни е страх да счупим. Но това не трябва да
е начинът на работа, когато правим нещо по-голямо.
За да завършим темата с моковете и "истинското" тестване, ще предложа
Integrated Tests are a Scam лекцията на J.B. Rainsberger:
http://vimeo.com/80533536
Поздрави,
Дешев
...
> Тук закачаме друга любима моя тема. Аз не смятам, че Rails е сгрешен,
> но определено съм страдал от тия проблеми (не помня дали не сме страдали
> заедно). Смятам монолитността на Rails за безценна в началото, но има
> момент, в който човек стига до нуждата от шестоъгълници и тук Rails не
> scale-ва. В смисъл, че трудно се минава от едното към другото.
> Интересно ми е какво може да се направи по въпроса. Нямам конкретно
> решение, просто обичам да дъвкам въпроса. Ако си навит, нали :)
Напълно съгласен тук. Аз се занимавам повече с Джанго, но там проблемите
> но определено съм страдал от тия проблеми (не помня дали не сме страдали
> заедно). Смятам монолитността на Rails за безценна в началото, но има
> момент, в който човек стига до нуждата от шестоъгълници и тук Rails не
> scale-ва. В смисъл, че трудно се минава от едното към другото.
> Интересно ми е какво може да се направи по въпроса. Нямам конкретно
> решение, просто обичам да дъвкам въпроса. Ако си навит, нали :)
са същите. Тези фреймуърци са страхотни за бързо пускане на някакъв апп.
И се провалят безобразно, когато проектът порасне над няколкомесечно
усилие. Който е работил по "система", която се състои от един единствен
"сайт" проект за Рейлс/Джанго, където са "творили" Х (Х > 2) програмиста
над половин година знае много добре за какво става дума.
>
>> DHH вероятно избира TDD като ъгъл на атака, понеже повечето статии, които
>> говорят за interactors, hexagonal, отделен клас за всеки controller action
>> (https://github.com/jonleighton/focused_controller), и прочее, изтъкват
>> "по-лесно се тества в изолация" като аргумент. Ясно ти е, че това не е
>> единствената цел, но е по-лесно за него да захапе TDD, вместо целия обхват
>> от неща. И той е подобен на Uncle Bob в това, че винаги е на 11.
сбъркан, защото не "скейлва" при големи приложения, така и не можем да
твърдим, че техниките за правене на големи приложения са сбъркани когато
ги прилагаме за прости системи.
В този ред на мисли, не виждам проблем в поп-фолк интеграционно тестване
с истинска база за малки системи. Или прескачането на тестването на
разни "прости" неща, които не ни е страх да счупим. Но това не трябва да
е начинът на работа, когато правим нещо по-голямо.
За да завършим темата с моковете и "истинското" тестване, ще предложа
Integrated Tests are a Scam лекцията на J.B. Rainsberger:
http://vimeo.com/80533536
Поздрави,
Дешев
Stefan Kanev
May 12, 2014, 4:13:03 AM5/12/14
to polyglo...@googlegroups.com
Аз съм твърдо зад имането на някакъв lint, но за мен той не решава
кой-знае-колко големи проблеми свързани с разбирането. Може да те пази
от настъпване на мотика (изпуснат var в JavaScript) или да се увери, че
конвенцията е спазена, но тези неща не са пряко свързани с
"разбираемостта" на кода. Може да се опита да прилага правила от рода
на "най-много седем метода в клас" и "най-много 20 реда на метод", но те
няма как да работят в 100% от случаите (или дори 100%). Могат да
предотвратят някои каши, но не правят кода четим.
За мен едни от двете най-важни неща в разбирането на кода са имената и
нивото на абстракция. Първото е очевидно. За второто – ако видиш
примерите на DHH, те са на хубаво ниво – показват само най-релевантната
част и скриват ненужни неща (заявки към бази, HTTP query string-ове,
HTTP Response кодове). И двете ми се струват фундаментално
"интелектуален" проблем. Затова ми харесва паралела с писане – ако
пишеш учебник, например, ще първо ще избереш добри имена и после ще
предаваш информацията на малки, консистентни части.
Разбира се, това са само отнесени размишления. Как точно виждаш идеята
за квалифициране на тези неща?
Don't have good ideas if you aren't willing to be responsible for them.
Hristo Deshev
May 12, 2014, 4:25:09 AM5/12/14
to polyglo...@googlegroups.com
On 05/11/2014 09:44 PM, Iskren Chernev wrote:
> Аз искам да коментирам върху концепцията за четим код.
>
> Според DHH, дали един код е четим зависи от човека който го чете, и
> сам отбелязва, че това е субективно точно като в художествената
> литература. Съгласен съм, че в момента ситуацията е такава, но не
> смятам, че трябва да бъде. От моя скромен опит (работа в компания, а
> не contractor в малки проекти с 1-3ма инженера) съм забелязал, че
> всеки има различно мнение по въпроса кое как трябва да стане, и понеже
> няма аксиоматика за да се види кое наистина е "правилно", често печели
> човека който е по-упорит и твърдоглав. Това няма добро отражение върху
> качеството/четимостта на кода.
DHH много плю по използването на тестваемост (testability) като критерий
> Аз искам да коментирам върху концепцията за четим код.
>
> Според DHH, дали един код е четим зависи от човека който го чете, и
> сам отбелязва, че това е субективно точно като в художествената
> литература. Съгласен съм, че в момента ситуацията е такава, но не
> смятам, че трябва да бъде. От моя скромен опит (работа в компания, а
> не contractor в малки проекти с 1-3ма инженера) съм забелязал, че
> всеки има различно мнение по въпроса кое как трябва да стане, и понеже
> няма аксиоматика за да се види кое наистина е "правилно", често печели
> човека който е по-упорит и твърдоглав. Това няма добро отражение върху
> качеството/четимостта на кода.
за дизайна, но аз си мисля, че въпреки всичко това си остава доста добро
мерило. Или поне по-добро от всички останали много по-абстрактни метрики
като "красота", "чистота", "елегантност", "четимост". От известно време
нарочно се опитвам да си избивам от главата такива неща и да си налагам
да потърпя и да продължа с дизайн на кода, който не ми харесва
естетически, но върши работа и е тестван адекватно. Често по-късно
разбирам истинската причина, заради която не ми е харесвал, но понякога
стават изненади и научавам нещо ново.
Това е и много добра насока за начинаещи програмисти. Вместо да развиваш
поетични причини за това кое е по-красиво, направо показваш, как подход
Х се тества трудно и затова подход Y е за предпочитане. Обучаваният
получава просветление, започва да вижда metapatterns във вселената и
въпросът приключва. (https://xkcd.com/224/)
>
> Вместо да се сравняваме с писатели, където наистина не е ясно кой
> какво точно иска да каже, но пък и на никой не му пука чак толкова
> дали е разбрал правилно дадена творба, не може ли да се изградят
> редица правила за всеки език, която прогресивно да "затяга" кода, в
> зависимост от неговия размер. Разбира се това върви ръка за ръка с
> инструмент (lint) който да прилага правилата и даже сам да поправя
> дребните отклонения.
Lint инструментът само ще пречи в малка система. В голяма система може
пък да ти помогне да навлезеш в начина на писане на код, а може и да те
отчая с излишна бюрокрация и тъпи правила за следване (пример: JSLint на
Crockford!). Също така не знам как бихме написали линт за архитектурни
решения. :)
>
> Съгласен съм, че написването на такъв осъвършенстван lint е сложна
> задача, но даже не разполагаме с правилата за това кое е приемливо и
> кое не. Докато това не съществува винаги 90% от кода ще бъде shit,
> защото не може да разчитаме, че най-добрите 1% програмисти пишат
> всичко.
твърдя, че кодът на хипотетичния lint инструмент ще бъде също 90% shit
:D. Това е напълно нормално и няма нужда да си режем вените, защото не
можем да го променим. По-добре да си избираме битките и да се радваме,
когато попаднем или създадем нещо от другите 10%.
Дешев
Andrew
May 12, 2014, 2:06:28 PM5/12/14
to polyglo...@googlegroups.com
> Кодът е директно отражение на реалния живот, където 90% е shit. Смея да
> твърдя, че кодът на хипотетичния lint инструмент ще бъде също 90% shit
> :D.
> твърдя, че кодът на хипотетичния lint инструмент ще бъде също 90% shit
> :D.
Няма проблеми. Само да го напишем, просто ще пуснем lint-а върху собствения му код и ще го оправим. :)
Iskren Chernev
May 14, 2014, 12:40:13 AM5/14/14
to polyglo...@googlegroups.com
Ще започна със cyclomatic complexity: това е един начин да се провери
сложността на някоя фунция. Основната идея е да се види колко
code-path-а има през кода, за целта се броят case-овете на
if/else/switch/for и умножава при конкатенация на 2 фрагмента (2
последователни if-а имат cyclomatic complexity 4).
После имам нещо в главата, което смята къде се използват променливите.
Например, ако създадеш една променлива и я ползваш на 1 място -- това
е ок. Обаче ако я използваш на 1 място и после след 200 реда пак
(същата функция) -- това не е хубаво защото има повече контекст да
пази човек в главата си като чете. Освен това, дълги методи тривиално
с анализ на променливите се вижда как да се разцепят на по-малки и
какви променливи да се подават на отделните части.
Просто трябва да измислим начин да мерим колко е сложно парче код,
плитко (на ниво един метод) и дълбоко (като се вземат предвид
функциите които вика). Ако се вдигне много сложността на проекта може
да предложи разделяне (и да предложи кое да се раздели).
Просто виждам как наистина кофти парчета код мнозинството от
програмистите ще кажат, че не е добре написан. Не трябва да е твърде
сложно да се автоматизира.
Относно променливите и концепциите -- тоя проблем и хората не могат да
го решат още. Мисля, че има по-лесни задачи, които ще доведат до
по-малко code suck.
Явно трябва да седна малко с jshint да видя какво може да се изкоди
набързо, за да не звучи толкова абстрактно.
Искрен
Andrew
May 14, 2014, 4:44:58 AM5/14/14
to polyglo...@googlegroups.com
> Явно трябва да седна малко с jshint да видя какво може да се изкоди
> набързо, за да не звучи толкова абстрактно.
> набързо, за да не звучи толкова абстрактно.
Има доста инструменти за подобни метрики. Като си тръгнал, може да погледнеш и flog и flay за руби:
http://ruby.sadi.st/Flog.html
http://ruby.sadi.st/Flay.html
Не знам дали са поддържани много добре, Ryan Davis от доста време не съм го чувал.
CodeClimate също са популярни в руби света: https://codeclimate.com/. Едва ли алгоритмите има са open-source, но ако си вържеш проекта и следиш за какви неща се оплакват, може би можеш да си направиш собствени изводи.
http://ruby.sadi.st/Flog.html
http://ruby.sadi.st/Flay.html
Не знам дали са поддържани много добре, Ryan Davis от доста време не съм го чувал.
CodeClimate също са популярни в руби света: https://codeclimate.com/. Едва ли алгоритмите има са open-source, но ако си вържеш проекта и следиш за какви неща се оплакват, може би можеш да си направиш собствени изводи.
Reply all
Reply to author
Forward
0 new messages