Методология, култура и начин на
мислене: Това го написах в началото на 2007, във wiki на проекта ХОР, при
разширяването на отбора. Частта за Доверието бе специално за новоприсъединилите се хора с
дълъг стаж във фирмата - ние в отбора се бяхме отдавна
сдушили. Май така и не го разбраха / възприеха... за разлика от други 1-2ма новодошли
студенти. Веднъж препечен на недоверие, май става неизлечимо.
Methodology, culture and way of
thinking: i wrote this in the beginning of 2007, in the wiki of project HOR, at the
time of expanding of the team. The part about Trust was specialy for the newcomers with
long time in the company - we in the team were "intimate"
long ago. Seems they did not understand / accept it then and now... by contrast to other
1-2 new fresh graduates. Maybe once overdone in distrust, it gets incurable.
Методология
Methodology
Тук с няколко думи ще обясня за какво става въпрос в този проект.
A few words about what this project is about.
Един само-цитат:
софтуер се пише от хора и за хора.
игнорирането на този прост факт води до всички възможни лоши
последствия. На хората трябва да им е приятно да
пишат софтуера (И съответно от другата страна - да ползват софтуера), иначе
не се получава.
Всякаквите технически подробности / архитектури / машини и пр. са
напълно вторичен елемент в писането на софтуер. В никакъв случай не
позволявайте те да надделяват.
Участниците в един отбор трябва да си имаме ДОВЕРИЕ и да
може да се разчита изцяло един на друг. Иначе нищо няма да стане.
citing myself:
software is being written by people and for people.
Ignoring this simple fact leads to all possible bad consequences.
People should feel good when writing the software, otherwise it does
not come out. And respectively, on the other side - when using the
software.
All them technical details - architectures / engines / organisational
processes et al - are completely secondary elements in the writing of
software. By no means allow them to prevail.
We the participants in a team must TRUST each
other and be able to rely entirely on one another. Otherwise nothing will
come out.
Ето някои от използваните основополагащи принципи в писането на софтуер:
Here are some of the basic principles of writing software, used in the project:
- всяко парче си има собственик/ отговорник. Това обикновено е основният
му разработчик (но може и да не е), и Е този който отговаря за него и без
негово съгласие не могат да се правят промени. Това особено важи за
външността, т.е. огъвките-интерфейси.
- each piece has its owner/ person-in-charge. This usualy is its main
developer (but does not have to be), and IS THE one who is responsible
for it and nothing should be changed without hir consent. This is
especialy so for the exteriors, i.e. wrappers-interfaces.
- всяка жаба да си знае гьола, или всеки да играе със собствените си
играчки (принцип на Деметър). Частен случай:
- ясни и твърди интерфейси/протоколи (което не значи
негъвкави), с ясни изисквания, и "собственост".
И никакво бъркане под масата.
- each frog knows it's puddle, or everyone plays with his own toys
(Demeter's principle). Special case:
- clear and firm interfaces/protocols (which does not mean
inflexible), with clear requirements, and "ownership".
And no monkeying under the table at all.
- Разрязване на оптимален брой вертикални слоеве и възможност за
хоризонтални разклонения. (Представете си слой в стена, състоящ се от една
хоризонтална греда от край до край, и наредени отгоре тухли, и отгоре още една греда.
Гредите са общите интерфейси нагоре/надолу, докато тухлите позволяват разрастване в
други посоки / измерения (настрани/напред/назад). Не е задължитено горната греда да е
открай докрай - може да има няколко надстройки една до друга.) Например: слой
потреб.интерфейс, с едно голямо разклонение екран, с подразклонения разните
gui-api-та...; и друго разклонение web-browser-интерфейс, и 3-то - .PDF и други
подобни само-за-четене представяния.
- Splitting into optimal number of vertical layers and possibility for
horizontal branching. (Imagine a layer in a wall, consisting of one horizontal plank
end to end, and bricks on top of it, and another plank on top. The planks are the
common interfaces towards up/down, while the bricks allow growing in other directions
/ dimensions (sideways/ forward / backward). The top plank does not has to be
end-to-end - there could be several overlayed structures next to one another.) Example:
layer user-interface, with one big branch for screen, with subbranches of the
misc.gui-api's; and another branch web-browser-interface, and third one - .PDF and
similar read-only representations.
- 360' градуса проучвателен оглед на всяко изискване / интерфейс /
_посока_. Т.е. отбелязват се всички неща които нещото трябва да прави И всички които
НЕ трябва да прави. Това позволява да се знае кога посоката на движение е грешна - ако
тръгне към нещо което не трябва да се прави. Всъщност тези 360' трябва да се считат не
като кръг, а като спирала; все едно лъч на радар, който обикаля. Това позволява едно и
също място да бъде обходено няколко пъти, в едно или различни поколения на продукта
(алтернативни решения или подобрения)
- 360' degrees exploration view around each requirement / interface /
_direction_. That is, noting down all items which the thing must do, AND all those it must
NOT. This allows to know when moved into wrong direction - if going towards
something that's in the NOT-list. Actualy these 360' should be regarded not as circle,
but as spiral; same as radar's beam going round and round. This allows to walk through
same place several times, in same or in different generations of the product
(alternative solutions or improvements).
- Ето едно полезно представяне на изискванията: представете си
софтуера като един висок кол, вързан със много въжета - всяко от тях
представляващо изискване / клиент / посока на развитие. Различните въжета са
различно дебели/еластични, и различно дълги (и са вързани на различни места - не
задължително в кръг). Задачата е: Колът да не падне, да не се счупи и да е с
минимална дължина. Например ако има много въжета от едната страна и малко от
другата, преместете основата на кола в тази посока (иначе ще има излишно дълъг кол
стоящ много наклонен). Може и да се вкопае, и тогава няма да пада, но пък изобщо
не може да се мести и почти не може да се накланя - ще се счупи. Същата представа
работи и при повдигане / удължаване на софтуера/кола - някои въжета няма да
позволяват, и т.н...
- Here one useful way to picture the requirements: imagine the
software as a tall pole, tied with many ropes - each being a requirement /
customer / direction of growth. The ropes are differently thick/ elastic, and of
different length (and are tied to different places - does not have to be a
circle). The task is: the Pole should not fall down, break, and be of minimal
length. For example if there are too many ropes on one side and much less on
other, shidt the base towards the many - or there'll be a too long and too tilted
pole. It can be dug into ground, it thus it won't fall, but then it cannot be
moved at all not tilted - and it would break. The same notion works with raising /
lengthening the pole / software - some ropes won't allow, etc...
- езици, езици и пак езици - Езиците за програмиране _са_ инструментите на
програмиста. Всъщност всеки интерфейс представлява един малък език - но това е
пасивното възприятие. Активният начин е да се ползва навсякъде подходящият език,
съответно да се _прави_ език на всяко място където има нужда / се вижда полза от това
- напр. ако смисълът на приложната област е достатъчно отделим / отнесен. Никак обаче
не е задължително този език да има нов синтаксис - ползвайте синтаксиса на базовия
език (в случая питон) като носител, но вложете собствен смисъл във всеки ваш
"оператор". Никъде не се изисква даден продукт да е написан _само_ на един език - това
е невъзможно.
- languages, languages and more languages - Programming languages _are_
the tools of the programmer. In fact each and every interface is a small language -
but this is the passive perception. The active one is to use for each place a language
that suits it best, respectively to _make_ a language where one is needed / an
advantage is seen - e.g. if the meaning of the application field is well separatable /
abstract. But it is not at all mandatory to have different syntax for each language -
use the syntax of base language (python in our case) as carrier, but put your own
meaning / semantics in each "operator". There's never a requirement that a product has
to be written in _same_ language all over - it is impossible to do so.
- Тук за основен език се ползва Питон - интерпретиран език,
позволяващ максимална гъвкавост и мощ при минимални усилия. Лесно разширяем надолу
(огъвки за С библиотеки и пр), и лесно разширяем нагоре (всичко е обекти,
включително функциите и класовете - и метакласовете). Т.е. можете да вложите в
даден синтактичен/граматичен израз какъвто си искате смисъл - стига да си го
напишете (т.е. да си подложите меко). В началния прототип има измислени около 6-7
езика за описание на различните елементи - почти всички базирани на питон (като
декларативен синтаксис) - но със собствен смисъл.
- The main language here is Python - interpreted language,
allowing maximal flexibility and power with minimum effort. It is easy extendable
downwards (wrappers for C libraries etc), and easy extendable upwards (everything
is objects, including functions and classes - and the metaclasses too). That is u
can put whatever meaning in some syntactical/grammatical expression - as long as u
write it yourself ("cushion" yourself softly). Even in the initial prototype there
are 6-7 languages describing various elements - near all based on python itself
(as declarative syntax) - but with their own meanings.
- ЧОВЕШКАТА страна на програмирането е ИЗКЛЮЧИТЕЛНО ВАЖНА. Дори всичките
рационални и логични правила на света да се спазват, ако това се прави механично, нищо
няма да се получи. В края на краищата, софтуерът е _само_ едно доста ограничено
отражение на действителността, начин за (орязано) запомняне и изпълнение на човешки
знания (в някакъв предварително заложен контекст). Ако едно знание е просто записано в
книга, трябва някой човек да го интерпретира и да го изпълни; софтуерът+машината
заместват частично този някой. Разликата е, че човекът може сам да промени полученото
знание (и да го приложи в преди невъзможна област / контекст - или да просто да обърка
всичко). Машината не може да обърка, но и не може да се оправя в нов
не-заложен/предвиден в нея контекст. Така че всъщност употребата на софтуер е един
изключително изкривено-опосредстван начин за виртуален разговор с програмиста И
спецификатора. Затова има значение дали той е щастлив/ кисел/ проклет/ мързелив/
безразличен - въобще какъв е всъщност.
- The HUMAN side of programming is EXTREMELY IMPORTANT. Even if all them
rational and logical rules of the world are respected, if it is done mechanicaly,
nothing useful is gonna come out. All in all, the software is _just_ a very limited
reflection of reality, a way of (clipped) storing and executing of human knowledges
(in whatever context, set upfront). If some knowledge is simply stored in a book, a
human is needed to interpret and execute it; the software+machine can partialy
substitute that person. The difference is that the human can change the received
knowledge (or apply it into before impossible area / context - or just mess it up).
The machine cannot mess it, but it can't manage a new context either, in one that is
not set/ predicted in it. Thus the usage of software is actually an extremely
crooked-and-intermediated way of a virtual conversation with the programmer AND the
specifier. Therefore, it is important if they are happy/ sour/ bad-tempered/ lazy/
indifferent - what are they actually.
-
дебелите томове са за начинаещите.. опитните си измислят
сами правилата, които най-пасват на тях самите и на ситуацията.
Но Най-опасни са тези които не искат да знаят че не знаят.
-
the thick volumes are for beginners... the experienced make their own
rules, which best match themselves and the situation.
But most dangerous are those who do not want to know that they do not know.
Теория и пособия
Theory and books
-
Ето една готова методология (процес), която съм намерил и предлагам,
като нещо готово, събрано накуп и консистентно - и изпробвано.
- CrystalClear - Методология за малки отбори (до 8) при максимална ефективност и "удоволствие"
A methodology (process) i have found and suggest, as something ready
to use, all-in-one and consistent - and well-tried out:
- CrystalClear - Methodology for small teams (up to 8) in maximal efficiency and "pleasure"
- amazon.com
-
Основен ресурс (учебник, ако щете) на тема (човешка) методология/организация
за писане на софтуер, е тази книга:
The main resource (call it textbook) about the (human) methodology and
organisation for making software, is this one:
- "Organizational Patterns of Agile Software Development" -
amazon.com
-
виж списъка с препоръчваните четива
see the list of recomended readings