?

Log in

No account? Create an account
 
 
25 July 2017 @ 11:28 am
Software development - constantly balancing problems against each other  
Short names vs unique names
It is a good practice to use shorter method names, because long names are harder to read.
It is cleaner to call:
candidate.Save();
than:
candidate.SaveCandidate();

But then we end up with multiple "Save()" methods in different classes. For example:
Candidate.cs/Save()
Recruiter.cs/Save()

Problem with non-unique names
If we search our codebase for "Save(" - we would find a lot of methods and method calls. Only some of them would relate to the functionality we actually want to research (for example, we may want to research where "Candidate Save()" functionality is used because we consider refactoring or deleting it).

Plain text search vs code references
Visual Studio allows to find all references to a specific method by right-mouse-clicking on a method name and selecting "Find All References".
So, non-unique method names problem is solved, right?
Not quite.
Visual Studio is not able to track method calls that are made from aspx and ashx files.
Visual Studio is also not able to find method references in the comments.

ReSharper vs vanilla Visual Studio
ReSharper actually is able to find method references in aspx, ashx and even in comments. Until Visual Studio 2015 that worked fine. But since ReSharper team and codebase aged, and Visual Studio switched to new Roslyn compiler, ReSharper team was not able to keep up and delivered only barely working resource hog, that is practically not usable with newer version of Visual Studio (too slow).

Get rid of aspx and ashx files?
It is actually pretty easy to avoid using ashx handlers and use standard C# classes to implement HttpHandler interface.
But what about aspx pages: can we get rid of them too and use only standard C# HttpHandlers?
If we could do that, then we would be able to rely on "Find All References" feature again.
But, unfortunately, getting rid of aspx pages is not that simple. We would have to reimplement a lot of functionality that aspx has.
For example:
- Page PostBack support would be gone.
- Ability to nicely combine HTML code and aspx controls alongside each other would be gone.
- HTML syntax validation would be gone (no HTML syntax validation for C# strings in Visual Studio).

If it ain't broke - don't fix it
Even though it is pretty straightforward operation to convert existing ashx files into standard C# classes (where Visual Studio is able to track all method references) - such conversion is not without its own problems.
- Conversion takes developer's time.
- Code replacement could introduce silly bugs.
- Moving code from class to class makes navigating "svn blame" - a little bit trickier.
So if an ashx handler was working in the solution for many years already - does it make sense to touch it now?

The benefits of code refactoring
In spite of "If it ain't broke - don't fix it" rule - cleaning up code is still needed. If we do not keep code clean (do not delete unneeded parts and do not clear confusing things such as hidden references) - then our codebase would be extremely hard to maintain. Fixing a bug would introduce other bugs. Features would be very hard to add without adding bugs.

It depends
There is no single solution that can be applied to all situations. In software development we consider multiple problems and constantly weigh pros and cons against each other.
For example, out of 11 remaining ashx files, we:
- Deleted one file because we do not use it ("Reduce amount of code when possible" principle).
- Would migrate one file to the standard C# HttpHandler, because today during refactoring a developer missed a method call from that ashx file.
- Keep other 9 ashx files as is ("If it ain't broke - don't fix it" principle).

What are your examples of balancing problems against each other?

Originally posted at: http://dennisgorelik.dreamwidth.org/136913.html
 
 
 
veremeenko_alex on July 26th, 2017 03:59 pm (UTC)
move to asp net mvc (can work together with aspx/ascx/ashx - good for migration)
use Resharper with ssd
Dennis Gorelikdennisgorelik on July 26th, 2017 06:44 pm (UTC)
> move to asp net mvc

Unfortunately, asp.net mvc is not a robust product.
It has a weird and annoying bug:
https://stackoverflow.com/questions/23707108/why-does-adding-system-web-webpages-dll-cause-illegal-characters-in-path-cras

> use Resharper with ssd

We tried ReSharper on SSD machines. It is still slow.
veremeenko_alex on July 27th, 2017 08:06 am (UTC)
А зачем вам ковычки в урле?
veremeenko_alex on July 27th, 2017 08:12 am (UTC)
Использовать поиск с значением как часть урл?

Почему не
http://qa.postjobfree.com/autocompleteskills.apsx?search="myskill
Dennis Gorelikdennisgorelik on July 27th, 2017 02:11 pm (UTC)
It would work, but the URL is less user-friendly.
It is probably not very important in this case, because that call is made by javascript anyway (passing user's input).

But my main point is that classic ASP.NET Web Forms allow using http://qa.postjobfree.com/autocompleteskills/%22myskill
but ASP.NET MVC - does NOT allow that -- for no good reason.

So I evaluate ASP.NET MVC as a not robust product that probably has many other problems, and does not deserve my attention.

Does it make sense?
veremeenko_alex on July 27th, 2017 02:21 pm (UTC)
>It would work, but the URL is less user-friendly.
>It is probably not very important in this case, because that call is made by javascript anyway (passing user's input).

Там возвращается даже не json а кусок javascript. Странно.

>but ASP.NET MVC - does NOT allow that -- for no good reason.

Правильно что валится, в ASP.NET MVC другая концепция по умолчанию
autocompleteskills будет AutoCompleteSkillsController
%22myskill будет методом "MySkill, что некорректно

Поэтому и валится, возможно настройкой routestable это можно починить, и выдрать эту часть пути и смапить на другой метод, но зачем такое делать?
Dennis Gorelikdennisgorelik on July 27th, 2017 02:32 pm (UTC)
> кусок javascript

Это упрощает javascript в браузере - нет необходимости парсить json.

> autocompleteskills будет AutoCompleteSkillsController
%22myskill будет методом "MySkill, что некорректно

Это значит, что с приобретением MVC - я теряю гибкость в формате URLs, которые я использую.
Ну и зачем нужен такой инструмент, который накладывает ненужные ограничения на бизнес-логику построения URL?

Кроме того, само по себе сообщение об ошибке в данном случае - очень некачественное и очень плохо объясняет причину, по которой ASP.NET MVC Framework считает это ошибкой.

Некачественное (запутанное) сообщения об ошибке - это тоже серьёзный недостаток framework-а.
Dennis Gorelikdennisgorelik on July 27th, 2017 02:36 pm (UTC)
> Там возвращается даже не json а кусок javascript. Странно.

See client usage of '/autocompleteskills/' here:
view-source:https://www.postjobfree.com/job-alert


Edited at 2017-07-27 02:37 pm (UTC)
veremeenko_alex on July 27th, 2017 03:05 pm (UTC)
проверил в проекте mvc net core

app.UseMvc(routes =>
{
routes.MapRoute(
"Default", // Route name
"{controller}/{search}", // Route Pattern
new {controller = "AutocompleteSkills", action = "Index", search = "search" });
});


namespace WebApplication1.Controllers
{
public class AutocompleteSkillsController : Controller
{
// GET: //
public IActionResult Index(string search)
{
return View("Index", search);
}
}
}

кавычки проходят
Dennis Gorelikdennisgorelik on July 27th, 2017 03:34 pm (UTC)
===============
https://stackoverflow.com/questions/23707108/why-does-adding-system-web-webpages-dll-cause-illegal-characters-in-path-cras
Q3: Does that "Illegal characters in path." crash happen on all computers?

No. Unfortunately it crashes in production, but does not crash on my dev machine.
===============

Sigh.
veremeenko_alex on July 27th, 2017 03:41 pm (UTC)
Мой пример доказывает что можно использовать тот же формат урл используя asp.net mvc

В принципе ваш сайт можно было писать хоть на пхп, у него достаточно простой функционал.
Даже webforms довольно излишен.

Dennis Gorelikdennisgorelik on July 27th, 2017 03:52 pm (UTC)
> можно использовать тот же формат урл используя asp.net mvc

Можно. В development environment.
А в production - не работает.
Ненадёжно работающая функциональность -- ещё хуже, чем вообще не работающая функциональность.

> В принципе ваш сайт можно было писать хоть на пхп

Что значит "даже"?
Facebook тоже на php написан.

> у него достаточно простой функционал

Функционал - совсем даже не простой. Но основная сложность - в backend, а не в asp.net коде.

> Даже webforms довольно излишен.

Возможно.
Чем больше и старше сайт, тем больше у меня соблазна избавиться от ASP.NET и писать на чистом C#.
Vanilla ASP.NET, конечно, более надёжный продукт, чем ASP.NET MVC, но всё равно несколько глючный.

С другой стороны, не хочется терять некоторые удобные инструменты (типа валидации HTML и javascript в дизайнере).
И, конечно, не хочется переписывать legacy код.


Edited at 2017-07-27 03:53 pm (UTC)