программерское
amarao_san — 05.10.2015 А вот одна из причин, почему я ощущаю себя плохопрограммистом - это способность хорошо формулировать мысли на среднем уровне. Если 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 писать?
|
</> |