| смена парадигм, блядь! |
[Jun. 15th, 2015|12:55 pm] |
обнаружил вдруг, что некоторое время назад (это не недели и даже не месяцы, если чо) полностью сменил способ написания софта. раньше я долго думал, продумывал API чуть ли не до уровня ваще кода, всё это как‐то увязывал, а потом делал либы и софт.
в итоге получалось, что в API я всё равно накосячил, потому что это таки забыл, то не учёл. в либах тоже кое‐что сделал не так. да вдобавок пока писал — требования немного изменились, и пришлось адаптировать то, что есть, к новым.
при этом я очень не любил выкидывать уже написаный код. потому что как же так — я же, блядь, ДУМАЛ, и тут вдруг выкинуть. я что, зря думал, или неправильно? нет, не будем выкидывать! даже если он не нужен или бесполезен: а вдруг пригодится потом?
ещё один минус был в том, что увидеть нечто более‐менее работающее можно было далеко не сразу. сначала ты сидишь и уныло пишешь кучу кода, который нельзя запустить и посмотреть на результат. ну, то есть, можно, но результат на то, что хочется получить, не очень похож.
сейчас я перешёл к новому принципу. вкратце это называется «take your reusability to the bank and fuck it!»
во‐первых, нахуй универсальные крутые библиотеки. они всегда чересчур сложны и запутаны.
во‐вторых, в новом проекте будут новые требования, и нет ничего страшного в переписывании библиотеки под него. натурально, какие‐то части кода можно спокойно взять из старой (зачастую вполне большие части, иногда чуть ли не полностью), но нет ничего ненормального в том, чтобы поменять API, например, или порядок действий.
в третьих, не боимся развалить то, что только что построили. пишем гуйтулкит? отлично, начинаем с того, чтобы как можно быстрее нарисовать на экране окошко с текстом «ты хуй!» нарисовали? отлично, выкидываем ненужный код, добавляем нужный — теперь окошко у нас класс, а не просто иксовый хэндл. сделали? ура, вынимаем из класса иксовый хэндл, уносим в другой модуль, учим класс работать с таким вариантом. и так далее.
да, на каждой итерации мы делаем больше кода, чем делали бы, если бы всё продумали сразу и стали писать как полагается, «снизу». то есть, «по уму» делаем сначала кэши цветов, кэши шрифтов, всю вот эту механику… всё, я уже хочу нахуй бросить заниматься ерундой. потому что куча кода написана, а окошко всё ещё никак не нарисовать. потому пишем «сверху» — от окошка к кэшам, постепенно добавляя фичи и перерабатывая код. так интересней.
ключевое — перерабатывать код небольшими кусочками. чтобы почти всегда можно было запустить и посмотреть на окошко. и да, если перерабатывать заебало — можно отвлечься на создание новой фичи. например, вывода в окошко картинок. конечно, 90% кода вывода картинок будет потом рипнуто — ну и что? сохранение интереса не менее важно, чем «чистота кода». может, даже, более важно.
естественно, это не «пишу не приходя в создание, потом посмотрю, что получится». я изначально имею в черепе план того, что и как я хочу увидеть в итоге. наподобие «каскадные стили, отсутствие дохуя умной автоматизации, примерно вот такой синтаксис для создания, etc.» и последовательно иду к этому. но именно последовательно, и имея на каждом этапе что‐то, с чем можно поиграть, или просто посмотреть и подумать: «таки вот, окошко, работает! круто! едем дальше.»
предостерегаю, что если изначально плана желаемых фич и того, как оно должно выглядеть в итоге, нет — то в результате применения метода получится вполне ожидаемый неюзабельный говнокод. поэтому лучше всего метод подходит для товарищей с опытом, которые более‐менее представляют не только то, что они в итоге хотят, но и то, как это должно выглядеть внутри (и пусть первые варианты на это совсем не похожи; неважно). если же опыта нет… метод тоже работает, просто переписывать придётся сильно больше. |
|
|