Старый текст который я давно хотел опубликовать.
Если бы кто-то рассказал мне это 10 лет назад, я бы сэкономил столько нервов и времени, что просто сложно вообразить.
Я уже больше десяти лет работаю в области разработки программного обеспечения и всё это время, когда мне поступала задача на доработку какой-либо системы я, как и любой разработчик, думал. Что сделать? Быстро написать костыль или сделать всё как положено - обследование, схема процесса, техническое задание, проектировка и т.д.
Для тех, кто в танке и ничего не понимает в программировании, поясню.
Любая программа состоит из программного кода на языке программирования. Чтобы в программе что-то стало работать по-другому или добавилось, нужно модифицировать программный код. Можно его модифицировать по технологии, а можно сделать костыль. Представьте, что у вас стол качается. Можно исправить это по технологии - описать какой высоты должен быть стол, какой угол качания допустим и т.д. Потом сделать чертеж стола, определить технологию устранения неисправности: подпилить ножки, сделать какие-нибудь набойки или подкрутить если конструкция позволяет. А можно сделать костыль - просто подсунуть под ножку сложенную бумажку. Для того, кто работает за столом результат одинаков, но второй вариант в разы быстрее и дешевле.
Что самое страшное, каждый раз, когда я был вынужден говнокодить, я чувствовал себя каким-то обманщиком, который вместо качественной работы "впаривает фуфло".
Но теперь я уже знаю все секреты и с удовольствием с вами ими поделюсь.
Если вы работаете в крупной компании, где всё по технологии или в компании по разработке софта, то тут всё понятно, делаете по регламенту и вопросов нет.
Но!
Большинство людей работают в маленьких или средних компаниях, где Софт либо для внутреннего использования, либо для внешнего клиента на поддержке (т.е. он уже написан и продан). В таких компания у меня регулярно вставал вопрос - "Как выполнять задачу?"
Теперь я точно могу ответить - однозначно КОСТЫЛИРОВАТЬ! Никаких проектировок и ТЗ. Боже упаси!
Ключевое слово в этой ситуации - "Быстро!". Если пытаться сделать всё по фень-шую, то вы рискуете оказаться в ситуации, когда к моменту, когда будет закончена проектировка и ТЗ, приоритеты поменяются и срочной станет другая задача, с которой произойдет тоже самое, и в конце концов у вас будет много спроектированных задач и ни одной сделанной. А у того, кто говнокодил будут уже корявые, убогие, но работающие и применяемые фичи.
Поначалу я боялся так делать, потому что думал "Я вот сейчас напишу всё криво, а потом всё равно придется переделывать. Лучше я сразу сделаю по нормальному."
Запомните раз и на всегда. Переделывать придется в любом случае и не один раз, т.к. новые задачи будут затрагивать тот же функционал или вообще противоречить ему. А на то чтобы переписать всё по нормальному у вас всё равно никогда не будет хватать ни времени, ни сил.
То, что код некрасивый, не оптимальный или работает медленно, абсолютно "не колышет" того, кому срочно нужна кнопка или отчет, или ещё что-то, что ускорит его работу в разы и сократит мучения и ручной труд. Конечно не стоит творить абсолютный "треш", но мне лично приходилось применять даже такой "харам" как запросы в цикле и сравнение с константами прямо в коде и модальные окна во время транзакции. И всякий раз, пользователей волновало только то, чтобы это работало как им надо и было сделано быстро. А в плане дальнейших доработок, уже имеющиеся в коде костыли скорее упрощали работу, чем накладывали какие-либо ограничения. Переписывать что-то глобально из-за полной нечитаемости и непонятности конструкций приходилось крайне редко.
Поэтому, послушайте опытного Костылье. Делайте максимально быстро и просто. Подсуньте бумажку если стол качается.
Если бы кто-то рассказал мне это 10 лет назад, я бы сэкономил столько нервов и времени, что просто сложно вообразить.
Я уже больше десяти лет работаю в области разработки программного обеспечения и всё это время, когда мне поступала задача на доработку какой-либо системы я, как и любой разработчик, думал. Что сделать? Быстро написать костыль или сделать всё как положено - обследование, схема процесса, техническое задание, проектировка и т.д.
Для тех, кто в танке и ничего не понимает в программировании, поясню.
Любая программа состоит из программного кода на языке программирования. Чтобы в программе что-то стало работать по-другому или добавилось, нужно модифицировать программный код. Можно его модифицировать по технологии, а можно сделать костыль. Представьте, что у вас стол качается. Можно исправить это по технологии - описать какой высоты должен быть стол, какой угол качания допустим и т.д. Потом сделать чертеж стола, определить технологию устранения неисправности: подпилить ножки, сделать какие-нибудь набойки или подкрутить если конструкция позволяет. А можно сделать костыль - просто подсунуть под ножку сложенную бумажку. Для того, кто работает за столом результат одинаков, но второй вариант в разы быстрее и дешевле.
Что самое страшное, каждый раз, когда я был вынужден говнокодить, я чувствовал себя каким-то обманщиком, который вместо качественной работы "впаривает фуфло".
Но теперь я уже знаю все секреты и с удовольствием с вами ими поделюсь.
Если вы работаете в крупной компании, где всё по технологии или в компании по разработке софта, то тут всё понятно, делаете по регламенту и вопросов нет.
Но!
Большинство людей работают в маленьких или средних компаниях, где Софт либо для внутреннего использования, либо для внешнего клиента на поддержке (т.е. он уже написан и продан). В таких компания у меня регулярно вставал вопрос - "Как выполнять задачу?"
Теперь я точно могу ответить - однозначно КОСТЫЛИРОВАТЬ! Никаких проектировок и ТЗ. Боже упаси!
Ключевое слово в этой ситуации - "Быстро!". Если пытаться сделать всё по фень-шую, то вы рискуете оказаться в ситуации, когда к моменту, когда будет закончена проектировка и ТЗ, приоритеты поменяются и срочной станет другая задача, с которой произойдет тоже самое, и в конце концов у вас будет много спроектированных задач и ни одной сделанной. А у того, кто говнокодил будут уже корявые, убогие, но работающие и применяемые фичи.
Поначалу я боялся так делать, потому что думал "Я вот сейчас напишу всё криво, а потом всё равно придется переделывать. Лучше я сразу сделаю по нормальному."
Запомните раз и на всегда. Переделывать придется в любом случае и не один раз, т.к. новые задачи будут затрагивать тот же функционал или вообще противоречить ему. А на то чтобы переписать всё по нормальному у вас всё равно никогда не будет хватать ни времени, ни сил.
То, что код некрасивый, не оптимальный или работает медленно, абсолютно "не колышет" того, кому срочно нужна кнопка или отчет, или ещё что-то, что ускорит его работу в разы и сократит мучения и ручной труд. Конечно не стоит творить абсолютный "треш", но мне лично приходилось применять даже такой "харам" как запросы в цикле и сравнение с константами прямо в коде и модальные окна во время транзакции. И всякий раз, пользователей волновало только то, чтобы это работало как им надо и было сделано быстро. А в плане дальнейших доработок, уже имеющиеся в коде костыли скорее упрощали работу, чем накладывали какие-либо ограничения. Переписывать что-то глобально из-за полной нечитаемости и непонятности конструкций приходилось крайне редко.
Поэтому, послушайте опытного Костылье. Делайте максимально быстро и просто. Подсуньте бумажку если стол качается.
The old text that I have long wanted to publish.
If someone told me this 10 years ago, I would have saved so much nerves and time that it’s hard to imagine.
I have been working in the field of software development for more than ten years, and all this time, when I received the task of finalizing a system, I, like any developer, thought. What to do? Quickly write a crutch or do everything as expected - examination, process diagram, terms of reference, design, etc.
For those who are in the tank and do not understand anything in programming, I will explain.
Any program consists of program code in a programming language. In order for something to work in the program differently or to be added, you need to modify the program code. You can modify it by technology, or you can make a crutch. Imagine that your table is swinging. You can fix this by technology - describe what height the table should be, what swing angle is acceptable, etc. Then make a drawing of the table, determine the technology for troubleshooting: file legs, make some heels or tighten if the design allows. And you can make a crutch - just slip a folded piece of paper under the leg. For someone who works at the table, the result is the same, but the second option is many times faster and cheaper.
What is most terrible, every time I was forced to shit, I felt like some kind of deceiver who, instead of high-quality work, "fucked up".
But now I already know all the secrets and will share them with pleasure.
If you work in a large company, where everything is technology-based or in a software development company, then everything is clear, you are doing according to the regulations and there are no questions.
But!
Most people work in small or medium-sized companies, where the software is either for internal use or for an external client for support (i.e. it is already written and sold). In such a company, I regularly got the question - "How to perform the task?"
Now I can definitely answer - definitely COLLECT! No design and technical specifications. God forbid!
The key word in this situation is "Fast!". If you try to do everything at Feng Shui, then you run the risk of a situation where by the time design and TK are completed, the priorities change and another task becomes urgent, with which the same thing happens, and in the end you will have a lot of designed tasks and not one done. And the one who the govnokodil will already have clumsy, miserable, but working and used features.
At first, I was afraid to do so, because I thought, “I’ll write everything crookedly now, and then I’ll have to redo it anyway. I’d better do it right away right away.
Remember once and for all. In any case, you will have to redo it more than once, because new tasks will affect the same functionality or even contradict it. And in order to rewrite everything in the normal way, you still will never have enough time or energy.
The fact that the code is ugly, not optimal or runs slowly absolutely doesn’t “shake” someone who urgently needs a button or report, or something else that will speed up its work at times and reduce torment and manual labor. Of course, you should not create an absolute “trash”, but I personally had to apply even such “harames” as queries in a loop and comparison with constants directly in the code and modal windows during a transaction. And every time, users were only concerned that it worked as they needed and was done quickly. And in terms of further improvements, the crutches already in the code rather simplified the work than imposed any restrictions. It was extremely rare to rewrite something globally because of the complete illegibility of the constructions.
Therefore, listen to the experienced Crutch. Do it as quickly and simply as possible. Slip a piece of paper if the table is swinging.
If someone told me this 10 years ago, I would have saved so much nerves and time that it’s hard to imagine.
I have been working in the field of software development for more than ten years, and all this time, when I received the task of finalizing a system, I, like any developer, thought. What to do? Quickly write a crutch or do everything as expected - examination, process diagram, terms of reference, design, etc.
For those who are in the tank and do not understand anything in programming, I will explain.
Any program consists of program code in a programming language. In order for something to work in the program differently or to be added, you need to modify the program code. You can modify it by technology, or you can make a crutch. Imagine that your table is swinging. You can fix this by technology - describe what height the table should be, what swing angle is acceptable, etc. Then make a drawing of the table, determine the technology for troubleshooting: file legs, make some heels or tighten if the design allows. And you can make a crutch - just slip a folded piece of paper under the leg. For someone who works at the table, the result is the same, but the second option is many times faster and cheaper.
What is most terrible, every time I was forced to shit, I felt like some kind of deceiver who, instead of high-quality work, "fucked up".
But now I already know all the secrets and will share them with pleasure.
If you work in a large company, where everything is technology-based or in a software development company, then everything is clear, you are doing according to the regulations and there are no questions.
But!
Most people work in small or medium-sized companies, where the software is either for internal use or for an external client for support (i.e. it is already written and sold). In such a company, I regularly got the question - "How to perform the task?"
Now I can definitely answer - definitely COLLECT! No design and technical specifications. God forbid!
The key word in this situation is "Fast!". If you try to do everything at Feng Shui, then you run the risk of a situation where by the time design and TK are completed, the priorities change and another task becomes urgent, with which the same thing happens, and in the end you will have a lot of designed tasks and not one done. And the one who the govnokodil will already have clumsy, miserable, but working and used features.
At first, I was afraid to do so, because I thought, “I’ll write everything crookedly now, and then I’ll have to redo it anyway. I’d better do it right away right away.
Remember once and for all. In any case, you will have to redo it more than once, because new tasks will affect the same functionality or even contradict it. And in order to rewrite everything in the normal way, you still will never have enough time or energy.
The fact that the code is ugly, not optimal or runs slowly absolutely doesn’t “shake” someone who urgently needs a button or report, or something else that will speed up its work at times and reduce torment and manual labor. Of course, you should not create an absolute “trash”, but I personally had to apply even such “harames” as queries in a loop and comparison with constants directly in the code and modal windows during a transaction. And every time, users were only concerned that it worked as they needed and was done quickly. And in terms of further improvements, the crutches already in the code rather simplified the work than imposed any restrictions. It was extremely rare to rewrite something globally because of the complete illegibility of the constructions.
Therefore, listen to the experienced Crutch. Do it as quickly and simply as possible. Slip a piece of paper if the table is swinging.
У записи 4 лайков,
0 репостов,
122 просмотров.
0 репостов,
122 просмотров.
Эту запись оставил(а) на своей стене Филипп Кашкет
