Ползата и вредата от 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 Comments

  • Anonymous says:

    Хе-хе, тук има един материал по тая тема, който заема малко по-твърда и недвусмислена позиция по въпроса, и дава някои конкретни примери.

  • Mike Ramm says:

    Вярно е, че аторът е доста по-твърд в позицията си, но това също е една много хубава статия.

    Благодаря за линка!

  • Владо Алексиев says:

    Има връзка с един много основен принцип на 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 които са със съмнителна стойност.

  • Mike Ramm says:

    В крайна сметка, на-важното е да намериш мярката, което е изкуството на професията.

    Благодаря ти, Владо, за коментара!

  • Алексашо says:

    ЧРД на патерица! Many happy returns, както думат братята ингилизи. Аз те забравих улисан в работа (след 2 седмици отпуска ми трябва 1 ден само за четене на пощата), но зло да те забрави !

    Бих добавил към вече казаното и един друг agile принцип, който се вписва в този ред на мисли : KISS (keep it simple stupid).

    BTW много добър блог ! Имаш моето искрено възхищение и приятелска завист. Продължавай в същия дух !

  • Mike Ramm says:

    Welcome on board, Сашо!

    Много се радвам, че се включваш в дискусията с ценен съвет!

    Надявам се, че ще намираш време да хвърляш по един поглед насам и да участваш в обсъждането на различните въпроси.

    Благодаря за пожеланията! Надявам се, че и ти ще се присъединиш към блогърското братство – твоето перо е несравнимо по-добро от моето 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *