Ползата и вредата от soft-coding
При по-младите и неопитни програмисти hard-coding е често срещано явление. Той се проявява не само като твърдо зададена логика в кода на програмата, а също така и като конкретни стойности на променливи или константи, от които зависи поведението на продукта. Разбира се, дори и по-опитни разработчици не за имунизирани срещу това, особено в началото на един проект, когато се пише “само за проба”, а после “пробния код” някак си остава и в продукционната система.
Колкото повече hard-coding има в една програма, толкова по-трудно е да се поддържа този код и всяка една промяна в изискванията води до сериозно преписване на кода и прекомпилиране. Това е известен проблем в областта на програмирането, но не това е темата на настоящия пост, а точно обратното.
Обратното на hard-coding се нарича “soft-coding”, което ще рече, че програмистите предоставят на потребителите (обикновено на административно ниво) средства, с които да конфигурират системата, без да се налага да се променя самата тя. Такива механизми могат да бъдат специален потребителски интерфейс или конфигурационни файлове или бази от данни. В зависимост от нивото на техническа компетентност на потребителя, те могат да бъдат повече или по-малко сложни. Затова, например, в продукт като Microsoft Word има диалогови прозорци, а open-source сървърните продукти се настройват с конфигурациони файлове.
Добро или лошо нещо е soft-coding? Това е въпросът, който Кришна Кумар анализира в своя пост Hard-coding and Soft-coding и заключава: “Soft-coding е по принцип хубаво нещо”, стига да не се прекалява с него. Soft-coding дава възможност на крайния потребител да адаптира продукта към собствените си нужди; софтуерната компания пък печели от това, че няма да поддържа специална версия за всеки клиент или да променя функционалността непрекъснато според потребителските изисквания.
Всичко това е чудесно, само че крайния потребител никак не обича да се занимава с настройки и, според наблюденията на Кришна, повечето потребители си използват настройките, заложени по подразбиране. Нещо повече, колкото механизмът за персонални настройки е по-богат и по-сложен, толкова по-малко се използва. Ироничното, казва той, е в това, че колкото е по-добър продуктът, който произвеждате, толкова по-малко нужда от настройки има той. Ако повечето потребители могат да си свършат работата използвайки базовия интерфейс, те много по-малко ще се интересуват от това да си го настройват персонално. В този смисъл, излиза, че колкото по-добре познавате работата и навиците на своите клиенти, толкова по-малка нужда от soft-coding има вашето приложение, защото сте по-уверени, че сте предложили точно това, от което те се нуждаят.
Кришна се впуска в по-дълбоки разсъждения и, ако ви интересува, можете да прочетете целия пост тук. Това е интересна тема за размисъл, според мене. И както винаги, опираме до това нещата да се правят с мярка, а къде точно е границата между добрия и лошия подход, е въпрос на много опит и може би на малко интуиция.
Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се напълно безплатно за нашия бюлетин чрез RSS feed или по имейл
Коментари
6 коментара to “Ползата и вредата от soft-coding”
Споделете вашето мнение
Анкета
Loading ...
-
-
Безплатен абонамент
-
Препоръчвам ви
-
Авторски права
-
Admin
Хе-хе, тук има един материал по тая тема, който заема малко по-твърда и недвусмислена позиция по въпроса, и дава някои конкретни примери.
Вярно е, че аторът е доста по-твърд в позицията си, но това също е една много хубава статия.
Благодаря за линка!
Има връзка с един много основен принцип на agile development: YAGNI (you aren’t gonna need it). Тоест да не се прекалява с неща, които не допринасят директно Busniess value. Нещата може да са features, architectural frameworks, working procedures и пр.
Подобен прицип е TAGRI (they aren’t gonna read it), т.е. да не се прекалява с project documents които са със съмнителна стойност.
В крайна сметка, на-важното е да намериш мярката, което е изкуството на професията.
Благодаря ти, Владо, за коментара!
ЧРД на патерица! Many happy returns, както думат братята ингилизи. Аз те забравих улисан в работа (след 2 седмици отпуска ми трябва 1 ден само за четене на пощата), но зло да те забрави !
Бих добавил към вече казаното и един друг agile принцип, който се вписва в този ред на мисли : KISS (keep it simple stupid).
BTW много добър блог ! Имаш моето искрено възхищение и приятелска завист. Продължавай в същия дух !
Welcome on board, Сашо!
Много се радвам, че се включваш в дискусията с ценен съвет!
Надявам се, че ще намираш време да хвърляш по един поглед насам и да участваш в обсъждането на различните въпроси.
Благодаря за пожеланията! Надявам се, че и ти ще се присъединиш към блогърското братство - твоето перо е несравнимо по-добро от моето