ITRampage

“Programs must be written for people to read, and only incidentally for machines to execute.” 

Harold Abelson, Structure and Interpretation of Computer Programs

Я дуже часто зустрічаю цю мантру. Код має бути написаний для людей… Це не так! Код пишеться для того, аби його виконувала машина. Без машини немає жодного сенсу в існуванні коду. Код тим краще, чим ефективніше (дешевше, враховуючи вартість часу на виконання) він використовує машину для виконання завдання, для якого був призначений.

Якщо є дві версії коду. Одна з яких виконує завдання за 1мсек та утилізує потужності на $0.01, а інша виконує завдання за 5мсек та утилізує потужності на $0.1, то очевидно, що перша версія значно краще. Якщо я буду продавати рішення, то зрозуміло, що клієнт віддасть перевагу першому, оскільки воно дешевше та дозволяє вирішувати проблеми краще. Легкість читання коду розробниками – це не те, що кінцевий користувач бажає придбати. Коли ми говоримо, що головне – це те, як легко код читається людьми, то ставимо розробників головними stakeholder’ами, наче саме задоволення естетичних вподобань розробників приносить компанії гроші.

Код не має бути легким для читання, натомість, він має бути:

• Ефективним з точки зору вирішення проблеми для якої призначений
• Ефективним з точки зору внесення змін

Нас цікавить не легкість читання чи якась уявна простота, а саме легкість внесення змін, можливість продукту адаптуватися до нових умов та викликів. Але що саме мається на увазі під легкістю змін?

Зазвичай, коли розробники говорять про здатність до змін, то вони слабо розуміють про що вони говорять. Зміни – це щось, що має відношення до стану, а відтак і до сутностей. Коли ми говоримо про зміни у коді, то код постає сутністю, тобто чимось, що змінюючись лишається самим собою. 

Концепція сутності – це продукт гештальту сприйняття, який не має жодного сенсу, якщо мова йде про код. Про що насправді треба говорити, то це не про здатність до змін (типу адаптивності живих організмів), а про можливість легко щось демонтувати й замінити на нове (типу ремонта автомобіля).

Про те, чи легко автомобіль ремонтується чи тюнінгується ми можемо судити із того, як легко він розбирається та знову збирається. Якщо необхідно демонтувати додатково п’ять інших деталей, аби дістатися до тієї деталі, яка підлягає заміні, то такий автомобіль гірше з точки зору внесення змін, аніж той, де відповідну деталь можна замінити без того, аби чіпати інші. До коду необхідно ставитися в значній мірі механістично, хоча він і може здаватися чимось пневматичним, ефемерним, чистим породженням свідомості без матеріального тіла. Не дарма код помилково називають логікою. 

Нам не треба легко читати код. Нам треба мати можливість легко його позбутися / замінити на новий. Я вже описав майже ідеальну організацію коду. “Майже”, тому що ідеальна організація коду – це коли немає ніякої організації, але при цьому покладені на організацію функції виконуються і мета досягається.

Доречі, розглядаючи ідеальне – ідеально читається той код, який не треба читати, але який залишається зрозумілим! Як таке можливо?! Дуже просто! Мова йде про приховування складності за інтерфейсом. Бажано за дуже простим інтерфейсом. Якщо Ви полюбляєте правила типу SOLID, то ось Вам одне:

Якщо стоїть питання між “простий інтерфейс і складна реалізація” та “складний інтерфейс і проста реалізація”, то обирати у більшості випадків  слід перше, оскільки, зазвичай, користувачі витрачають на роботу із кодом більше часу, аніж його розробники на його створення. Просто прикиньте скільки часу було витрачено на розробку, наприклад, Ruby on Rails  та скільки часу було витрачено на розробку проєктів на Ruby on Rails.

File.open do |f|
…
end

… простіше та безпечніше за:

f = File.open “/dev/null/”
…
f.close