?

Log in

No account? Create an account
November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
cartoon

eXtreme programming

Posted on 2010.10.25 at 03:03
Tags: , ,
Похоже, теперь я знаю, как его придумали, и почему оно именно такое. А также - почему оно кажется таким странным программистам, имевшим дело со строготипизированными языками.

Всего-то надо было как следует потрахаться с JavaScript.

Я ненавижу этот язык, и ненавижу XP. К сожалению, XP оптимальный способ писать на JavaScript, в противном случае можно смело стреляться. Поэтому, лучше на этом говне по возможности вообще не писать, а генерировать его из чего-нить строготипизированного.

В двух словах, почему так. XP является практически прямым следствием процессной теории применительно к наблюдаемым мной классам ошибок и стоимости их исправления для этого дебильного языка.

Почему тесты вперед? Потому што по другому _вообще никаких_ ошибок не увидеть. А какой смысл писать много кода, не имея возможности даже заметить опечаток? Если так делать, то цена ошибки возрастает просто ацки.

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

Почему парное программирование как основная практика? Потому, что дешевых ошибок не бывает, и их слишком легко допустить, ибо сам процесс затратен и геморроен. Блин, даже хедеров с типами, чтобы коллегам показать, нет :). Что делаем? Правильно, постоянное непрерывное code review (aka pair programming) становится в таких условиях дешевле.

И самое странное - почему полдня колбасим, а полдня рефакторим? Да потому, что из-за отсутствия какой-либо декларации типов и интерфейсов, которые механически проверяются, и "микроитеративности" разработки (изменения проводят серией маленьких шажков и сразу тестируют - так дешевле) в процессе работы очень быстро образуются тонны говнокода. Причем - если пытаться смешивать рефакторинг и разработку - мозг взрывается и продуктивность падает. Реально можно делать что-то одно.

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

Какое же фантастическое говно этот JavaScript.

ЗЫ: Кстати. О больном месте JavaScript - о модулях, вернее, об их отсутствии.

Самое толковое, что из работающего на эту тему есть - это вот эта штука.
http://requirejs.org/
Она нейтральна к применяемому фреймворку. И она реально работает.

У нее есть небольшой косяк - определения модулей выглядят так, что сносят крышу. И, кстати, они еще, как бы это сказать - error-prone. Да сами посудите.

require.def( 'main',
      [ 'view/cart', 'view/categories', 'view/search', 'view/item' ],
   function( CartView, CategoriesView, SearchView, ItemView ){
      return function(){ типо например конструктор }

   })


Так вот, я в процессе обсуждения сговнякал за 5 минут простой враппер вокруг require.js, который его подсахаривает, и заставляет модуля выглядеть прилично.

Пользоваться так. Примерно такая хрень должна быть в заглавном HTML-е.
	 module.main({
	    baseUrl: "/term/newui", //это - корень для путей.
	    waitSeconds: 15, // это таймаут.
	    paths: {
	       core: "lib/core", // это - "символические линки" типо.
	       gears: "lib/gears"
	    }
         })
	 .require({ // и панеслась инклудить модуля...
	    View : 'main', 
	    Items : 'model/items',
	    Network: 'network/main'
	 })
	 .body( function( _ ){ // теперь - определяем тело модуля.
	    items = new _.Items( 'test_store', 10 ); // 
	    view = new _.View();
	    network = new _.Network( items );
	    network.start();
	    $('#prompt').hide();
	    $('#screen').show();	 
	 });


Вот и все. В модулях - все почти так же. Вот так.

module( 'my_mod' )
.body( function(){
   return ...;
});


Или так:
module( 'my_mod_2' )
.require({
   my_mod: 'my_mod'
})
.body( function( _ ){
   return _.my_mod.something;
});


А вот и сам код враппера.

      var module = function(){
	 function Do( a_name, require_f ){
	     var _addr = [];
	     var _name = [];
     
	     this.require = function( a_obj ){
		 for( var x in a_obj ){
		     _addr.push( a_obj[ x ] );
		     _name.push( x );
		 }
		 
		 return this;
	     }
	     
	     this.body = function( a_fun ){
		 return require_f( a_name, _addr, function(){
		     var import_obj = {};
		     for( var i = 0; i < arguments.length; i ++ ){
			 import_obj[ _name[ i ] ] = arguments[ i ];
		     }
		     
		     return a_fun( import_obj );
		 });
	     }
	 }
            
	 function module( a_name ){
	    return new Do( a_name, require.def );
	 }
	 
	 module.main = function( a_obj ){
	    return new Do( a_obj, require );	 
	 }
	 
	 return module;
      }();

Comments:


Page 1 of 2
<<[1] [2] >>
Unshaven and Drunk
rlabs at 2010-10-24 23:14 (UTC) (Link)
на первый взгляд, между всеми этими терминами, включая XP, строготипизированные и JS, нет никакой связи.
Gaperton
gaperton at 2010-10-24 23:24 (UTC) (Link)
Ну, у меня-то не первый взгляд.
Djuffin
djuffin at 2010-10-24 23:29 (UTC) (Link)
То же самое (в несколько меньшей степени) относится к Python и Ruby.
Gaperton
gaperton at 2010-10-25 00:19 (UTC) (Link)
Ну, динамика динамике рознь.

Например, компилятор Эрланга проверяет соответствие имен функций и количества аргументов при вызове в статике. Это, оказывается, вовсе не мелочь, а уже _очень_ много.

А XP родился в проекте на Smalltalk, который такой же в доску динамический, как JS. Оказывается, это очень существенно. Не ожидал, что все может быть _настолько_ плохо, что XP окажется по сути единственным выходом. В Эрланге, например, все не так.
Алексей Могильников
amogilnikov at 2010-10-25 00:02 (UTC) (Link)
Почему всё выше описанное про JS не относится к Эрлангу? :)
Lev Walkin
lionet at 2010-10-25 00:15 (UTC) (Link)
Эрланг строго типизирован, в отличие от JS.
alexsoff
alexsoff at 2010-10-25 02:42 (UTC) (Link)
В общем верно. Хотя и не так страшно. (И действительно касается и Ruby с Python-ом.)
После пары лет опыта, непрерывное ревью с парным программированием уже на столь обязательно.
А модули можно выделять через "языковую инкапсуляцию" (протокол, DSL)... и раздавать на опытных разработчиков (с помошниками).
Вполне стабильный продукт в итоге получается.
Gaperton
gaperton at 2010-10-25 10:10 (UTC) (Link)
Ну, мне же от модулей еще и корректная подгрузка по зависимостям нужна.Такие модули, например, нейтральным к фреймворку образом, через require.js.

Но толку-то от этого.
Яков Сироткин
yakov_sirotkin at 2010-10-25 04:31 (UTC) (Link)
Про тесты и динамические языки вопрос понятен, но JavaScript делали для веб-страничек, а то, что там пользователь вбивает и что ему показывают - это не типизированные данные по сути. И JavaScipt это более-менее отражает.

GWT уже сделали, вот только программисты на Swing все повымерли. Как программировать на JavaScipt - это ещё учиться нужно.
ja?
jak40 at 2010-10-25 05:53 (UTC) (Link)
О, не ожидал такого громкохудожественного крика души!
В любом случае, получилось убедительно.

(+ насколько я помню, ХР работало уже при программировании на больших машинах с большими колодами из больших перфокарт с маленькими дырочками, ьлдбко так не называлось, а JS - это, конечно, отдельная песнь:)
Serguey Zefirov
thesz at 2010-10-25 06:40 (UTC) (Link)
>ХР работало уже при программировании на больших машинах с большими колодами из больших перфокарт с маленькими дырочками,

Из той же оперы - компиляторы слабенькие, цена ошибки высока.
osdm at 2010-10-25 06:47 (UTC) (Link)
А опция "use strict" не помогает?
alll
alll at 2010-10-25 07:12 (UTC) (Link)
"use strict" есть в вебном жабаскрипте? как далеко наука продвинулась...
alll
alll at 2010-10-25 07:14 (UTC) (Link)
> Почему парное программирование как основная практика? Потому, что дешевых ошибок не бывает

И ещё потому, что текучка, а передавать знания в _таких_ условиях можно только от гуру к ученику.
alll
alll at 2010-10-25 07:17 (UTC) (Link)
Зря вы так про JS, очаровательное в своём роде существо. Просто не надо запихивать его в отверстие нишу, для которой он ну никак не предназначен.
Inspiration book
insanegigolo at 2010-10-25 07:24 (UTC) (Link)
Это куда же?
абстрактное синтаксическое дерево
mr_aleph at 2010-10-25 07:50 (UTC) (Link)
ну можно применять помошников типа Closure Compiler.
Роман Яковлев
pr0ximo at 2010-10-25 07:50 (UTC) (Link)
да да типичный холивар :) js действительно хорошо подходит для своих целей и его растущая популярность говорит, что он, в общем то, не такой и плохой ... особенно фреймворки на его основе, типа jquery, extjs
Gaperton
gaperton at 2010-10-25 10:29 (UTC) (Link)
Ну, каждый видит в первую очередь то, что хочет видеть.

Кто-то, например, увидит внятное описание контекста, в котором работает XP. И поймет, что то, что хорошо для С++, не есть хорошо для Смоллтока и JS.

А JS, в том виде, в котором он сейчас есть в браузерах, конечно же, плохой. Тут и говорить нечего. Более-менее нормальный его вариант - JavaScript 2.0.
b00ter
b00ter at 2010-10-25 08:43 (UTC) (Link)
Рекомендую взять FireBug или отладчик из Chrome/Safari. Меня тоже от JavaScript тошнило, ровно до момента нахождения нормального отладчика. А там и REPL есть, и воевать с языком не приходится, и писать на нем в декларативном стиле (не при помощи jQuery, но все же) вполне удобно и комфортно. Говно как правило люди, а не языки.

Да, и еще - очень рекомендую ознакомится с http://dmitrysoshnikov.com/ecmascript/javascript-the-core/ - там дается основное понимание, что такое scope и как с этим бороться.

На мой взгляд JavaScript такой же хороший язык для своих целей, как Эрланг или Клэй для своих.
Gaperton
gaperton at 2010-10-25 10:04 (UTC) (Link)
У меня уже почти готова сложная аппликуха, работающая автономно в браузере через Google Gears. И проблемы стоят несколько другого порядка.

Например, где взять нормальную систему модулей, подгружающую код по зависимостям, умеющую управляться с ресурсами, и работающую в браузере. require.js - работает, но говно. Думаю собраться, и самому написать.

А вы мне отладчики советуете. :) Трогательно :).
magicprinc
magicprinc at 2010-10-25 12:33 (UTC) (Link)
У нас с коллегой пишушим на JS было большое обсуждение: зачем нужен GWT.

Я сам на Java, а на JS мало-мало. Поэтому мог ему сказать чисто теоретически, что писать большой проект на Java удобнее. Статическая типизация начинает помогать, система состоит из модулей между которыми есть удобная навигация.

Он же активно аргументировал, что если писать код аккуратно, то с JS проблем нет, наоборот из-за его краткости (нет типов, есть closures вместо анонимных классов), код пишется быстрее, его меньше и выглядит он яснее.

Ваш опыт показывает, что всё-таки для больших проектов лучше взять GWT или Vaadin?
Gaperton
gaperton at 2010-10-25 12:43 (UTC) (Link)
Думаю, да. Любая штука, которая позволяет внятно (и одинаковым, стандартным образом) бить систему на изолированные компоненты, будет лучше, чем рукопашный JavaScript. И строгая типизация - это плюс.

Если не уходить далеко от JavaScript - можно пробовать брать Objective-J, например.
Goga_gansky
goga_gansky at 2010-10-25 12:57 (UTC) (Link)
Чот последние записи аффтара безвариантно пгружают нас в инженерно-программерские дебри, в которых люди с нехилым мозгом и воспаленными красными глазами по капле продают себя акулам софтверного бизнеса.

А где же посты про жизнь? Где ее живое биение, наблюдаемое через призму вымышленных персонажей? Так недолго и раствориться в матрице... проснуться как-нибудь хмурым ноябрьским утром - и обнаружить себя подвешенным вверх ногами между кристаллами процессора в недрах материнской платы :))
pingback_bot
pingback_bot at 2010-10-25 13:35 (UTC) (Link)

XP

User shebnik referenced to your post from XP saying: [...] Отжиг на тему "Откуда есть пошло eXtreme Programming" http://gaperton.livejournal.com/51646.html [...]
Previous Entry  Next Entry