October 5th, 2015

404

программерское

А вот одна из причин, почему я ощущаю себя плохопрограммистом - это способность хорошо формулировать мысли на среднем уровне. Если grand design ещё как-то можно (хотя редко могу оценить что получится), и если на локальном уровне (в пределах функции) моей выразительности хватает, но на тактическом уровне (в пределах пары-тройки классов и их взаимоотношений) я плыву страшно.

То есть какой-то тривиальный конструктор из "class Device" с методами сбора информации и разных операций я делал с пятой попытки, изобретая какие-то адские речекряки с глобалами, в которые лазали три разных класса и "всё равно" получалась путаница.

Я не знаю как это у "настоящих программистов" происходит, но в программировании я ощущаю ровно три проблемы:

1) Ошибки дизайна среднего уровня (которые приводят к постоянному недоперерефакторингу, сильно замедляющему всё и вся).
2) Чрезмерные обобщения и универсализация того, что универсализировать не надо (условно, у того же class Device метод update_info зачем-то принимает параметром "устройство" помимо self, да ещё и делает с десяток проверок, чтобы понять, что этот 'device' это то, для чего можно выполнять проверки - хотя чуть раньше почти они же делались в __init__/
3) Острую нехватку знаний о том, "как делать правильно".

Вот написал я класс Device, который данное блочное устройство с разных мест облизывает. И точку монтирования для него находит, и номер в энкложе, и букву диска, и статусы, и смарты, и uuid файловой системы, и даже делает всякое полезное типа монтировать/отмонтировать.

А теперь как бы мне для него юнит-тесты-то написать?

__init__ дёргает кучу внутренних функций, которые лезут в реальные блочные устройства (по абсолютному пути) и что-то там выискивают.

И как я его тестировать должен?

Допустим (упрощая задачу):

class Device:
    def __init__(self, device):
        with file('/sys/block/%s/device/status' % device, r) as f:
            self.status = f.read().strip()
        self.device = device

И как мне для такого unit-test писать?